Catch-all 不等同于有效。
当域名配置为 catch-all 时，无论具体邮箱是否存在，它都会接受所有传入消息。验证工具无法突破域名级别的接受，去检查 john.smith@company.com 是否真的属于某人。域名接受了，邮箱不一定存在。
这就是将 catch-all 结果当成已确认有效地址处理的核心问题。你的邮件被接受了，但不意味着它被投递给了真实的人。很多情况下，域名运行 catch-all 配置，恰恰是因为它无法维护自己邮箱的准确列表——发送到不存在地址的邮件会被悄悄丢弃。
反过来，将每一条 catch-all 结果都当成垃圾并全部删除也是一个错误。这会丢弃大量有意义的分类。许多 catch-all 域名包含真实的、可投递的地址。正确做法既不是盲目接受所有 catch-all 记录，也不是全部丢弃——而是将它们单独分类，并制定自己的发量和风险规则。
冷邮件验证框架
本页面介绍单个发件工具或工作流。完整框架涵盖从名单来源到验证、分组，再导入发件工具的全流程。
Catch-all 验证能告诉你什么，不能告诉你什么。
| 信号 | 含义 | 不能告诉你的 |
|---|---|---|
| 已确认 catch-all | 域名接受所有邮件 | 具体邮箱是否存在 |
| 无 MX 失败 | 域名有正常运作的邮件基础设施 | 收件人地址是否对应真实的人 |
| 无硬拒绝 | 服务器未拒绝连接 | 邮件是否会被投递还是被悄悄丢弃 |
| 无一次性标记 | 该域名不是已知的临时邮件服务 | 邮箱是否被监控或处于活跃状态 |
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 单独分类。该分类有不同的规则：较低的发量、更密切的监控，以及明确决定它是属于当前活动还是等待队列。
通过 BillionVerify 运行列表
→ 有效记录 → 主活动分类
→ 无效、风险、一次性 → 抑制列表
→ Catch-all 记录 → 独立分类
→ 应用发量上限（低于主活动）
→ 密切监控回复率和退信信号
→ 不与已确认有效记录混合
→ 根据首次发送结果重新评估
→ 基于角色 → 单独消息轨道
→ 未知 → 审核队列
Catch-all 分类不是废弃堆，而是受监控的分类。一些 catch-all 记录会产生回复，另一些会退信或无互动。首次向 catch-all 分类进行小规模发送，会给你关于该域名实际行为的真实信号——这是仅靠验证无法获得的信息。
导入前路由每条结果。
| BillionVerify 结果 | 导入前操作 |
|---|---|
| 有效 | 导入主活动列表 |
| 无效 | 不导入——添加至抑制文件 |
| Catch-all | 独立分类，降低发量，不与有效地址混合 |
| 基于角色 | 使用共享收件箱消息的单独活动 |
| 未知 | 人工审核——排除在主活动之外 |
| 风险或一次性 | 不导入 |
其他应用类似决策的工作流。
预热前先验证邮件
了解为什么名单验证必须在预热之前进行，而不是之后。
导入前名单清洗
在任何名单进入发件工具或 CRM 之前，应用统一的清洗规则。
冷邮件退信率控制
在名单层面控制退信率，在发件工具介入之前。
预热 vs 邮件验证
了解预热解决哪类问题，验证解决哪类问题。
内置验证 vs 第三方验证
对比发件工具原生验证与专用发送前质量门控的差异。
Folderly + BillionVerify 工作流
在 Folderly 送达率优化前验证名单，干净的数据让预热更有效。
Mailforge + BillionVerify 工作流
在 Mailforge 基础设施运行活动前，添加发送前的验证步骤。
Catch-all 策略常见问题。
我应该向 catch-all 地址发送邮件吗？
应该，但要降低发量并单独跟踪。在大多数 B2B 外呼场景中，丢弃所有 catch-all 记录过于保守。正确做法是将它们单独分类，谨慎发送，并利用首次发送结果决定是否继续或抑制该域名。
Catch-all 分类的发量应该低多少？
一个起点是将首次发送的 catch-all 分类发量上限设置为主活动发量的三分之一左右。如果回复率与主分类相当且退信信号极少，可以在后续发送中逐步提高发量。如果出现退信，抑制那些具体记录，并重新评估剩余域名。
我可以在同一活动中将 catch-all 地址与已确认有效记录混合吗？
不可以。在同一活动中混合 catch-all 和有效记录会使性能诊断更加困难。如果活动表现不佳或产生意外退信，你无法将列表质量问题与文案、定向或发件工具问题区分开来。独立分类能给你干净的数据来采取行动。
如果我的大部分列表都是 catch-all 怎么办？
在某些行业，中型公司将 catch-all 配置为默认邮件服务器设置，这种情况很常见。如果你的列表主要是 catch-all，请将该分类作为主要工作列表，在扩大规模前通过小批次发送验证各域名的实际行为。利用早期发送的回复和退信结果，随时间建立域名级别的抑制和纳入列表。
Catch-all 状态会随时间变化吗？
会。六个月前是 catch-all 的域名，其配置可能已经改变。对任何闲置超过 60 至 90 天的列表重新验证。Catch-all 行为是服务器端配置——可以在不通知发件人的情况下启用或禁用。