不要因为冷邮件供应商演示得漂亮，就直接把生产域名接进去、把真实潜客名单上传。这个工具会进入身份、数据、消息和销售工作流，因此采购阶段就应该测试：坏数据会怎样、退订会怎样、DNS发生变化会怎样、真人回复又会怎样。
下面25问可以直接做验收清单。
数据与来源：1—6
1. 产品使用哪些联系人数据来源？ 哪些是公开、授权、客户提供、哪些只是推断。
2. 每条记录的来源与新鲜度能不能一起导出？ 只有UI里的分数很难审计。
3. “verified email”在这个产品里具体是什么意思？ 语法、域名接收、SMTP行为、历史送达、直接确认是不同信号。
4. 发现错误后怎么修？ 销售发现联系人已经换公司，能否更正同时保留历史。
5. 能否区分“公司适合”和“这个人适合”？ 公司是ICP但联系人错误，仍然是坏发送。
6. 不同导入与工作区之间怎么查重？ 重复记录可能绕过频率与抑制。
用途、政策与地区：7—10
7. 供应商条款明确允许哪些发送用途？ 能技术上做到，不等于平台允许这样用。
8. 企业需要不同地区规则时，能否按司法辖区路由或限制记录？
9. 系统能否保存企业希望关联到联系人的业务理由、来源或其他证据？
10. 哪些字段与消息元素支持企业需要的身份信息和退订流程？
FTC的CAN-SPAM是美国商业邮件的重要官方参考，也明确B2B并不是整体豁免。其他司法辖区不同。工具应该提供控制，但企业仍要针对自己的市场获得适当判断。
域名与认证：11—15
11. 供应商会要求新增或修改哪些DNS记录？ 要具体示例。
12. 谁管理SPF范围，如何避免重复或过度授权？
13. DKIM怎么配置和轮换？ 选择器与责任人要记录。
14. 工具怎么与已有DMARC策略共存？ 不应该为了“更容易发送”随意弱化政策。
15. 有没有回滚方案？ 如果配置影响正常业务邮件，组织必须能快速恢复。
M3AAWG的资料很适合理解认证为什么重要，也提醒认证不等于证明内容合法或受欢迎。
发送控制：16—18
16. 邮件实际从哪里发出？ 客户邮箱、供应商基础设施、中继还是第三方？
17. 产品里实际执行哪些服务商限制与政策？ Google、Yahoo、Microsoft都有与发送相关的官方要求或限制。
18. 哪些情况会自动停止？ 认证失败、退信突然升高、平台阻止、投诉信号、异常发送量等是否有规则。
供应商只说“无限发送”却解释不了接收平台政策，应该增加疑问，而不是增加好感。
抑制与退订：19—21
19. 抑制是同一业务目的下全局生效，还是只对某个序列有效？
20. 被抑制邮箱能不能因为再次导入而意外恢复？ 必须现场测试。
21. 抑制事件能否连时间、来源、原因一起导出？ 换平台以后不能丢掉历史。
不要只看截图。用测试邮箱退订，再从第二份名单导入，再尝试加入新序列，真正看系统会不会拦。
回复与审计：22—25
22. 收到真人回复后自动化是否停止？ 正向、拒绝、自动回复分别测试。
23. 回复能否连同原始对话完整分配给指定销售？
24. 能否导出完整事件日志？ 发送、退信、回复、退订、抑制、规则变化与用户操作都应该能查。
25. 域名、数据与日志退出计划是什么？ 企业需要知道怎样断开基础设施并带走记录，尤其不能丢掉抑制历史。
做五组沙盒验收
先只用受控测试记录。
A组测试坏数据：一个无效邮箱、一个重复记录、一个缺必要字段的记录，看系统是警告、阻止还是静默排队。
B组测试认证：连接测试子域，记录每个DNS变化，再故意破坏一个预期设置，看监控是否能发现，而不是继续盲发。
C组测试退订：发到测试邮箱，执行退订，再导入、再尝试加入，检查所有相关路径是否抑制。
D组测试真人回复：正向回复，看自动化是否停止、负责人是否切换、原对话是否进入CRM或销售队列。
E组测试导出：把联系人、来源字段、抑制、事件日志和活动配置导出，确认企业脱离供应商帮助也能看懂。
如何评分
每一问标为“已演示”“有文件但未演示”“不清楚”。没有亲自测试的控制，不要因为演示很顺就当作已经验证。
域名回滚、抑制、事件导出和回复交接权重应该更高，因为这些地方失败会影响不止一个活动。一个UI小功能缺失可以以后补，无法保留退订不应该带着上线。
同时核对事故升级路径。收到服务商警告、发现认证被改时，多久能联系到真正懂发送架构的人？最好在出事故之前就知道答案。
最后的采购边界
冷邮件供应商不是企业的律师、数据治理部门或销售经理。工具可以提供控制、记录和自动化，但企业仍然负责决定在哪些地方、用什么方式发送，负责检查当前法律与平台要求，也负责目标人群和offer质量。
这条边界不意味着不能用工具，反而意味着采购应该更严谨。当系统能证明数据来源、展示域名配置、强制抑制、回复即停、导出审计轨迹时，企业获得的是控制。如果所有困难问题最终都是“AI会自动处理”，买方其实没有一套可以依赖的运营模型。
只有沙盒全部通过以后，再连接真实域名与真实名单。规模应该是最后一步，而不是用真实客户来验证系统能不能工作的第一步。
每一项供应商承诺旁边都写上内部负责人
供应商演示的每一项功能，都要明确上线后公司内部由谁负责。数据来源需要数据或销售运营负责人；DNS与认证需要技术负责人；抑制名单需要运营负责人；回复路由需要销售负责人；跨境规则需要合适的法务或合规负责人。如果每一个控制都被认为“归供应商负责”，一旦两套工具或两项政策发生冲突，企业会立刻陷入被动。
还要记录每项控制是预防型还是侦测型。阻止已被抑制的联系人再次进入发送属于预防控制；对退信率异常发出告警属于侦测控制。两者都重要，但解决的是不同问题，不能互相替代。
清晰的负责人地图也能让供应商升级处理更快，因为公司在开支持工单前，就能先判断事故属于数据、基础设施、政策还是销售路由问题。
Sources
- https://www.ftc.gov/business-guidance/resources/can-spam-act-compliance-guide-business — U.S. Federal Trade Commission, CAN-SPAM compliance guide for commercial email, including B2B email.
- https://support.google.com/mail/answer/14229414 — Google Gmail sender guidelines / FAQ for bulk senders and personal Gmail accounts.
- https://senders.yahooinc.com/best-practices/ — Yahoo Sender Hub best practices for senders.
- https://www.m3aawg.org/published-documents — Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG), current published best-practice documents.
- https://www.m3aawg.org/TechnologySummaries/EmailAuthentication — M3AAWG summary of email authentication and its limits.
- https://www.m3aawg.org/TechnologySummaries/DMARC — M3AAWG DMARC technology summary.
- https://techcommunity.microsoft.com/blog/exchange/introducing-exchange-online-tenant-outbound-email-limits/4372797 — Microsoft Exchange Team, updated August 13, 2026, on Exchange Online tenant outbound email limits.