企业邮箱迁移通常从创建新账号开始，却常常在 DNS 和发信认证上留下隐患。MX 记录切到新系统后，收信可能已经正常，但网站表单、账单系统、营销工具、客服平台和旧应用仍可能从旧系统发信。反过来，SPF 列出了旧授权，DKIM 选择器没有发布，或 DMARC 仍然对齐失败，都会让收件方把正当邮件当作可疑邮件。迁移验收要把收信、发信、转发、退信、认证和旧域名入口拆开验证，并让每一个失败结果都有负责团队。
明确迁移对象和邮件流向
先列出所有会收发邮件的域名和子域名，包括主域名、通知域名、营销域名、招聘域名、客户服务域名和停放域名。为每个域名记录收件系统、正当发信源、转发规则、邮件联系人、业务重要性和切换时间。把用户邮箱、共享邮箱、别名、自动回复、归档、移动客户端、外部 SMTP 和应用 API 分开列出。不要只依赖平台向导中的“已连接”状态，平台连接成功不等于外部收件人会接受每一种业务邮件。
- 每个域名和子域名的收信、发信用途
- MX 目标和优先级、旧系统保留时间
- 网站、应用、营销和第三方服务的发信源
- SPF 记录、DKIM 选择器和密钥切换时间
- DMARC 策略、rua 地址和报告负责人
- 回滚条件、退信处理和客户通知计划
先切换收信，再验证发信
MX 记录决定接收方把邮件送到哪里，但 DNS 改变需要经过缓存和不同解析位置的观察。切换前保存旧 MX、TTL 和当前收件系统，切换后从多个公开位置确认新 MX，并使用外部测试地址分别测试新用户邮箱、共享邮箱、别名、转发和不存在的地址。检查退信是否到达正确的发件人，是否出现重复投递或旧系统仍在接收的情况。临时并行接收时要明确结束时间，否则旧系统会长久保存敏感邮件并让排障变得困难。
收信测试通过后，再逐个测试网站表单、账单、密码重置、通知、营销和人工客户端的发信。每封测试邮件记录 From、Return-Path、Received、Authentication-Results、DKIM-Signature 和时间，避免只看收件箱是否出现。若消息经过转发或中转，邮件内容可能被修改，SPF 结果也可能变化。把转发链、邮件头和实际到达情况作为独立证据保存。
用 SPF 盘点正当发信源
SPF 是 DNS 中的授权声明，不是邮件内容的加密签名。迁移时先把新邮箱平台、客服系统、账单系统、营销系统、网站服务器和其他合法服务列入发信源清单，再核对它们是否需要 IP、include 或其他机制。删除旧授权前要确认没有仍在运行的定时任务，否则迁移后会出现间歇性失败。还要注意 SPF 的查询限制、嵌套 include、宏和多个 SPF 记录等结构问题。验证结果应记录是授权、语法错误、暂时不可取还是未请求，不要把一次失败自动解释成恶意来源。
用 DKIM 和 DMARC 验证身份对齐
DKIM 通过签名域名和选择器让接收方验证消息没有被意外修改，但发布公钥只是准备工作，还要检查真实邮件的 d= 是否正确。DMARC 关注 From 域名与 SPF 或 DKIM 认证域名是否对齐：至少一个机制通过并且对齐，消息才可能通过 DMARC。Microsoft 官方建议先以 p=none 观察，再逐步提高到 quarantine 和 reject，以便发现正当邮件的失败。迁移期间要特别检查新旧平台是否使用不同的 Return-Path、签名域名、子域名或发信地址。
_dmarc.example.cn. IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]"DMARC 报告能帮助团队发现未知发信源和认证失败，但报告覆盖不一定完整，且不同接收方的提交方式不同。按 source IP、From 域名、DKIM d=、选择器、SPF 域名、消息数量和策略结果聚合，逐项与发信源台账核对。未知来源不应立刻被标为攻击，可能是旧应用、转发、外包服务或配置遗漏；已确认的正当来源则应明确修复负责人和完成时间。
保留回滚和切换后的再验证
邮箱迁移的回滚不仅是把 MX 改回旧值。还要恢复旧平台的账号或转发、旧发信源、DKIM 密钥、应用凭证、自动回复和退信处理。为每个动作设置时间窗口和负责人，明确哪些邮件可能在两套系统之间分流，必要时保留可审计的临时转发。正式切换后至少在低流量和高流量时段各做一次收发验证，检查外部主要收件方、附件、链接、退信和自动处理规则。
上线后持续观察 DMARC 报告、退信率、投诉、发信量和认证结果。不要因为 DNS 已经显示新记录就关闭旧域名的风险检查，旧域名可能仍被用户用于回复、密码重置或历史链接。对于不再发送邮件的停放域名，Microsoft 官方也建议发布拒绝来自该域名的邮件的 DMARC 记录，但实施前要确认没有遗留业务。每次新增应用或第三方服务，都重新检查 SPF、DKIM 和 DMARC 对齐。
把检查接入企业运维流程
迁移一个域名可以手工完成，管理几十个域名或多个业务团队时，应把公开配置和测试结果结构化。DomScan 的邮件安全检查、SPF 构建器、DKIM 发现、DMARC 构建器和 DNS 查询可以帮助团队从单个域名开始核对，再把结果接入变更工单。批量 API 处理时要保留域名、记录类型、观察时间、认证状态、未知原因和原始证据，不要只返回一个“邮件安全分数”。监控系统自身失败时也应产生单独事件，避免把没有更新的结果当成通过。
验收完成的标准不是所有邮件永远通过，而是正当发信源有台账、收发路径有测试、SPF 和 DKIM 的对齐结果可解释、DMARC 策略变更有批准和回滚方案、未知状态有人跟进。这样即使迁移后出现新的服务或收件方行为变化，团队也能用同样的方法定位差异，而不是重新从 DNS 页面和零散邮件头开始猜测。