域名解析未生效？后台已设置但邮箱不通的四个检查点

先划清边界。填记录本身填什么、优先级怎么写，见MX 记录怎么设置；改完之后要等多久、缓存怎么过期，见MX 记录多久生效。这两篇讲的是「填对」和「等够」。

这篇处理第三种情况：后台明明显示已设置，邮箱就是不通，而且等了两天也没变。这类问题有个共同特征——不是时间问题，是记录压根没出去，或者出去了但没被采用。继续等下去，只会把工作时间也一起等掉。

先分清「没生效」和「生效了但没被用」

这两个说法听着像一回事，处理路径完全相反。

没生效是记录不存在。权威 DNS 里查你的域名，返回的是空的，或者还是旧值。这意味着前面某一环断了：没提交、提交到别家去了、或者被拦住了。

生效了但没被用是记录存在，邮箱还是不通。这时候 DNS 已经不是嫌疑对象，要去查域名状态、线路设置、以及邮箱服务那一侧的绑定关系。

分辨只用一条命令。先查 NS 拿到权威服务器，再向它要 MX：

dig ns 你的域名.com
dig mx 你的域名.com @返回的NS地址

Windows 下用 nslookup -type=mx 你的域名.com 那台NS的IP，效果一样。权威服务器上是什么，就是什么。它说没有，全世界都不会有；它说对，剩下的问题都不在解析这一层。

记住这个判断，后面四个检查点都是围绕它展开的。

检查点一：NS 指向的是不是你在改的那家

这是最常见、也最浪费时间的一种。公司域名在 A 家注册，当年顺手在 A 家配了解析；后来换过 DNS 服务商，NS 改到了 B 家，但没人记得这件事。现在 IT 登录 A 家后台加 MX，页面提示保存成功，实际上一个字节都没生效——因为全世界只认 B 家的说法。

识别方法就是上面那条 dig ns。返回的 NS 主机名里通常带着服务商的标识，看一眼就知道是谁。如果返回的 NS 和你正在操作的后台对不上，方向就已经明确了：去 NS 指向的那家改。

还有一种变体：NS 确实指向这家，但域名下有多个 NS，其中一个已经失效。表现是解析时好时坏，不同地区结果不同。这种要联系解析商处理，自己改不了。

顺带说一句，改 NS 本身是件大事。NS 一改，原来那家配的所有记录全部作废——MX、SPF、TXT、CNAME 一个不留。所以迁移解析商之前，必须先把记录清单抄一遍，在新家配好，再改 NS。顺序反了，邮箱会直接断掉，而且断得毫无提示。

检查点二：域名本身有没有被停掉

记录配得再对，域名状态不对也是白搭。域名有几种「暂停」状态，表现都是解析全停，但原因完全不同。

这几种状态在注册商后台都能看到，通常在域名列表里直接标出来。查一次只要十秒，但被忽略的概率很高——因为大家的注意力都在解析后台，没人去看域名本身的状态。

国内还有一个容易混的点：域名实名和网站备案是两件事。实名不做，解析直接停；备案是网站侧的要求，不影响邮箱收信。有人把邮箱不通归到「没备案」上，方向从一开始就错了。

检查点三：记录写法的四种假象

后台显示「已添加」，跟「已正确添加」之间，隔着四种常见的写法问题。它们不会报错，只会静静地不生效。

第二种在国内的域名商里特别普遍。新版后台默认开了分线路，界面上只显示「默认」一条，看着像改完了，实际上电信、联通、移动、境外各有各的记录。判断方法：把域名用手机 4G 和公司宽带分别查一次，结果不一样，就是线路问题。

第三种最难发现。复制服务商给的记录值时，很容易把前后空格一起粘进去，或者把 mx.qiye.163.com 手工改成 http://mx.qiye.163.com。后台保存的时候不会拦，查询的时候对不上。删掉重填一遍，比盯着看十分钟有效。

检查点四：解析商那边是不是「暂停」状态

记录加对了，但记录本身处于关闭状态。这一层在自己看不到的地方，需要专门去看一眼。

几个具体位置：解析记录列表里每条记录后面通常有个开关，可能被误关；有些后台对新增记录有「待审核」状态，审核没通过就不下发；免费版解析服务可能有记录条数或类型限制，超出部分不生效；域名是从别家转入的，转入时旧记录被标记为「保留未启用」。

还有一个容易被当成缺陷的正常行为：解析商加的记录，只在它自己的权威服务器上生效。如果你的 NS 不在它这里，它加多少条都没用——这又回到检查点一。所以正确的顺序是先查 NS，再查记录，反过来做会白折腾。

四个检查点都过了，问题已经不在 DNS

如果权威 DNS 上能查到正确的 MX，域名状态正常，线路没漏，记录也没被暂停，那解析这一层就可以排除了。接下来要查的是另外三处。

一是邮箱后台的域名绑定。MX 指向了服务商的服务器，但服务商后台里没把域名加进来、或者域名处于「待验证」状态，邮件到了也会被拒。这一步在管理后台的域名管理里能看到状态，别只看解析。

二是发信的认证记录。能收不能发、或者发出去进垃圾箱，是 SPF、DKIM、DMARC 的问题，跟 MX 无关。三条 TXT 怎么配，见SPF、DKIM、DMARC 怎么配。切换后头几天出的问题，一半在这一处。

三是客户端本身。网页端能正常收发、客户端不行，那就是服务器地址或端口填错了。IMAP 是 imap.qiye.163.com:993（SSL），SMTP 是 smtp.qiye.163.com:465（SSL），POP3 是 pop.qiye.163.com:995（SSL）。端口填成 25 或 110 这类非加密端口，多数网络环境下会被直接阻断。

如果对方能发进来、你发出去被退，别猜，直接看退信里的报错码。常见码的含义和处置见退信报错码对照，按码定位比逐项改配置快得多。

最后一句实话：域名解析这类问题，九成的时间浪费在「反复查本机」和「反复等生效」上。真正的判断只有一步——去权威 DNS 看一眼有没有这条记录。有，就去查别的层；没有，就别再等了，回后台。