Mailshake 运行活动，BillionVerify 在活动开始前验证名单。
Mailshake 是一款外发邮件平台，为中小型团队和个人销售人员提供邮件序列自动化、跟进计划、回复检测和活动分析，让简单、快速的外发推广成为可能。
BillionVerify 是预发送验证层，在任何记录进入发送工具之前，按可送达性信号对邮件记录进行分类——有效、无效、catch-all、角色邮箱、未知、一次性。它不运行活动，也不管理邮件序列。
Mailshake 和 BillionVerify 并非替代关系，它们解决的是同一问题的不同部分。BillionVerify 在名单进入 Mailshake 之前运行；Mailshake 在名单准备好之后运行活动。
冷邮件验证框架
本页面介绍单个发件工具或工作流。完整框架涵盖从名单来源到验证、分组，再导入发件工具的全流程。
Mailshake 负责的内容。
Mailshake 管理发送和序列层面，提供：
- 带跟进计划的邮件序列自动化
- 使用联系人数据字段进行个性化
- 回复检测和线索状态管理
- 打开、点击和回复追踪
- 与 Gmail、Outlook 和自定义 SMTP 集成
Mailshake 也包含基础的名单卫生功能，可以处理部分无效地址模式。
Mailshake 无法替代的功能：
- 在序列配置前一致应用的 catch-all 分类策略
- 在个性化外发序列运行前进行角色邮箱地址检测
- 在任何活动步骤开始前进行未知地址细分
- 独立于 Mailshake 跨活动持久保存的屏蔽管理
- 在名单进入 Mailshake 导入界面之前运行的独立验证
使用 Mailshake 的小型团队通常只用一个发送域名，没有收件箱轮换或域名池来分摊退信损害——每次退信都会影响同一个域名。对于只有一两个发送地址的团队来说，一份糟糕的名单即使只产生少量硬退信，也会造成不成比例的声誉损害。发送资产越少，退信预算就越小，而非越大。
BillionVerify 负责的内容。
BillionVerify 在记录进入 Mailshake 之前应用预发送质量门控，提供：
- 信号分类：有效、无效、catch-all、角色邮箱、未知、高风险、一次性
- Catch-all 检测：识别在域名层面接受所有地址的域名
- 角色邮箱检测：在共享收件箱收到个性化外发序列之前进行标记
- 屏蔽管理：跨活动导出并维护屏蔽名单
- 域名和 MX 级别检查：识别发送域名无效或配置错误的记录
BillionVerify 不运行活动，也不管理 Mailshake 序列。
工作流程的职责边界。
| Mailshake 负责 | BillionVerify 负责 |
|---|---|
| 运行邮件序列和跟进 | 按可送达性信号对记录分类 |
| 管理回复检测和线索状态 | 在导入前识别 catch-all 域名 |
| 追踪打开、点击和回复 | 在序列运行前标记角色邮箱地址 |
| 通过 Gmail、Outlook 或 SMTP 发送 | 根据验证结果构建屏蔽名单 |
| 处理退订 | 导出已批准和已拒绝的记录细分 |
| 管理活动计划 | 在任何发送工具介入之前运行 |
组合工作流程。
从来源收集名单
→ 通过 BillionVerify 验证
→ 按信号类型路由结果
→ 将已批准记录导入 Mailshake
→ 使用 Mailshake 启动活动
对于从单一发送域名运营的小型团队来说，导入前验证是防范退信损害的主要防线。没有收件箱轮换，没有域名池，发送域名一旦受损也没有简单的方式轮换资产。跳过验证的代价相对于团队规模而言是更高的，而非更低。
在导入 Mailshake 前路由每个结果。
| BillionVerify 结果 | Mailshake 导入前的操作 |
|---|---|
| 有效 | 导入 Mailshake 活动 |
| 无效 | 不要导入——添加到屏蔽名单 |
| Catch-all | 单独活动，较低发送量，密切监控 |
| 角色邮箱 | 针对共享收件箱收件人调整文案的单独活动 |
| 未知 | 暂停待人工审查——排除在自动化序列之外 |
| 高风险或一次性 | 不要导入 |
Instantly vs Smartlead
两者都支持规模化发送，但都无法替代导入前的名单验证。
GMass vs Mailmeteor
两者都通过 Gmail 发送，了解两者名单风险的差异所在。
Salesloft vs Outreach
企业级发件工具，导入流程不同，但都需要导入前验证。
Lemlist vs Smartlead
多渠道外拓 vs 送达率优先发送，名单质量在两者中都至关重要。
Mailshake vs Reply.io
渠道模式不同的中小企业外向工具，了解发送前的差异。
Instantly vs Lemlist
规模优先 vs 个性化优先发送，验证在每种模式中的作用。
Instantly vs BillionVerify 验证对比
Instantly 内置验证是否足够，还是需要专用的发送前门控？
Smartlead vs BillionVerify 名单清洗对比
大批量发送仍需独立的名单清洗，原因在此。
GMass vs BillionVerify 邮件验证对比
Gmail 发送和专用邮件验证解决的是不同层面的问题。
Lemlist vs BillionVerify
多渠道外拓与名单验证是互补关系，而非替代关系。
Gmail 发件 vs 冷邮件基础设施
Gmail 原生发件与专用冷邮件基础设施的名单风险特征不同。
Mailshake 对比 BillionVerify 常见问题。
Mailshake 内置的验证功能够用吗？
Mailshake 包含基础的名单卫生功能。通过 BillionVerify 进行专门的导入前验证，可以在名单进入 Mailshake 之前额外提供 catch-all 分类、角色邮箱检测和屏蔽策略。对于从单一发送域名运营的小型团队来说，这层额外保护至关重要——当退信损害集中在单一资产上时，容错空间更小。
使用 Mailshake 是否还需要 BillionVerify？
Mailshake 和 BillionVerify 用途不同。Mailshake 运行活动，BillionVerify 在活动建立前验证名单。如果您是从一两个发送地址开展外发的小型团队，导入前验证可以降低一份糟糕名单损毁唯一发送基础设施的风险。
小型团队使用 Mailshake 与大型发件人的退信风险有何不同？
大型发件人拥有专用的冷邮件基础设施，可以将退信风险分散到多个域名和邮箱中。如果一个域名受损，可以轮换掉。使用 Mailshake 从单个 Gmail 或企业域名运营的小型团队没有轮换机制——每次退信都打击同一个声誉池。这使得 Mailshake 用户的导入前验证更加重要，而非更不重要。
在 Mailshake 中应如何处理 catch-all 地址？
将 catch-all 结果分配到单独的低发送量活动中，在添加更多 catch-all 联系人之前监控投递率。当您从单一域名发送时，不要将 catch-all 地址与确认有效地址混入同一活动。在有限轮换发件人的情况下，不确定的投递模式积累速度比多收件箱设置要快得多。
在 Mailshake 活动前应多久重新验证一次名单？
超过 90 天的名单在导入或活动重启前应重新验证。之前的 Mailshake 活动表现并不能确认当前地址的有效性。6 个月前运行良好的名单，可能因为职位变动、域名过期或收件箱配置变更，而包含已不再有效的地址。