为什么我们12%的注册是假的——以及我们采取的措施

Source: Dev.to

去年十月，我打开了我们的 ESP 仪表盘，看到 12.3 % 的硬退信 出现在入职邮件中。

不是软退信。也不是“邮箱已满”。而是硬性的 550 拒收——那种会让你的服务商发送警告邮件，听起来像是威胁的情况。

我们并没有向任何人发送垃圾邮件，也没有抓取名单。这些都是刚刚注册的用户。

这时我恍然大悟：这不是发送问题，而是 注册问题。

Source: …

实际上电子邮件退回时发生了什么

大多数开发者在出现问题之前都不会去关注 SMTP 层，我也不例外。

当你的服务器发送邮件时，它会连接到收件方域名的 MX 记录。整个流程通常是这样的：

1. TCP connect
2. EHLO your-domain.com
3. MAIL FROM:
4. RCPT TO:

如果收件箱不存在，远程服务器会回复类似以下内容：

550 5.1.1 User unknown

这种拒绝通常发生在发送任何邮件正文之前——没有内容，没有 HTML，只有协议层面的“否”。

如果这种情况频繁出现，你的发送 IP 就会显得可疑。邮件服务提供商会密切监控这一点。高硬退回率会让他们认为你无法控制自己的数据，而他们并不喜欢这种情况。

为什么正则和双重确认没有拯救我们

我们的第一步是可预见的：正则验证。

/^[^\s@]+@[^\s@]+\.[^\s@]+$/

它能捕获明显的垃圾，但对 fakeuser@gmail.com 却无能为力。

接着我们加入了 MX 检查。如果某个域没有邮件服务器，我们就拒绝它。这去除了部分垃圾域名，但仍然会接受在真实域名上不存在的地址。

然后我们依赖 双重确认。双重确认有帮助，但它是被动的。你仍然要 发送第一条消息。如果邮件弹回，损失已经 发生。在用户 点击任何内容 之前，你的声誉就已经下降。

我们需要在坏地址 进入我们的数据库之前 就将其拦截。

修复方案：注册时实时邮箱检查

我们决定在 注册时 验证地址——不仅仅是格式校验、域名是否存在，而是实际的邮箱检查。

最终我们使用了 VerifiSaaS（https://verifisaas.com）。市面上还有 ZeroBounce、NeverBounce 等工具，但我们想要一个 API‑first 的方案，能够直接集成到后端，而不需要繁琐的 CSV 工作流。

下面是我们现在的 Next.js API 路由代码：

// pages/api/signup.js
export default async function handler(req, res) {
  const { email, password } = req.body;

  const response = await fetch('https://api.verifisaas.com/v1/verify', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      'Authorization': `Bearer ${process.env.VERIFISAAS_API_KEY}`
    },
    body: JSON.stringify({ email })
  });

  const result = await response.json();
  const { status, confidence_score, classification } = result;

  if (status === 'undeliverable') {
    return res.status(400).json({ error: 'That email address does not exist.' });
  }

  if (confidence_score < 0.6 || classification === 'risky') {
    return res.status(400).json({ error: 'Please use a valid email address.' });
  }

  return res.status(200).json({ success: true });
}

就这么简单。表单提交到该路由后，我们在 写入数据库之前 完成验证。如果地址验证失败，流程就在此终止——不会发送欢迎邮件、不会产生弹回、也不会影响声誉。

我们发布后有什么变化

• 在一周内，我们的硬退回率从 ≈12 % 降至 <0.5 %。
• 这相当于每十封邮件中有一封失败，降至每千封约四封。
• 我们的 ESP 停止发送警告邮件。
• 发件人评分在接下来的几周里缓慢上升。
• 关于缺失入职邮件的支持工单数量下降。

更大的收获不仅仅是声誉提升。

• 我们的数据库变得更干净。
• 营销自动化不再因垃圾账户而卡顿。
• 分析数据更可靠。
• 我们不再在虚假用户之上构建功能。

这本该在 v1 中就实现。

变得混乱的部分

• Catch‑all domains 在 SMTP 检查阶段接受任何地址，但随后会悄悄丢弃邮件。如果你把每个 250 都当作有效，你会高估质量。我们不会自动拦截 catch‑alls；我们会标记它们。对部分用户来说这已经足够，对高风险注册我们会要求额外确认。
• Disposable providers 是另一个灰色地带。对 B2B SaaS 来说，它们通常意图低；对消费类应用则可能是合法的隐私选择。我们会标记它们，并根据具体情境决定是否处理，而不是盲目拦截。
• Performance – 如果你的注册表单出现流量激增并且实时验证每个地址，你会感受到性能压力。我们加入了基础的速率限制，并在验证 API 超时的情况下提供回退模式。注册流程不能在没有防护措施的情况下依赖单一外部调用。

当这值得时

• 如果你每周只发送少量邮件，这可能并不重要。
• 如果你在进行付费获客、为成千上万的用户进行入职，或发送与收入挂钩的事务性邮件，就不能承受两位数的退信率。

我们是吃过这苦头才明白的。域名声誉下降后再去修复投递率非常痛苦。提前在边缘阻止错误数据要容易得多。

我会做的不同之处

我本应该从一开始就把 注册验证视为电子邮件基础设施的一部分。

我们曾认为电子邮件问题出现在发送层。事实并非如此。它们出现在 输入层。

错误数据传播迅速。它会污染分析、营销、计费和支持工作流。一旦进入，清理起来就是噩梦。

祝编码愉快，愿你的退信率保持在 0.5 % 以下！