换DNS服务商，邮箱解析怎么迁才不断信

先把边界划清。这篇讲的是把域名的解析托管从一家 DNS 服务商换到另一家——也就是改 NS。域名所有权转移（把域名从 A 注册商转到 B 注册商）是另一件事，流程完全不同，这里不涉及。

换 DNS 期间邮箱断掉，是这类操作里最常见的后果，但它不该发生。收信靠的是 MX 记录的内容，不是 MX 记录托管在谁家。只要内容一字不差地搬过去，中间那段时间发件方查到哪一家都得到同样的答案。

断信只有两个原因

复盘过的情况里，断信基本落在两处，都跟「换服务商」本身没关系，是操作顺序的问题。

一是记录没搬全。MX 太显眼，人人都会搬（它的字段怎么填，MX 记录怎么设置那篇写过）。真正被漏掉的是那几条不显眼的 TXT：SPF、DKIM 公钥、DMARC。它们不在邮箱后台的「域名设置」页面里，只存在 DNS 里，登录新服务商的后台时根本想不到它们。漏了 SPF 不会立刻收不到信，是发出去的信开始进垃圾箱，两周后才有人发现「客户说没收到报价」。

二是顺手改了 MX。换 DNS 的时候看到旧记录格式不整齐、优先级写着 5 和 10 觉得别扭，顺手改成 10 和 20，或者把两条合并成一条。这一类改动的后果最重：旧记录已经在全球缓存里，新记录要等缓存过期，中间那段时间不同发件方查到不同答案，邮件一半进新服务器一半进旧服务器，还有人两头都投不进去。

所以下面这套顺序，核心就一句：搬家的时候只搬不改。

迁之前，把旧解析抄成一张清单

不要凭记忆在新后台一条条加。先把旧服务商的记录列表整页导出或截图，逐条对着建。有些服务商支持 BIND 格式的 zone 文件导入导出，能用就用，比手工敲准确得多。

下面这张表是搬家时按类型过一遍的清单，最后一列是漏掉之后最先出问题的现象。

这张表里最该盯的是 SPF、DKIM、DMARC 三行。MX 漏了当天就有人喊，TXT 漏了要等业务方反馈，中间的时间差足够让一批邮件白白进垃圾箱。SPF、DKIM、DMARC 怎么配那篇有每条记录的完整写法，搬的时候照着抄，别凭印象重写。

还有个细节：MX 的优先级也是记录内容的一部分。值和优先级都必须与旧记录逐字一致，包括那两条主备的顺序。

抄完先比对，别急着改 NS

新后台的记录建好之后，先别动 NS。此时旧服务商还在对外提供解析，你有充分的时间核对。

核对的办法不是看新后台的列表——列表显示的是你填的，不是外面查到的。要查新服务商的权威服务器：先拿到新服务商分配给你的 NS 主机名，然后直接向它查。

dig mx 你的域名 @新服务商的NS主机名

MX、SPF、DKIM、DMARC 各查一遍，把结果和旧服务商的权威结果逐条对照。优先级、主机名、TXT 引号内的整串内容，三个地方都要一致。这一步花二十分钟，能省掉后面两天。

比对时容易忽略的是 TXT 的引号。有些后台会把一条长 TXT 显示成被引号切成几段的形式，那是展示方式，实际是一整串。复制时把引号也复制进去，记录就废了——外面查到的内容会多出两个引号字符。

NS 的缓存比普通记录久，还有 DNSSEC 这道坎

改 NS 之后生效慢，很多人第一反应是「去把 TTL 调小」。这个动作在这里没用，原因很简单：TTL 是你自己 zone 里每条记录的属性，NS 委派不在你的 zone 里。它由上级（注册局）那条委派记录的缓存决定，你既看不到也改不了。

实际等待时间以注册商后台显示为准，常见的说法是 24—48 小时。这期间不同地区的人查到新旧两家都有可能，属于正常中间态，不用反复改设置——每改一次，计时重新开始。如果你要判断具体某条记录为什么还没更新，MX 记录多久生效那篇里的三层查法可以直接套用，区别只在于这次要看的是 NS 而不是 MX。

比等待更麻烦的是 DNSSEC。如果域名在注册商那里启用了 DNSSEC，会有一条 DS 记录指向旧服务商的密钥。换到新服务商之后，新家的密钥和 DS 对不上，所有查询都会返回 SERVFAIL——不是邮件收不到，是整个域名解析崩掉，网站、邮箱、API 一起挂，而且报错信息完全看不出跟 DNSSEC 有关。

处理顺序有讲究：先确认新服务商支持 DNSSEC 并拿到新密钥，在注册商处把 DS 换成新的，再改 NS；或者反过来，先在注册商处把 DS 删掉，等迁移稳定后再重新启用。两条路都行，唯一不能做的是「什么都不管直接改 NS」。

判断有没有启用，去注册商后台看 DNSSEC 状态最直接。命令行也行：dig +dnssec 你的域名，应答里出现 RRSIG 记录就说明签名是开着的。

迁移窗口里，这三件事别碰

1. 别动 MX。哪怕只是把优先级从 5 改成 10，也等迁移彻底稳定之后单独做一次。同时改两处，出问题时你无法判断是哪一处导致的，只能全部回滚。
2. 别删旧 DNS 的 zone。NS 还没在全球生效时，相当一部分解析请求仍然打到旧服务商。这时候把旧记录删掉，那部分请求就查不到结果，等于人为制造断信。
3. 别同时换邮箱服务商或换网站主机。三个变量一起动，排查成本翻几倍。真要换，隔开至少一周，一次只动一个。

这三条看着保守，但它们的共同点是：把可能的故障源压到一个。出了问题能立刻定位，比事后省下的那点时间值钱。

收尾：观察几天，什么时候能删旧解析

改完 NS 不是结束。观察期至少要覆盖一个完整的业务周期，一周是常见的做法。外贸公司要把时差算进去——欧洲客户的上午对应北京时间下午，那段时间的来信量才是真实水平，别拿凌晨的安静当「一切正常」。

观察期内要做四件事：

1. 多地查 NS。用不同节点的在线工具查一遍，确认都指向新服务商。还有节点指向旧的，说明缓存没走完，继续等。
2. 抽查四条邮件记录。MX、SPF、DKIM、DMARC 各查一次，与迁移前的截图逐字对照。这一步是防止「搬的时候手滑」，比看后台列表可靠。
3. 发测试信看原文。往 Gmail、QQ、Outlook 各发一封，打开邮件原文的 Authentication-Results，spf、dkim、dmarc 三项都应是 pass。
4. 确认网站和证书。官网能打开只说明 A 记录对；CAA 漏了要等下次续签才报错，提前在证书后台看一眼更稳。

七天之后，如果没有异常，就可以把旧服务商的 zone 删掉或停掉。删之前导出一份存档，包括账号信息、记录清单和迁移日期。半年后有人问「当初那条 CAA 是谁加的」，这份存档是唯一能回答的东西。如果观察期内出现某条记录查不到的情况，按 域名解析未生效那篇的四个检查点走一遍，先确认 NS 指向的是不是你以为的那一家，再往下查。

顺带提醒一件跟迁移无关但常被一起忘掉的事：域名的到期提醒邮箱要确认能收到。换了 DNS 服务商，注册商的联系人信息通常不变，但如果那个邮箱本身就在这个域名下，域名一到期就会陷入「收不到续费提醒、域名被停、邮箱停摆」的死循环。这一条比上面所有技术细节都更值得检查一次。