Instantly 运行活动，BillionVerify 在活动开始前验证名单。
Instantly 是一个冷邮件平台。它管理收件箱轮换、预热序列、活动调度以及大规模多收件箱出站邮件。它做得很好。
BillionVerify 是一个发送前验证层。它在任何记录进入发件工具之前，按信号类型对邮件记录进行分类——有效、无效、catch-all、角色型、未知、一次性。它不运行活动。
这些是不同的问题。Instantly 无法替代 BillionVerify，BillionVerify 也无法替代 Instantly。它们处于工作流程的不同位置：BillionVerify 在 Instantly 导入前运行；一旦经过验证的名单准备好，Instantly 接管。
冷邮件验证框架
本页面介绍单个发件工具或工作流。完整框架涵盖从名单来源到验证、分组，再导入发件工具的全流程。
Instantly 处理的事项。
Instantly 管理发送层，提供：
- 跨专用冷邮件域名的多收件箱活动轮换
- 具有可配置发送速度和池的邮箱预热
- 序列调度、跟进自动化和回复检测
- 活动分析、打开和点击跟踪
- 面向团队和机构的多账户管理
Instantly 还包括基本的名单质量功能，处理明显的格式错误和一些无效地址模式。
Instantly 内置功能无法替代的内容：
- 跨所有名单和数据源一致应用的导入前 catch-all 分类策略
- 在任何序列步骤运行之前应用的角色型地址检测
- 跨活动和导入持久存在的抑制管理，不仅限于单个活动内
- 高发量轮换开始之前的未知地址分类
- 在名单进入 Instantly 界面之前运行的验证结果
Instantly 的名单质量功能在平台上下文中应用。通过 BillionVerify 进行的专用导入前过程在 Instantly 看到名单之前——在来源处，而不是在发件工具内部——应用一致的策略。
BillionVerify 处理的事项。
BillionVerify 在名单进入任何发件工具之前应用发送前质量门控，提供：
- 信号分类：有效、无效、catch-all、角色型、未知、高风险、一次性
- Catch-all 检测：识别在域名级别接受所有地址的域名，以便单独分类
- 角色型检测：在共享收件箱进入命名联系人序列之前进行标记
- 抑制管理：跨活动和导入导出并维护抑制名单
- 域名和 MX 级别检查：识别发送域名本身无效或配置错误的记录
BillionVerify 不运行活动，不管理收件箱、预热序列或活动调度。
工作流程边界。
| Instantly 做的事 | BillionVerify 做的事 |
|---|---|
| 管理收件箱轮换和发送 | 按送达率信号对记录进行分类 |
| 运行预热序列 | 在导入前识别 catch-all 域名 |
| 调度活动和跟进 | 在序列运行前标记角色型地址 |
| 跟踪打开、点击和回复 | 从验证结果构建抑制名单 |
| 管理多账户工作空间 | 导出已批准和拒绝的记录分类 |
| 处理发送基础设施 | 在任何发送基础设施介入之前运行 |
组合工作流程。
从来源收集名单
→ 通过 BillionVerify 验证
→ 按信号类型路由结果
→ 将已批准的记录导入 Instantly
→ 使用 Instantly 启动活动
顺序很重要。验证在 Instantly 导入之前进行，因为导入是一个承诺点——一旦名单进入活动内，活动压力和序列自动化使得停止并移除弱记录变得更加困难。BillionVerify 在这个承诺之前创造了正确的阻力，而不是之后。
在 Instantly 导入前路由每个结果。
| BillionVerify 结果 | Instantly 导入前行动 |
|---|---|
| 有效 | 导入目标活动或邮箱轮换 |
| 无效 | 不导入——添加到抑制名单 |
| Catch-all | 单独活动，较低发量，密切监控投递 |
| 角色型 | 包含共享收件箱消息的单独活动 |
| 未知 | 保留以供人工审查——从高发量序列中排除 |
| 高风险或一次性 | 不导入 |
Instantly vs Smartlead
两者都支持规模化发送，但都无法替代导入前的名单验证。
GMass vs Mailmeteor
两者都通过 Gmail 发送，了解两者名单风险的差异所在。
Salesloft vs Outreach
企业级发件工具，导入流程不同，但都需要导入前验证。
Lemlist vs Smartlead
多渠道外拓 vs 送达率优先发送，名单质量在两者中都至关重要。
Mailshake vs Reply.io
渠道模式不同的中小企业外向工具，了解发送前的差异。
Instantly vs Lemlist
规模优先 vs 个性化优先发送，验证在每种模式中的作用。
Smartlead vs BillionVerify 名单清洗对比
大批量发送仍需独立的名单清洗，原因在此。
GMass vs BillionVerify 邮件验证对比
Gmail 发送和专用邮件验证解决的是不同层面的问题。
Lemlist vs BillionVerify
多渠道外拓与名单验证是互补关系，而非替代关系。
Mailshake vs BillionVerify
外向发送与发送前验证属于同一工作流，而非竞争关系。
Gmail 发件 vs 冷邮件基础设施
Gmail 原生发件与专用冷邮件基础设施的名单风险特征不同。
Instantly vs BillionVerify 常见问题。
Instantly 的内置验证够用吗？
Instantly 的内置功能处理基本的名单卫生。通过 BillionVerify 进行专用导入前验证添加了 catch-all 分类、角色型检测和一致的抑制策略，这些在名单进入 Instantly 之前运行。对于高发量活动（少量坏记录产生大量退信），额外的验证层很重要。
使用 Instantly 还需要 BillionVerify 吗？
Instantly 和 BillionVerify 不是互相替代的。Instantly 运行活动。BillionVerify 在活动设置之前验证名单。如果你运行高发量出站邮件、从多个提供商获取名单或管理多个客户活动，导入前验证可以降低任何单个名单带入轮换的退信风险。
两者对 catch-all 的处理有何不同？
Instantly 向 catch-all 地址发送邮件，不自动分类它们。BillionVerify 识别 catch-all 域名并标记这些记录，这样你就可以在它们进入 Instantly 之前将其路由到单独的低发量活动。分类决定由你做出，由 BillionVerify 的分类结果提供依据。
何时应该在重新导入 Instantly 之前重新验证名单？
在导入或重新激活任何超过 90 天的名单之前重新验证。无论名单是否在之前的 Instantly 活动中运行过，还是一直存储在电子表格中，这都适用。邮件有效性独立于活动历史而变化——6 个月前表现良好的名单可能包含相当数量不再有效的地址。
BillionVerify 是否直接与 Instantly 集成？
BillionVerify 以导出形式提供验证结果，你在验证过程后导入到 Instantly。工作流程是：使用 BillionVerify 验证，导出已批准的记录，导入 Instantly。没有改变这一顺序的应用内集成——验证在 Instantly 之前运行，而不是在其内部。