域名解析系统｜3种记录类型最常配错

域名解析系统里配错记录，十次有八次不是手抖打错字母，是记录类型本身就选岔了。A、CNAME、MX、TXT 这些，界面上都是往一个框里填字符串，看着都差不多，规矩却完全不是一回事。下面这三种记录，是我这些年见得最多、也最容易被“保存成功”这四个字给糊弄过去的。

域名解析系统里最爱套娃的就是 CNAME

CNAME 的意思是“我这个域名等同于那个域名”，好处是对方换了 IP 你这边不用动。就因为这个方便，太多人把它当万能胶——主域名直接 CNAME 到 CDN 厂商给的别名，图省事。省完事再看企业邮箱，收不到信了。原因不复杂：主域名上挂了 CNAME，同一个主机名下的 MX 在不少解析商那里就存不进去，或者存进去了也不生效。这条老规矩吵了很多年，各家实现还有差别，具体以服务商控制台的提示为准。稳妥的做法是别把邮箱相关的全挤在主域名上，单独开一个 mail.你的域名 放 MX 和收信用的 A 记录。另外 CNAME 指向的目标得是个活着的域名，别指回自己，也别指向一条早被删掉的记录——那会解析出空答案，表现出来就是网站一会儿能开一会儿打不开，最容易让人怀疑服务器。

MX 记录错得最隐蔽，信退回来了才知道

MX 的值必须是“能收信的一个域名”，不是 IP。我见过把 MX 那栏直接填 192.168 开头的地址，控制台还显示保存成功，邮件照样一封封退回来。MX 的优先级是数字小的先试，不少人以为大的优先，把主力邮箱填 10、备用填 5，结果备用那台天天在收信，主力反而闲着。还有那个经典组合拳：MX 指向 mail.你的域名，可 mail 这条 A 记录压根没建，或者指向的是一台没开 25 端口的虚拟主机。解析层面一切正常，投递层面全废，你去查解析，它还会告诉你记录配置无误。改完拿 dig mx 你的域名 看一眼返回，比在面板里反复点保存有用得多。顺手也确认一下反向解析和 SPF 有没有跟上，发出去的信进不进收件箱，不是解析商单方面能决定的。

TXT 记录不是给人看的留言板

TXT 本来是为验证和发信策略准备的，不是备注栏。最常见的错法有三种。第一种，域名归属验证、SPF、DKIM 三样东西全塞进同一条记录里，以为省事，结果哪一样都验不过。第二种，SPF 拆成好几条记录写，收信方一看有多条 SPF 直接判失效——规矩是同一条记录里列多个发信来源，而不是写多条记录。第三种，DKIM 给的是一长串值，复制的时候在中间断了，少了后半截，签名校验怎么都过不去，还得回头找服务商重发。做证书验证时加的 _acme-challenge 那条也常出事：验证完忘了删，过几个月换证书又加一遍，两条并存，验证就卡在那儿，谁看都是一脸问号。

记录之间的冲突，报错往往不说人话

同一条主机名上，A 和 CNAME 不能共存，CNAME 和 TXT、MX 也不行——严格讲 CNAME 要求这个主机名上只有它自己。解析商给的报错经常就一句“记录冲突”，剩下的你自己推。所以我现在养成的习惯是：主域名老老实实放 A 或 AAAA，邮箱相关的挂到 mail 子域，各种验证类的临时记录单独起个主机名，验证完立刻删。看着麻烦，真出事的时候能省下大半夜。

改完不生效，多半跟记录本身没关系

TTL 这东西，设成 600 就意味着十分钟内旧记录还在各处缓存里跑。很多人改完立刻刷浏览器，看见旧 IP 就以为没保存，接着一遍遍点保存，把好好的记录点出问题来。正确姿势是绕开本地缓存：换台机器、换个网络，或者干脆用 dig 指定权威服务器查，比如 dig @ns1.服务商的域名 你的域名 A。权威那边已经是新值、本地还是旧的，那就是缓存，等着就行，别乱改。这一条每年都能救回几个准备重装服务器的人。

十来分钟能走完的自查顺序

顺序别乱。先查权威现在返回什么，用 dig 或者 nslookup 直接指到权威 NS；再看本地缓存清没清，换个网络验证一遍；然后查发信这条链路，MX 的值是不是域名、它对应的 A 记录在不在、SPF 是不是只有一条；最后挨个看 CNAME 的落点还活着没有，尤其指向 CDN 的那种，CDN 那边把域名删了、CNAME 还指着一个不存在的目标，解析出来就是空答案。按这个顺序走，基本不用来回猜。

记录类型这事，说白了就几条硬规矩，记不住也没关系。动手之前先把当前的解析结果导出一份或者截个图，改完拿它对比，出了岔子能原样退回去。要连着改好几条，慢一点，一条一条来，别一口气全提交。