邮箱迁移指南：安全完成 DNS 与 MX 切换

如何将邮箱迁移到新服务商（DNS 切换指南）

在邮件服务商之间迁移邮箱时，顺利切换与停机 48 小时之间的差别往往取决于 DNS 策略。错误的 TTL 或遗漏的 SPF include 都可能造成永久退信和业务损失。

这项工作不能依靠临场发挥，而要按准确顺序执行技术操作。本指南说明如何考虑传播计时、合并 SPF、DKIM 和 DMARC 身份验证，并将邮件路由至新服务商，以尽量降低丢失邮件的风险。

实际搬迁邮件数据的方法请参阅完整的 IMAP 同步指南。

迁移邮箱时 DNS 为何无法立即传播

DNS 是分布式缓存系统。更改记录后，必须等待各个递归解析器依据 Time-To-Live (TTL) 更新缓存，其中包括网络服务商的 DNS 服务器、Google 8.8.8.8 和本地路由器。

如果 TTL 仍是常见的 86,400 秒（24 小时），切换后可能整天处于双路由状态，一部分邮件进入新邮箱，另一部分仍进入旧邮箱。

长尾与负缓存

迁移邮箱时，以下两个隐蔽因素经常破坏切换过程：

• 长尾：即使 TTL 很低，全球仍约有 1-5% 的解析器忽略低于 60 分钟的值。因此，切换后约一小时内仍应留意流向旧服务商的残余邮件。
• 负缓存（SOA）：如果在记录存在前查询，例如过早检查新的 DKIM 选择器，NXDOMAIN 响应会按照 SOA 记录的最小 TTL 缓存，通常为 1 小时。即使随后发布了有效记录，也可能暂时无法看到。

阶段 1：48 小时倒计时

暂时不要修改 MX 记录，先让环境做好接受变更的准备。

步骤 1：降低 TTL（提前 48 小时）

找到 MX、SPF (TXT) 和 DMARC 记录，将 TTL 降至 300 秒（5 分钟）。

这样可以缩短传播窗口。相比 24 小时的 TTL，许多解析器会更快更新，但不能保证全球缓存都在 5 分钟内完成刷新。

步骤 2：合并 SPF（提前 24 小时）

SPF (RFC 7208) 授权指定 IP 代表您的域名发信。过渡期间必须同时授权两个服务商。

常见陷阱：SPF 最多允许 10 次 DNS 查询。合并两个服务商，例如 Google Workspace 和 TrekMail，可能超过限制。

解决方法：只有在工具能够维护并及时更新 IP 时才应扁平化记录。否则，嵌套 include: 若被直接 ip4: 机制替换，可能留下过期地址。

过渡记录示例：

如果 TrekMail 使用您自备的 SMTP，例如 Amazon SES 或 SendGrid，则应改为包含相应服务的 SPF 记录。

步骤 3：提前发布 DKIM

DKIM 使用选择器，例如 google._domainkey。在新服务商处生成密钥时，请使用唯一选择器，例如 tm1._domainkey。不要重复使用选择器名称。新选择器可以提前数天发布，不会与旧服务商冲突。

步骤 4：暂时放宽 DMARC

如果 DMARC 策略是 p=reject 或 p=quarantine，请至少提前 24 小时改为 p=none。切换初期如果配置尚未完整，可能出现身份验证失败。p=none 可在 RUA 报告中记录失败，而不会仅因该 DMARC 策略拒收，但它本身并不保证投递。设置方法请参阅 Google DMARC 配置指南。

阶段 2：执行切换

TTL 已降低，身份验证记录也已合并，现在可以把邮箱路由转移至新主机。

步骤 1：比较权威与递归查询

先确认权威域名服务器能够看到新记录，再查询公共递归解析器：

步骤 2：更新 MX 记录

最好先添加并验证新的 MX，再删除旧记录，或者以原子方式完成更改。TrekMail 用户使用：

TTL 暂时保持 300 秒，不要立即调高。

步骤 3：清除本地缓存并验证

清除本地 DNS 缓存，Windows 使用 ipconfig /flushdns，macOS 使用 sudo dscacheutil -flushcache。再次运行 dig。该操作只清理本机缓存，能否看到新 MX 仍取决于所查询的解析器。

阶段 3：切换后稳定运行

留意租户归属错误（550 5.7.64）

迁移到 Microsoft 365 或类似套件时经常出现此问题。如果目标系统尚未在内部目录中完整配置域名，可能以“Relay Access Denied”拒收邮件。更改 MX 之前，请确认新服务商面板中的域名状态为“Verified”或“Healthy”。

监控 DMARC 报告（72 小时）

连续三天查看 RUA 报告：

• 成功：来自新服务商 IP 的流量通过 SPF 和 DKIM。
• 失败：计费系统、营销平台等合法流量未通过验证。应尽快修正 SPF 或 DKIM。

清理（切换后 72 小时）

流量稳定后：

1. 确认旧服务商不再发信后，从 SPF 中删除其 include:。
2. 等待足以验证先前签名邮件的安全窗口后，再删除旧 DKIM CNAME/TXT 记录。
3. 将 TTL 恢复至 3,600s（1 小时）或 86,400s（24 小时）。
4. 确认合法来源均能正确验证后，再启用 p=quarantine 或 p=reject 的 DMARC 强制策略。

邮箱迁移检查清单概览

TrekMail 让邮箱迁移更简单

手动管理 DNS 容易出错。TXT 记录中的一个语法错误就可能使整个 SPF 策略失效。

适合小型企业

TrekMail 提供实时DNS 状态检查。管理面板会查询权威域名服务器，并按照必要基准验证 MX、SPF 和 DKIM 记录。可识别的语法错误会被标记，便于在造成退信前修正。

进一步了解如何为自己的域名设置电子邮件。

适合代理机构

管理 50+ 个域名需要标准化。TrekMail 可以把统一的 DNS 模板应用到所有客户租户。Starter 和 Agency 套餐中的托管 SMTP 负责 IP 信誉和投递邮件头，通常无需自行扁平化 SPF 或安排 IP 预热。

了解面向代理机构的多域名电子邮件托管。

所有付费套餐均提供 14 天免费试用，但需要银行卡。Nano 套餐无需银行卡。

总结

将邮箱迁移至新服务商时，最容易出错的是 DNS 切换。请提前降低 TTL，合并身份验证记录，在维护窗口内切换 MX，并持续 72 小时监控 DMARC 报告。这就是基本操作流程。

如果不想手动协调 DNS，可以免费试用 TrekMail，使用管理面板协助验证记录。