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