我们本可以排得更高，但我们选择不假装自己知道更多

有一种测试，会让一家年轻的软件公司本能地紧张。

不是安全审计，也不是线上事故，而是——公开基准测试。

有人拿走你的 API，用一组真实地址进行测试，公开结果，然后把你和那些拥有更大团队、更充足预算、以及更成熟品牌的公司放在同一张排行榜上。

对一家小公司来说，这可能是一个非常难得的机会。一个漂亮的成绩可以带来关注、可信度、新用户，甚至更多收入。一个不理想的成绩，则可能让别人还没真正了解产品，就先把它排除在外。

最近，我们的邮箱验证 API 就遇到了这样的情况。DataCircle 对我们进行了公开的邮箱验证对比测试，并将我们与几十家其他服务商放在一起比较。

这次测试让我们看到了一个此前没有从客户角度充分思考的产品决策。我们后来改变了这个决策。同时，它也暴露出一个更复杂的问题：当一个邮箱地址无法被确定性验证时，到底什么才算是诚实的答案？

这篇文章不是为了讨论谁对谁错。评测方有一套合理的方法论，我们也尊重创建和公开这项测试所付出的工作。我们只是想解释发生了什么、当时面对怎样的选择，以及我们为什么做出了现在的决定。

这个机会是真实存在的

这次测试的结果并不漂亮。

在 DataCircle 于 10 月 31 日进行的复测中，我们的 API 得分为 50 分（满分 100 分），在 91 家服务商中排名第 65 位。对于一家仍在努力建立信任、说服用户尝试自己产品的小公司来说，这种结果当然不会让人开心。

于是，我们开始仔细查看测试用例。

其中一些未通过的地址，属于已知的 catch-all 域名。所谓 catch-all 邮件服务器，是指它在 SMTP 会话阶段几乎接受发往该域名的任何收件人地址。从外部看，person@example.com 和 definitely-not-a-real-mailbox@example.com 可能会得到完全相同的响应。

这带来了一个根本限制：服务器确认了这个域名可以接收邮件，但并没有确认具体的邮箱地址确实存在。

我们的 API 会将这种情况标记为 risky。

而这项基准测试对这些情况采用了不同的判定方式。根据实际发送邮件后观察到的结果，测试地址对应的预期标签是 invalid。

这个差异对排名产生了明显影响。如果我们把这些结果从 risky 改成 invalid，得分就会显著提高，排行榜上的位置也会随之上升。

诱惑当然很大。

真正令人不舒服的，并不是技术故障

在讨论分歧之前，有必要先区分两件从外部看起来很相似的事情：技术故障，以及产品决策。

最初，我们有意将 catch-all 检测功能限定在 Pro 套餐及更高等级。我们的考虑是，Starter 和 Free 套餐使用相对精简的功能集，而更高等级的套餐提供更高级的检测能力和更新频率。

所以，当用于测试的账户没有识别出这个 catch-all 域名时，系统其实是在按照我们自己制定的产品规则运行。它不是一个我们不小心发布出去的隐藏 bug。

但这次测试迫使我们从客户的角度重新审视这个决定。

如果 Free 或 Starter 用户因为系统没有执行 catch-all 检测，而得到一个"有效"的结果；与此同时，Pro 用户因为启用了这个功能而得到 risky，那么这两档套餐之间的差异就不只是速度或便利性的问题了。它直接影响客户能够获得多少关于这个地址的真实信息。

这与我们的透明原则发生了冲突。

当客户要根据验证结果决定是否联系某个人时，我们不希望那些会影响准确判断的重要信息被隐藏在付费墙后面。对于更快的检查、更高的额度、更高的处理优先级、更频繁的刷新，以及其他运营层面的优势，我们当然可以收费。但我们开始不愿意让客户付费才能知道一个域名本身属于 catch-all 域名。

于是，我们改变了产品决策。

现在，catch-all 检测从原来的 Pro 及以上套餐专用，调整为对所有套餐开放——Free、Starter、Pro 和 Enterprise 都能获得这个核心信号。不同套餐之间仍然可以在速度、SMTP 超时设置、优先级模式和数据新鲜度方面有所区别，例如重新检测 catch-all 状态的频率不同。但最核心的信号，现在对所有用户开放。

这次调整之后，我们的基准测试分数并没有变化。Free 和 Starter 套餐现在能正确识别 catch-all 域名，但仍然返回 risky 而不是 invalid——而基准测试的评分模型把 risky 视为未通过。这次套餐调整是为了透明度，不是为了排名。

