Hunter 和 BillionVerify 服务于同一工作流的不同步骤。
Hunter 是一款基于域名的邮件查找工具。你给它一个公司域名，它通过结合公开可见的模式与网络上的联系人数据返回邮件地址。Hunter 还包含内置验证器——当你找到一个地址时，Hunter 会根据域名配置和已知模式检查它是否看起来合理。
BillionVerify 在导入时提供独立的 SMTP 级检查。当你上传列表时，BillionVerify 连接到每个域名的邮件服务器，确认邮箱当前是否接受投递。该检查发生在你运行它的那一刻——而不是 Hunter 最初收集地址的时候。
两个工具处于不同阶段。Hunter 处理发现和第一轮合理性检查。BillionVerify 在列表进入发件工具或 CRM 之前提供最终的投递能力关卡。同时使用两者的团队能从 Hunter 获得来源覆盖，并在任何发送之前从 BillionVerify 获得当前确认。
Hunter 做什么 vs BillionVerify 做什么。
| 维度 | Hunter | BillionVerify |
|---|---|---|
| 用途 | 查找公司域名的邮件地址；验证格式和域名模式 | 在 SMTP 级别验证列表的当前投递能力 |
| 工作方式 | 结合域名模式、公开来源和模式匹配 | 连接到接收邮件服务器，检查邮箱是否接受投递 |
| 输出 | 带有置信度分数和"已验证"或"未验证"标签的邮件地址 | 每个地址的结果：有效、无效、全接收域、角色型、未知、临时邮件 |
| 何时使用 | 从目标公司域名构建潜在客户列表 | 在将列表导入 CRM、发件工具或外发序列之前 |
| 无法做什么 | 确认邮箱当前是否活跃或自采集以来是否已更改 | 从头开始来源或查找邮件地址 |
Hunter 验证在哪里结束，BillionVerify 在哪里开始。
Hunter 的验证检查地址在语法上是否有效以及域名的 MX 记录是否已配置。它还使用模式置信度将地址标记为更多或更少可能是正确的。
Hunter 验证不做的事：它不连接到单个邮箱并询问投递现在是否会成功。这一差距很重要，因为邮箱会关闭、员工会离职，域名会在 Hunter 收集地址和你发送之间重新配置邮件服务器。
| Hunter 验证结果 | 含义 | BillionVerify 补充了什么 |
|---|---|---|
| 已验证 | 格式有效，域名接受邮件，模式匹配 | 特定邮箱当前是否接受投递 |
| 未验证 | 模式置信度低或域名无法检查 | 确定性的 SMTP 结果——有效、无效或全接收域 |
| 全接收域 | 域名接受所有地址，不管它们是否存在 | 每地址分组，使全接收域地址单独处理 |
| 无 MX 记录 | 域名没有配置邮件服务器 | 已确认无效，可以安全抑制 |
Hunter 的"已验证"标签是数据采集步骤的质量信号。BillionVerify 的 SMTP 检查是发送就绪步骤的投递确认。两者都有用；它们回答不同的问题。
Hunter 中的"已验证"与 BillionVerify 中的含义对比。
Hunter 和 BillionVerify 都使用"已验证"这个词，但含义不同。理解这一区别能防止此工作流中最常见的错误——将 Hunter 的已验证标签视为发送就绪信号。
- Hunter "已验证"：地址与域名的已确认邮件模式匹配，MX 记录已配置，格式验证通过。此检查在 Hunter 索引数据时运行。
- BillionVerify "有效"：建立了到接收邮件服务器的 SMTP 连接，服务器确认特定邮箱接受投递。此检查在导入时运行——独立于 Hunter。
Hunter 的已验证标签告诉你地址在采集时看起来合理。BillionVerify 的有效结果告诉你地址现在可以投递。两者关于各自测量的内容都是正确的陈述——在不同时间，使用不同方法。
Hunter 导出中的具体风险。
Hunter 擅长查找给定域名最常见的邮件模式。这一优势引入了其自身的风险特征——最常见的模式不总是当前模式，而可信的模式不等于已确认的邮箱。
| 风险 | 来源 | 影响 |
|---|---|---|
| 过时地址 | Hunter 最后一次数据更新后离职的员工 | 发送时硬退信 |
| 全接收域 | 在服务器级别接受所有传入邮件的公司 | 不确定的投递，列表大小虚增 |
| 角色型收件箱 | 通用公司搜索返回的 、、 |