1. 从一封“用完即弃”的注册邮件说起
做用户增长和风控的同行大概都遇到过这种场景：后台注册量曲线突然翘头，看着挺喜人，结果一查邮箱域名，全是@mailinator.com、@guerrillamail.com、@temp-mail.org这类一次性邮箱。这些账号领完新人券、薅完首单优惠就消失，留下的全是脏数据，后续做留存分析、用户画像、邮件触达时全被污染。更麻烦的是，有些批量注册背后还连着刷单、薅羊毛、垃圾内容投放，等你反应过来，营销预算已经被啃掉一大块。
StopReg 这个项目瞄准的就是这个痛点——它把自己定位成一个Email API，核心能力是识别 disposable email（一次性邮箱）和 signup abuse（注册滥用）。说白了，你把它接进注册流程，用户提交邮箱的那一刻，API 就告诉你这个邮箱是不是临时邮箱、这个注册行为有没有滥用嫌疑，然后你决定是放行、拦截还是打标观察。
这篇文章不是官方文档的翻译，而是我以一个接过多个注册风控系统的一线从业者视角，把这类邮箱检测 API 的工作原理、接入方式、阈值调优、误杀处理、以及那些文档里不会写的坑，完整地拆一遍。不管你是刚接触风控的开发者，还是正在选型邮箱验证服务的产品负责人，都能从里面拿到可以直接抄作业的东西。
2. 一次性邮箱检测到底在检测什么
很多人以为“检测一次性邮箱”就是拿一个黑名单域名去比对，命中就拦。这个理解只对了三成。真正能打的检测服务，背后是一套多信号融合的判断体系。StopReg 这类 API 的价值，恰恰在于它把这些信号打包成了一个接口调用。
2.1 域名黑名单只是最粗的那一层
最基础的一层确实是域名库。像mailinator.com、10minutemail.com、yopmail.com这些老牌临时邮箱，域名是公开的，维护一份黑名单并不难。但问题在于：
- 临时邮箱服务商每天都在注册新域名，黑名单永远滞后；
- 有些服务商提供“自定义域名”功能，用户可以把自己的域名挂上去收信，这时候域名看起来完全正常；
- 反向操作也存在——某些正常企业邮箱域名会被误判。
所以单靠黑名单，召回率和准确率都撑不住。我实测过，纯黑名单方案对新型临时邮箱的漏检率能到 40% 以上，基本等于没防。
2.2 MX 记录与 DNS 特征：判断“这个域名能不能收信”
第二层是 DNS 层面的探测。一个邮箱域名要能收信，必须有有效的 MX 记录。检测服务会去查这个域名的 MX 记录指向哪里，然后做几件事：
- 看 MX 是否指向已知的临时邮箱基础设施（很多临时邮箱共用同一批邮件服务器）；
- 看域名的 A 记录、NS 记录是否异常（比如 NS 指向免费 DNS 服务、域名注册时间极短）；
- 看域名是否配置了 SPF、DKIM 等邮件认证记录——正规企业邮箱通常有，临时邮箱往往没有。
这一层能抓到不少黑名单漏掉的新域名。但要注意，MX 查询是有网络开销的，如果 API 每次调用都实时查 DNS，延迟会上去。好的服务会做缓存和预计算，这也是选型时要关注的指标。
2.3 行为信号：signup abuse 的真正抓手
标题里除了 disposable email，还有signup abuse。这两个是不同维度的问题。一次性邮箱是“邮箱本身可疑”，注册滥用是“这个注册行为可疑”。StopReg 把两者放在一起，说明它不只是做邮箱格式校验，还在做行为风控。
行为信号通常包括：
- 同一 IP 在短时间内的注册频次；
- 同一设备指纹关联的账号数量；
- 注册时提交的邮箱是否呈现批量模式（比如
user1001@、user1002@这种连续命名）； - 注册时间分布是否异常（比如凌晨集中爆发）；
- 邮箱本地部分（@ 前面那段）是否是随机字符串。
这些信号单独看都不致命，但组合起来就能勾勒出一个“批量注册”的画像。这也是为什么纯前端校验没用——攻击者可以绕过前端，直接打你的注册接口。
2.4 一次性邮箱的“生命周期”特征
还有一个容易被忽略的维度：邮箱的存活时间。临时邮箱的典型特征是“注册后几分钟到几小时内有效，之后自动销毁”。检测服务可以通过一些间接手段推断：
- 该域名下的邮箱是否在极短时间内被大量创建；
- 该域名是否在公开的临时邮箱列表中频繁出现；
- 域名的 whois 信息是否匿名化、注册时间是否在近期。
把这些维度综合起来，才能给出一个相对可靠的“一次性邮箱概率分”，而不是简单的“是/否”。
3. 把 StopReg 接进注册流程：一次完整的接入推演
假设你现在要给一个 SaaS 产品的注册页加邮箱风控，StopReg 是候选方案。下面是我会走的完整流程，包括每一步的决策理由。
3.1 先明确你要拦的是什么
接入之前必须先回答一个问题：你的业务能承受多少误杀？
- 如果是面向企业的 B2B 产品，误杀一个真实客户邮箱的代价极高，那阈值要放宽，宁可放过一些可疑的，也不能拦错；
- 如果是面向消费者的促销活动，薅羊毛风险大，阈值可以收紧，误杀几个真实用户影响相对小；
- 如果是金融、支付类场景，风控要求最高，可能需要“可疑即拦截 + 人工复核”。
这个判断直接决定了你后面怎么用 API 返回的结果。StopReg 这类服务通常会返回一个风险评分或分类标签，而不是简单的布尔值，就是为了让你根据业务调阈值。
3.2 API 调用的典型时序
一个合理的接入时序是这样的：
- 用户在注册表单提交邮箱；
- 前端做基础格式校验（正则），过滤掉明显不合法的；
- 后端调用 StopReg API，传入邮箱地址 + 请求上下文（IP、User-Agent、时间戳等）；
- API 返回风险结果；
- 后端根据结果决定：放行 / 拦截 / 标记待审；
- 记录本次检测结果，用于后续分析和模型迭代。
这里有个关键点：不要把 API 调用放在前端。原因有两个：一是暴露 API Key，二是攻击者可以绕过前端直接打后端。所有风控判断必须在服务端完成。
3.3 请求参数里哪些是必须的
虽然 StopReg 的具体参数文档我没有逐字看到，但基于这类服务的通用设计，请求里通常包含：
| 参数 | 是否必须 | 作用 |
|---|---|---|
| 必须 | 待检测的邮箱地址 | |
| ip | 强烈建议 | 判断注册来源是否异常 |
| user_agent | 建议 | 辅助设备指纹判断 |
| timestamp | 建议 | 判断注册时间分布 |
| signup_source | 可选 | 区分不同注册入口 |
提示：如果 API 支持传入 IP，一定要传。很多一次性邮箱检测的准确率提升，靠的就是“邮箱可疑 + IP 可疑”的联合判断。只传邮箱，等于自断一臂。
3.4 返回结果怎么解读
这类 API 的返回通常包含几个字段：
is_disposable：是否一次性邮箱；risk_score：0-100 的风险分；reason：判定原因（比如domain_in_blocklist、suspicious_mx、high_frequency_ip）；is_valid_format：格式是否合法。
我的建议是不要只看is_disposable这个布尔值。真正有用的是risk_score和reason。比如：
risk_score在 80 以上，直接拦截；- 60-80 之间，标记为待观察，限制其领券、发帖等敏感操作；
- 60 以下，放行但记录。
reason字段则用于排查误杀。如果发现大量真实用户被拦，看 reason 就知道是哪个信号出了问题，方便针对性调整。
3.5 一个最小可用的接入示例
下面是一段伪代码，展示后端如何调用这类 API 并做决策：
import requests def check_email_risk(email, ip, user_agent): resp = requests.post( "https://api.stopreg.example/v1/check", json={ "email": email, "ip": ip, "user_agent": user_agent }, headers={"Authorization": "Bearer YOUR_API_KEY"}, timeout=2.0 ) data = resp.json() if data["risk_score"] >= 80: return "block" elif data["risk_score"] >= 60: return "review" else: return "allow"注意timeout=2.0这个设置。风控 API 是同步调用，如果它挂了或响应慢，不能拖垮你的注册流程。必须设置超时，并且有降级策略——超时了就默认放行还是默认拦截，取决于你的业务风险偏好。我的经验是：注册流程默认放行 + 异步补检，比直接拦截体验更好。
4. 阈值调优：那些文档不会告诉你的经验
接入只是第一步，真正决定效果的是阈值调优。这部分我踩过的坑最多，单独拎出来讲。
4.1 冷启动阶段不要急着拦截
刚接入的前一两周，建议只记录不拦截。把所有检测结果和实际注册行为都存下来，观察：
- 被标记为高风险的账号，后续行为是否真的异常（比如是否快速流失、是否触发其他风控规则）；
- 被标记为低风险的账号，有没有漏网的滥用者。
这个阶段是在积累你自己的标注数据。StopReg 的模型是通用的，但你的业务场景是特定的，只有用你自己的数据校准，才能找到最合适的阈值。
4.2 不同注册入口用不同阈值
一个产品往往有多个注册入口：官网注册、App 注册、活动落地页注册、API 注册。这些入口的风险特征完全不同：
- 活动落地页：薅羊毛重灾区，阈值要严；
- 官网注册：相对正常，阈值可放宽；
- API 注册：如果是开放平台，滥用风险高，需要额外校验。
我见过一个团队所有入口用同一个阈值，结果活动页拦得不够，官网又误杀太多。按入口分阈值是基本操作。
4.3 关注“灰色地带”的处理
风险分在 60-80 之间的“灰色地带”最考验策略。直接拦，误杀率高；直接放，又可能漏掉批量注册。我的做法是：
- 对灰色地带账号，限制其高价值操作，而不是直接封禁。比如可以浏览、可以登录，但不能领券、不能发帖、不能邀请好友；
- 同时把这些账号加入观察名单，如果后续触发其他风控规则，再升级处理。
这种“渐进式风控”比一刀切体验好得多，也更能抓住真正的滥用者——因为滥用者最终一定会去碰那些高价值操作。
4.4 定期回捞误杀样本
再好的模型也会有误杀。关键是建立误杀申诉和回捞机制：
- 给被拦截的用户提供申诉入口；
- 定期（比如每周）拉取被拦截但用户申诉的样本，人工复核；
- 如果发现某类邮箱被系统性误杀，调整规则或反馈给 API 服务商。
我处理过一个案例：某企业邮箱域名因为 MX 配置特殊，被检测服务误判为临时邮箱，导致该企业的员工批量注册失败。这种问题只有靠回捞才能发现。
5. 自建 vs 用 API：一个绕不开的选型问题
看到这里你可能会想：这些检测逻辑我自己也能写，为什么要用 StopReg 这类 API？这个问题值得认真回答。
5.1 自建方案的隐性成本
自建邮箱检测，表面上看是省了 API 费用，但隐性成本很高：
- 域名库维护：临时邮箱域名每天在变，你需要持续爬取、收集、更新，这是个体力活；
- DNS 查询基础设施：高并发下的 DNS 查询需要缓存、需要分布式部署，不然延迟和稳定性都是问题；
- 行为风控模型：signup abuse 的检测需要大量数据和模型调优，不是写几条规则就能搞定的；
- 持续对抗：攻击者会针对你的规则做规避，你需要不断迭代。
我算过一笔账：一个中等规模的产品，自建一套能达到商用水平的邮箱检测系统，前期投入至少 2-3 人月，后续每月还要投入人力维护。相比之下，API 按调用量付费，前期几乎零成本。
5.2 什么情况下适合自建
也不是所有情况都该用 API。以下场景自建更合适：
- 调用量极大：如果每天几百万次调用，API 费用会很高，自建可能更划算；
- 数据合规要求极高：某些行业不允许把用户邮箱传给第三方，只能自建；
- 有特殊检测需求：通用 API 满足不了的特定场景，需要定制。
5.3 混合方案：API 兜底 + 自建规则
我目前最推荐的其实是混合方案：
- 用 StopReg 这类 API 做第一层通用检测，覆盖大部分已知的临时邮箱和明显滥用；
- 自建一层业务规则，处理 API 覆盖不到的、你业务特有的滥用模式；
- 两层结果做联合决策，任何一层判定高风险就拦截。
这样既享受了 API 的广度和持续更新，又保留了对业务特定风险的掌控力。
6. 实测中遇到的几个典型问题
下面这几个问题是我在实际接入和使用过程中真实遇到的，分享出来帮大家少走弯路。
6.1 API 延迟波动导致注册超时
风控 API 是同步调用，它的延迟直接叠加在用户注册体验上。我遇到过 API 在高峰期响应从 200ms 涨到 1.5s 的情况，导致注册接口整体超时。
解决方案：
- 设置合理的超时时间（我一般设 1-2 秒）；
- 超时后走降级逻辑，默认放行 + 异步补检；
- 如果 API 服务商提供批量接口，对非实时场景可以用批量。
6.2 某些企业邮箱被误判
前面提过，某些企业邮箱因为 MX 或 SPF 配置特殊，会被误判为临时邮箱。这类误杀的杀伤力很大，因为影响的是真实付费客户。
解决方案：
- 维护一份白名单，把已知的、确认正常的企业邮箱域名加进去，优先级高于 API 结果；
- 对 B2B 产品，考虑对已知企业域名直接放行，不做检测。
6.3 攻击者用“正常邮箱”批量注册
这是最棘手的情况：攻击者不用临时邮箱，而是用 Gmail、Outlook 这类正常邮箱批量注册。这时候邮箱检测 API 就失效了，必须靠行为风控。
解决方案：
- 加强 IP 和设备指纹维度的检测；
- 对同一 IP/设备的高频注册做限制；
- 引入验证码、手机验证等二次验证手段。
这也说明，邮箱检测只是注册风控的一环，不是全部。把它当成唯一防线，一定会被绕过。
6.4 风险分阈值需要随业务变化调整
业务是动态的。促销期滥用风险高，阈值要收紧；平稳期可以放宽。我见过团队设了一个固定阈值就再也不管了，结果促销期被薅得很惨。
解决方案：
- 建立阈值配置化机制，可以随时调整而不用改代码；
- 大促前主动收紧阈值，活动结束后恢复；
- 监控拦截率和误杀率，异常时及时干预。
7. 关于邮箱风控这件事，我的一点个人体会
做了几年注册风控，最大的感受是：没有一劳永逸的方案，只有持续对抗的过程。StopReg 这类 API 能帮你解决 70%-80% 的通用问题，但剩下的 20%-30% 必须靠你自己的业务理解和持续运营。
我见过太多团队把风控当成一个“接入了就完事”的功能，结果要么误杀一片，要么形同虚设。真正有效的做法是：把邮箱检测当成一个持续迭代的系统，定期看数据、调阈值、回捞误杀、更新规则。API 是工具，策略才是核心。
另外提醒一句：风控的目标不是“拦住所有可疑”，而是“在风险和体验之间找到平衡”。过度风控会赶走真实用户，风控不足会被薅羊毛。这个平衡点，只有你自己最清楚。