这不是一次 bug 修复，而是一次有意为之的调整。因为我们意识到，原来的套餐边界已经不再符合我们希望坚持的透明标准。

这个区别对我们很重要。我们愿意为更高的容量和更便利的使用体验收费，但我们不太愿意让客户付费，才能得知一个会实质改变邮箱验证结果含义的限制条件。

做出这个改变之后，另一个问题仍然存在：当 catch-all 检测正常工作，但我们依然无法确认具体邮箱是否存在时，API 到底应该返回什么？

"Invalid"到底意味着什么？

对于邮箱验证产品来说，状态标签不是装饰。客户会根据这些标签决定如何处理一个地址。

如果 API 返回 invalid，大多数用户合理的理解是：

这个地址已经被确认不存在，或者无法投递。

而如果 API 返回 risky，含义则不同：

这个地址存在明显的投递风险，但还没有被证明是无效地址。

这一区别很重要。

对于 catch-all 域名，SMTP 服务器可能接受所有收件人。它也可能在之后拒绝部分邮件，或者接受邮件并以验证器无法观察到的方式进行处理。某封邮件之后发生退信，确实可以为那次具体投递提供证据，但这并不会改变验证器在最初检查时能够知道什么。

发送前的邮箱验证 API，和真正发送一封邮件、再观察最终投递结果，并不是同一件事。

这并不意味着其中一种方法一定正确，另一种方法一定错误。它们回答的是略有不同的问题。

这项基准测试实际上问的是：

这封邮件发出之后，这个地址最终表现得像是可投递的吗？

而我们的 API 设计用来回答的是一个更具体的问题：

在客户真正发送邮件之前，根据我们能够获得的信号，我们可以对这个地址判断到什么程度？

对于 catch-all 域名，第二个问题诚实的答案通常是：我们无法有足够把握地验证这个具体邮箱是否存在。

这就是我们使用 risky 的原因。

提高分数的简单办法

我们本可以增加一条规则：

如果一个域名是 catch-all，就返回 invalid，而不是 risky。

从技术上说，这并不困难。

这样做也确实会改善我们的基准测试排名。我们在对比表上的结果会更好看，可能也会有更多访客点击进来了解产品。

但同一条规则也会影响现实中的 API 客户。他们可能验证一个属于 catch-all 域名的地址，得到 invalid，然后把一个本来可能真实存在的潜在客户从名单中删掉。

这就是误报中的一种：假阴性。

假阴性通常不像假阳性那样显眼。假阳性可能导致邮件退信，而假阴性则可能让用户从一开始就不再发送这封邮件。因为没有退信、没有错误消息，甚至没有明显的记录，这种损失反而更难被发现和衡量。

我们不想为了排行榜上的一个数字，给客户一种底层证据并不支持的确定感。

所以，我们没有仅仅为了提高排名，就改变结果的含义。

这不是一篇反对基准测试的文章

我们完全可以把这篇文章写成一篇愤怒地批评基准测试的文章，但我们不想这样做。

公开测试是有价值的。它可以发现产品中的问题，揭穿模糊的营销表述，也能为客户提供产品落地页上通常不会告诉他们的信息。我们很感谢这次测试公开了足够多的输入和结果，让我们能够调查到底发生了什么。

我们也理解，评测方为什么可能更偏好简单的评分模型。基准测试需要规则。如果每家服务商遇到每个边缘情况时，都要采用一套特别解释，那么比较结果就会很难阅读，也很难复现。

真正的分歧在于：catch-all 结果是否应该被强行放进 valid / invalid 这样的二元模型中。

在我们看来，邮箱验证至少有三种有意义的结果：

1. Valid：有效——现有证据支持该邮箱大概率能够接收邮件。
2. Invalid：无效——现有证据支持该地址无法投递。
3. Risky 或 unverifiable：有风险或无法验证——域名或邮箱行为使我们无法得出可靠结论。

我们的 API 还会在服务器完全无法连接时使用 unknown。例如，可能是技术限制、触发了速率限制，或者验证探针暂时不可用。unknown 与 risky 并不相同：unknown 表示我们没有获得足够的信息来评估这个地址；而 risky 表示现有信号已经显示出明显的投递风险或不确定性。

三状态模型并不会让验证失去价值。相反，它把不确定性明确呈现出来。

客户可以据此选择适合自己的处理策略，例如：

• 删除被标记为 invalid 的地址；
• 只在小规模、可监控的活动中使用 risky 地址；
• 如果你是从中国域名发出邮件，也可以参考我们对为什么中国域名在 Gmail 眼里常常显得可疑的分析——投递失败的原因有时和地址本身无关；
• 通过其他渠道要求客户确认 risky 地址；
• 保留 risky 地址，但不把它们当作完全验证通过的地址。

