冷邮件的 Catch-All 策略

Catch-all 不等同于有效。

当域名配置为 catch-all 时，无论具体邮箱是否存在，它都会接受所有传入消息。验证工具无法突破域名级别的接受，去检查 john.smith@company.com 是否真的属于某人。域名接受了，邮箱不一定存在。

这就是将 catch-all 结果当成已确认有效地址处理的核心问题。你的邮件被接受了，但不意味着它被投递给了真实的人。很多情况下，域名运行 catch-all 配置，恰恰是因为它无法维护自己邮箱的准确列表——发送到不存在地址的邮件会被悄悄丢弃。

反过来，将每一条 catch-all 结果都当成垃圾并全部删除也是一个错误。这会丢弃大量有意义的分类。许多 catch-all 域名包含真实的、可投递的地址。正确做法既不是盲目接受所有 catch-all 记录，也不是全部丢弃——而是将它们单独分类，并制定自己的发量和风险规则。

Catch-all 结果处于有效和无效之间的风险区间。它们既不等同于已确认有效，也不等同于已确认失效。它们需要单独的路由决策——而不是简单的保留或移除判断。

大多数团队在验证输出中遇到 catch-all 结果时，会陷入以下三种模式之一：

将 catch-all 视为有效。 团队将所有 catch-all 记录与已确认有效地址一起导入主活动。当这些记录产生退信或互动率低时，团队责怪发件工具或邮件文案，而不是导入时做出的列表质量决策。

将 catch-all 视为无效。 团队在导入前丢弃所有 catch-all 记录。在某些行业——医疗、金融、中型 B2B 公司——catch-all 配置很常见，被丢弃的记录可能代表真实的联系人。团队在没有策略依据的情况下丢失了可触达的潜客。

完全忽略 catch-all。 团队根本不过滤 catch-all 状态。Catch-all 记录与已确认有效地址混在一起悄悄进入主活动。退信模式变得更难诊断，因为列表从一开始就不干净。

基于策略的方法在任何记录进入发件工具之前，将 catch-all 单独分类。该分类有不同的规则：较低的发量、更密切的监控，以及明确决定它是属于当前活动还是等待队列。

Catch-all 分类不是废弃堆，而是受监控的分类。一些 catch-all 记录会产生回复，另一些会退信或无互动。首次向 catch-all 分类进行小规模发送，会给你关于该域名实际行为的真实信号——这是仅靠验证无法获得的信息。

应该，但要降低发量并单独跟踪。在大多数 B2B 外呼场景中，丢弃所有 catch-all 记录过于保守。正确做法是将它们单独分类，谨慎发送，并利用首次发送结果决定是否继续或抑制该域名。

一个起点是将首次发送的 catch-all 分类发量上限设置为主活动发量的三分之一左右。如果回复率与主分类相当且退信信号极少，可以在后续发送中逐步提高发量。如果出现退信，抑制那些具体记录，并重新评估剩余域名。

不可以。在同一活动中混合 catch-all 和有效记录会使性能诊断更加困难。如果活动表现不佳或产生意外退信，你无法将列表质量问题与文案、定向或发件工具问题区分开来。独立分类能给你干净的数据来采取行动。