如何将邮箱迁移到新服务商（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 分钟内完成刷新。
dig yourdomain.com MX
# Look for 300 in the TTL column
步骤 2：合并 SPF（提前 24 小时）
SPF (RFC 7208) 授权指定 IP 代表您的域名发信。过渡期间必须同时授权两个服务商。
常见陷阱：SPF 最多允许 10 次 DNS 查询。合并两个服务商，例如 Google Workspace 和 TrekMail，可能超过限制。
解决方法：只有在工具能够维护并及时更新 IP 时才应扁平化记录。否则，嵌套 include: 若被直接 ip4: 机制替换，可能留下过期地址。
过渡记录示例：
v=spf1 include:_spf.google.com include:spf.trekmail.net -all
如果 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：比较权威与递归查询
先确认权威域名服务器能够看到新记录，再查询公共递归解析器：
# Check authoritative nameserver
dig @ns1.provider.com yourdomain.com MX
# Check public recursive resolver
dig @8.8.8.8 yourdomain.com MX
步骤 2：更新 MX 记录
最好先添加并验证新的 MX，再删除旧记录，或者以原子方式完成更改。TrekMail 用户使用：
10 mx1.trekmail.net
20 mx2.trekmail.net
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 小时）
流量稳定后：
- 确认旧服务商不再发信后，从 SPF 中删除其
include:。 - 等待足以验证先前签名邮件的安全窗口后，再删除旧 DKIM CNAME/TXT 记录。
- 将 TTL 恢复至 3,600s（1 小时）或 86,400s（24 小时）。
- 确认合法来源均能正确验证后，再启用
p=quarantine或p=reject的 DMARC 强制策略。
邮箱迁移检查清单概览
| 时间 | 操作 | 记录类型 |
|---|---|---|
| T-48h | 将 TTL 降至 300s | MX, SPF, DMARC |
| T-24h | 合并 SPF，同时授权两个服务商 | TXT |
| T-24h | 提前发布新的 DKIM 选择器 | CNAME/TXT |
| T-24h | 将 DMARC 放宽至 p=none | TXT |
| T-0 | 迁移邮箱：切换 MX 记录 | MX |
| T-0 | SPF 保留新服务商，旧服务仍发信时暂不删除 | TXT |
| T+72h | 安全移除旧 DNS 记录，启用 DMARC | 全部 |
TrekMail 让邮箱迁移更简单
手动管理 DNS 容易出错。TXT 记录中的一个语法错误就可能使整个 SPF 策略失效。
适合小型企业
TrekMail 提供实时DNS 状态检查。管理面板会查询权威域名服务器，并按照必要基准验证 MX、SPF 和 DKIM 记录。可识别的语法错误会被标记，便于在造成退信前修正。
进一步了解如何为自己的域名设置电子邮件。
适合代理机构
管理 50+ 个域名需要标准化。TrekMail 可以把统一的 DNS 模板应用到所有客户租户。Starter 和 Agency 套餐中的托管 SMTP 负责 IP 信誉和投递邮件头，通常无需自行扁平化 SPF 或安排 IP 预热。
了解面向代理机构的多域名电子邮件托管。
| 套餐 | 价格 | DNS 状态检查 | 托管 SMTP |
|---|---|---|---|
| Free | $0（无需银行卡） | 有 | 仅限自备 SMTP |
| Starter | $3.50/月 | 有 | 已包含 |
| Pro | $10/月 | 有 | 已包含 |
| Agency | $23.25/月 | 有 | 已包含 + IP 信誉管理 |
所有付费套餐均提供 14 天免费试用，但需要银行卡。Nano 套餐无需银行卡。
总结
将邮箱迁移至新服务商时，最容易出错的是 DNS 切换。请提前降低 TTL，合并身份验证记录，在维护窗口内切换 MX，并持续 72 小时监控 DMARC 报告。这就是基本操作流程。
如果不想手动协调 DNS，可以免费试用 TrekMail，使用管理面板协助验证记录。
