A记录和MX记录有什么区别？各自管一摊，改错一边才出事

先给结论。A 记录和 MX 记录回答的是两个不同的问题。A 记录回答「这个域名指向哪台机器」，网页访问和客户端连接都靠它；MX 记录回答「发给这个域名的邮件交给谁」，只管收信。两条记录各管一摊，改一条不会动另一条。

把这句话记住，能省掉一半的排查时间。多数「网站好好的，邮箱突然断了」的事故，根子都在有人以为这两条记录是一回事，于是换了网站顺便把邮件记录也清了。

邮件和网页，走的是两条查找路径

打开一个网页和发一封邮件，DNS 查询的步骤不一样。把这个顺序理清，后面所有现象都能自己对上号。

网页：浏览器拿到域名，查 A 记录（或者 CNAME 别名），得到一个 IP，连过去取页面。整条路径上没有 MX 什么事。

邮件：发件方的邮件服务器拿到收件人的域名，先查 MX 记录，得到一台邮件服务器的主机名；再对这个主机名查一次 A 记录，拿到 IP；最后连 25 端口把信投过去。

所以 MX 是架在 A 上面的一层。MX 指向的那个主机名自己必须有 A 记录，否则这条 MX 就是断的——收件方查到了主机名，却解析不出 IP，一样投不进来。反过来，A 记录完全不需要知道 MX 的存在。你把 @ 的 A 记录删掉，网站打不开，邮件照样收发。

一句话概括依赖方向：MX 依赖 A，A 不依赖 MX。

四种记录，各回答一个问题

DNS 里常见的记录就那么几种，弄清每种在回答什么问题，比记语法有用。

注意 MX 和 TXT 的关系：MX 只管「信投到哪」，投到了之后收件方愿不愿意收、会不会判成垃圾邮件，看的是 TXT 里的 SPF、DKIM、DMARC。MX 通了只代表能收，不代表收得干净。这是两件事，别混。

MX 的值填主机名，不要填 IP

后台那个「记录值」输入框很容易让人想填 IP，这是 MX 配置里最常见的一个错。

标准规定 MX 的记录值是一个主机名，收件方拿到之后还要再解析一次。填成 1.2.3.4 这种纯 IP，一部分解析商直接拒绝保存，另一部分允许保存，但收件方查不到对应的 A 记录，投递失败。表现就是「对方说发了，你这边什么都没收到，也没有退信」——最难查的那一类。

还有一条更硬的规则：MX 不能指向 CNAME。有些建站平台会把邮件服务器域名做成别名，你照抄进 MX，收件方顺着别名找不到最终的主机名，验证失败。遇到这种情况，要填它最终指向的那个真实主机名。

服务商给的值长这样：mx.qiye.163.com，优先级填 5 或 10。照抄，别自己加 http://、别加端口、别加结尾的斜杠。填完用命令看一眼：

dig mx 你的域名.com

看到返回的主机名之后，再对它查一次：

dig mx.qiye.163.com

第二次能返回 IP，说明这条 MX 是通的。第二次什么都没有，MX 填得再对也没用。

网站和邮箱分在两家，配法其实很简单

把两家服务商的要求拆开列出来，会发现它们几乎不重叠——这正是可以把官网和邮箱分开买的原因。

建站服务商要的：@ 的 A 记录指向它的服务器 IP，www 的 CNAME 指向它给的别名。它从不关心你的 MX。

邮箱服务商要的：@ 的 MX 指向它的邮件服务器，@ 的 TXT 里放 SPF，另外加一条 DKIM 的 TXT 和一条 _dmarc 的 TXT。它不要求你加 A 记录。

于是有了一条清晰的分界：换官网，只动 A 和 CNAME；换邮箱，只动 MX 和 TXT。两边一起改，才是事故的起点。

一个常被问到的地方：员工在 Outlook 或手机里填的服务器地址，直接填服务商给的三条就行——IMAP imap.qiye.163.com 993（SSL）、SMTP smtp.qiye.163.com 465（SSL）、POP3 pop.qiye.163.com 995（SSL）。这几个域名由服务商维护，不需要你在自己域名下另加 A 记录。具体填法见 Outlook 配置。

只有一种情况要自己加 A 记录：你想让员工用 mail.你的域名.com 访问网页邮箱。那就加一条主机记录为 mail 的 A 记录，指向服务商给的 IP。不加也能用，直接用服务商提供的登录地址即可。

@ 上挂 CNAME，会跟邮件记录打架

这是两类记录唯一会正面冲突的地方，也是「网站上线当天邮箱全断」最典型的成因。

DNS 规范里，一个名字上一旦放了 CNAME，就不能再有任何其他类型的记录。而现在很多建站平台和 CDN 的接入方式是「把 @ 做一条 CNAME 指到我们的加速域名」，你照着做了，解析商为了满足规范，会把原来 @ 上的 MX 和 TXT 一起顶掉。

后果很有欺骗性：网站立刻能打开，看着一切正常。第二天开始全公司收不到信，而且没有任何报错——因为 MX 记录已经不存在了，发件方查不到记录，静默失败。查 DNS 才发现 @ 上只剩一条 CNAME。

三种处理办法，按推荐程度排：

1. 让建站方给 A 记录的 IP。主流 CDN 都支持 A 记录接入，只是默认文档先写 CNAME。要一个 IP 就能解决，邮箱一点不受影响。这是首选。
2. CNAME 只放 www。主域名 @ 用 A 记录指向源站或 CDN 的 IP，www 走 CNAME。用户输 www 和输裸域都能到，邮件记录安全。
3. 把邮箱挪到子域名。用 mail.你的域名.com 收发信。能不选就不选：所有员工的客户端地址要改一遍，客户地址簿里的旧地址也要跟着换，代价远大于省下的那点配置功夫。

已经踩了坑的，回解析商把 @ 的 CNAME 删掉，MX 和 TXT 重新加回来。收信不会立刻恢复，要等旧 TTL 过期，时间账见 MX 记录多久生效。如果连记录都加不进去，说明解析商那边还有残留的 CNAME 没清，先把 CNAME 彻底删干净。

改错一边会怎样，对照着看

下面这张表是把常见操作和后果摆在一起。出事的时候先在这张表里找现象，比从头查快得多。

最后给一个三分钟自查，查四条就够：

• dig a 你的域名.com —— 返回的 IP 是不是当前网站服务器的那台。
• dig mx 你的域名.com —— 有没有记录，优先级数字对不对，主机名能不能再解析出 IP。
• dig txt 你的域名.com —— 有没有、且只有一条以 v=spf1 开头的记录。有两条就得删掉旧的那条。
• dig ns 你的域名.com —— NS 指向的是不是你正在操作的那家解析商。这一条最容易白忙，改了半天发现改的不是生效的那台服务器。

四条里哪条不对，问题就在那一层，不用往下猜。Windows 下没有 dig，用 nslookup -type=mx 你的域名.com 这类写法，效果一样。

还有一种情况要区分开：MX 正常、收信正常，但发出去的邮件进垃圾箱。这跟 A 和 MX 都没关系，是发信身份验证的问题，去看 SPF、DKIM、DMARC 怎么配。MX 和 MX 记录怎么设置讲的是收，那篇讲的是发，别把两件事搅在一起。