Mailforge 配置基础设施，但不筛选联系人名单。
Mailforge 管理发送层：配置域名和邮箱、处理预热、在活动中轮换发件身份。它构建和维护冷邮件活动运行所需的基础设施。
Mailforge 不做的事情是检查你活动将要目标的邮件地址是否真实存在或是否应该被联系。这个决定发生在名单层面，在任何记录进入 Mailforge 管理的发送基础设施之前。
这是同一冷邮件工作流程中两项不同的职责。Mailforge 负责发送层。BillionVerify 负责名单层。两者互不替代，都是冷邮件基础设施投入产生一致、可预测活动结果所必需的。
Mailforge 管理的内容——以及它不处理的内容。
| Mailforge 处理的事项 | Mailforge 不处理的事项 |
|---|---|
| 为冷邮件配置域名和邮箱 | 检查单个邮件地址是否可投递 |
| 为新发送基础设施设置预热序列 | 从联系人名单中移除无效、catch-all 或角色型记录 |
| 跨多个域名和邮箱的发送轮换 | 在联系人记录进入发送系统之前按风险分类 |
| 收件箱放置基础设施管理 | 为退信或退订联系人维护抑制文件 |
| 技术发送设置和 DNS 配置 | 导入前名单资格审查决策 |
Mailforge 是基础设施工具。它提供的价值——健康的发送域名、已预热的邮箱、保护个别收件箱健康的轮换——取决于这些域名和邮箱用于触达的联系人数据质量。
糟糕的名单质量不会停留在名单层面。它会向下游流入 Mailforge 构建的基础设施。来自无效地址的退信信号会降低预热努力建立的域名声誉。来自角色型收件箱的投诉会削弱轮换中邮箱的发送健康状况。
为何没有名单质量的基础设施投入是浪费的。
通过 Mailforge 构建冷邮件基础设施需要时间和持续管理。域名预热通常需要 4 到 8 周，域名才能准备好达到完整活动量。在多个邮箱之间设置轮换、配置 DNS 记录并建立干净的发送模式代表真实的运营投入。
当进入基础设施的联系人名单未经过资格审查时，这种投入就被破坏了。3,000 个联系人名单中的几百个无效记录可以产生足够的硬退信，损害新预热的域名。花了六周预热的域名，如果名单质量从未得到解决，可能在单次活动内看到其收件箱放置率下降。
基础设施是可靠的，名单是变量。验证在变量到达基础设施之前解决它。
组合工作流程：验证，然后通过 Mailforge 发送。
验证在每个名单的上游 Mailforge 层之前运行一次。Mailforge 从那时起处理发送机制。名单决定和基础设施决定是独立的——每个都应有明确的负责人。
在进入 Mailforge 配置的基础设施之前路由每个结果。
| BillionVerify 结果 | 通过 Mailforge 发送前的行动 |
|---|---|
| 有效 | 导入活动联系人名单 |
| 无效 | 不导入——退信损害 Mailforge 构建的域名声誉 |
| Catch-all | 单独的低发量分类，按域名密切监控 |
| 角色型 | 单独的消息发送渠道——弱参与度损害收件箱放置信号 |
| 未知 | 保留以供人工审查——在做出路由决定前排除 |
| 高风险或一次性 | 不导入 |
应用类似决策的其他工作流程。
Mailforge 和 BillionVerify 工作流程常见问题。
如果 Mailforge 预热了我的发送域名，我还需要名单验证吗？
是的。预热通过建立正面发送信号的历史来建立域名声誉。来自无效记录的退信产生与预热进程相悖的负面信号。即使是预热良好的域名也会因硬退信而遭受声誉降级。验证确保进入预热基础设施的地址不会产生破坏预热投入的退信信号。
名单验证需要直接与 Mailforge 集成吗？
不需要。最常见的方法是导出联系人名单，通过 BillionVerify 运行，然后只将有效分类导入连接到 Mailforge 基础设施的活动平台。验证在发送系统之外进行。BillionVerify 和 Mailforge 之间不需要集成——价值在于导入前决定，而非工具之间的连接。
我可以通过 Mailforge 向 catch-all 地址发送吗？
可以，但它们应该被视为单独的低发量分类。Catch-all 地址具有不确定的投递风险——域名接受邮件，但特定邮箱可能不存在。向 catch-all 地址发送较低发量并监控每个发送域名的结果，有助于你识别哪些域名成功投递，哪些产生静默失败或延迟退信。不要将 catch-all 记录与已确认有效地址混在同一活动轮换中。