这比把不确定性隐藏在一个二元标签里更有用。如果你正在评估邮箱验证服务商，我们的选型指南列出了在选择前应该问清楚的关于 catch-all 处理和标签语义的问题。

Catch-all 域名并不是完全没有价值

这里还有一个重要的细节。

我们并不是说 catch-all 域名上的所有地址都应该被丢弃，也不是说一旦发现 catch-all，整个域名就完全不能使用。

有些服务商，包括一些大型消费者邮箱服务，在 SMTP 阶段有时仍然会返回有用的否定结果。明确的拒收依然是有价值的证据。如果服务器明确表示某个收件人不存在，那么这条信息当然应该被报告出来。

真正困难的是 catch-all 服务器返回肯定响应的情况。肯定响应只能说明服务器在检查时接受了这个收件人，并不能证明这个具体邮箱属于一个真实的人。

所以，我们的做法不是：

永远不要验证 catch-all 域名。

而是：

不要把不确定的结果描述成确定的事实。

这句话可能没有"我们可以验证每一个邮箱"那么令人兴奋，但它更准确。

这次经历让我们学到了什么

这次经历给我们留下了三个教训。

第一，不是每个看似合理的套餐区分都是好区分。如果一个功能会改变客户对证据的理解，把它锁在付费墙后，可能悄悄削弱产品本该建立的信任。

第二，产品标签需要和产品功能一样认真对待。valid、invalid、risky、unknown 和 catch-all 不是可以随意互换的词——客户会围绕这些标签建立工作流程。

第三，一个排名的意义取决于它背后的问题。基准测试可以公平透明，但仍然可能在测量与产品目标略有不同的东西。

为什么我们接受了较低的排名

那个机会确实很有吸引力。

如果分数更高，我们可能会进入榜单前列。这可能带来曝光，也可能带来商业机会。对于一家小公司来说，这些收益不是虚构的，它们确实很重要。

但我们的产品不只是一个 API 接口，也不仅仅是一个返回状态的数字。它还包括我们对这个结果所做出的解释。

当我们告诉客户一个地址是 invalid 时，我们是在对现实做出一个判断。当我们告诉客户一个地址是 risky 时，我们做出的则是另一种判断：这个地址存在足够的不确定性或投递风险，客户应该谨慎对待。

我们希望这些判断经得起追问。

如果仅仅因为把 risky 改成 invalid 就能提高公开排名，那么我们实际上会在"我们知道什么"和"我们告诉客户什么"之间制造一道裂缝。

这是我们无法接受的裂缝。

所以，我们接受了较低的排名。

不是因为排名不重要。排名当然重要。

也不是因为我们认为评测方有意不公平。我们不认为这是一个有建设性的结论。

我们接受这个结果，是因为一个基准测试的排名是暂时的，而客户信任是长期积累的。一个高排名可能让别人访问你的网站一次，但真正让他们留下来的，是他们相信你返回的结果。

如果是你，你会怎么做？

这个问题没有一个适用于所有人的答案。

如果你经营一家小型 API 公司，发现只要改变一条分类规则，就可以让自己从公开排名的中游进入前列，你会改变吗？

你会优先遵循基准测试对"正确答案"的定义，还是优先考虑客户在真实生产环境中面对的不确定性？

你会采用二元结果，因为它更容易比较；还是增加第三种状态，因为它更能反映证据本身的局限？

在这次事件中，我们选择了透明度，而不是排名。另一家公司可能会做出不同的选择，而这并不自动意味着它不诚实。不同产品可以有不同目标，不同基准测试也可以衡量不同的东西。

对我们来说，原则很简单：

如果我们不能确定，就不应该假装自己确定。

这并不是承诺我们的 API 永远不会出错。任何邮箱验证服务都不可能诚实地做出这样的承诺。我们的承诺是：我们会继续改进检测能力，解释系统的限制，并且不会仅仅因为确定性更容易带来漂亮的数字，就人为制造一种并不存在的确定性。

而且，是的，我们仍然会继续验证 catch-all 域名。

我们只会继续诚实地标记它们。

有问题？

我是 Andy，创始人。我只是个喜欢为人解决问题的 IT 仔。如果您对邮箱验证 API、我们返回的标签，或 catch-all 检测在实际中如何工作有任何疑问，随时给我发邮件。

📧 info@parheliaweb.com