更换邮件服务商后客户收不到信，AI能从SPF、DKIM和DMARC结果定位配置问题吗？

邮件平台迁移后，内部互发正常，客户却开始报告收不到报价。管理员看过DNS记录，觉得SPF已经添加，问题应该在客户那边。实际发送报价的CRM可能还在走另一条路径，新平台测试通过不能说明它也通过。

AI适合整理发信路径、头信息与退信证据。以下域名用保留示例域表示，不提供可直接覆盖生产的DNS配置。所有变更需要管理员审核和可回退安排。

先查邮件在哪里停止

收集发送时间、消息标识、发信系统、收件域、平台投递日志及完整退信代码。SMTP接受、进入垃圾箱和真正未投递是不同情况，客户说没看见不能直接判为服务器拒收。日志中的成功也可能只代表下一跳接收，并非到达用户收件箱。

把人发邮件、CRM、工单、营销平台与旧服务商分别列出，记录发件域和实际发送出口。子域或别名也要检查，不拿主域一封成功测试覆盖全体路径。平台迁移范围与DNS变更日期对齐，有助于找出只有某条路径失败的案例。

incident-response可帮助整理事件范围、时间线和假设验证，职责是协助事件处理，不是自带DNS修复器。给AI脱敏后的头信息和日志，隐藏正文、客户地址及令牌，不把私人报价附件用于诊断。

SPF核对发送主机与信封发件域，DKIM核对签名及签名域，DMARC还需要验证身份与可见From域满足适用对齐方式。SPF显示通过，不等于DMARC必然通过；签名存在，也不等于接收端验证通过。以可信接收端的验证结果为依据，不能只看发送方自己写的头字段。

检查Return-Path、From、DKIM签名中的域与selector，并核对接收端Authentication-Results。域对齐可以有严格或宽松设置，子域关系按实际配置解释。转发路径可能改变SPF结果，内容修改可能影响签名，需要逐条验证而不是一句全部配置错了。

假设可见From使用example.com，信封域为mailer.example.net，接收端报告SPF通过，但签名失败。SPF验证了另一个域，无法仅凭这个通过结果证明与example.com对齐。管理员需要检查可见域的签名或经过批准的信封域方案，不能只再加一个SPF记录。

核对每个发信服务商的官方配置要求及已发布记录。SPF授权要覆盖实际出口并避免冲突，DKIM核对selector、公钥记录和服务商是否已经启用签名。新记录发布之后仍需实际发送并读取接收结果，控制台显示已保存只证明保存动作。

旧服务商尚有延迟任务时，不能过早删除旧授权或签名记录；也不能无限保留不再使用的发信权限。建立迁移清单与切换时间，确认所有业务路径完成测试后按批准方案收口。DNS缓存和生效时间记录在案，不把每次暂时差异都解释为相同原因。

DMARC策略调整应权衡保护和投递风险。不要为了收到一封报价就长期关闭验证，也不要未经观察直接把严格策略推到所有未知发信系统。AI可以列测试方案，实际记录由管理员修改，重要邮件系统采用变更审批。

从不同真实发信系统发送无敏感内容的测试，检查目标接收端的退信、头信息和收件位置。正常路径、别名、子域及必要的转发路径分开记录，测试账号不代表所有客户平台。对仍失败的路径保留同一消息标识，避免把不同测试混成一条链。

修复前后只改变确认过的因素，保留DNS快照与回退条件。若身份验证已通过但仍被过滤，继续查信誉、内容、速率和接收方限制，不把DMARC通过描述为必进收件箱。营销与交易邮件的使用限制也需按服务商最新要求核对。

交付每个系统的出口、域、selector、验证结果、异常和负责人。内部发送正常不是外部投递验收，平台交付也不替代业务系统验收。所有关键路径都有证据后才关闭事件，仍未知的来源保留监测任务。

后续新增发信平台时，将身份配置与真实投递测试纳入上线清单。配置文档只保存公钥与必要记录，不保存私钥或密码。这样下一次出现客户收不到信时，可以按路径查哪项验证失败，而不必重复争论DNS已经配过了。