域名邮箱托管：MX记录填错，邮件全丢

邮件忽然收不到了，一半人第一反应是服务商跑路。十有八九是 DNS 里那行 MX 被人动过。域名邮箱托管这东西，买的时候像点外卖一样顺手，真出问题才发现总开关在域名那边——服务商后台配得再漂亮，解析指错方向，邮件照样一封都进不来。

域名邮箱托管的记录不止 MX 一条，但它是命门

MX 干的事很单纯，就是告诉全网「这个域的邮件交给谁收」，后面跟一个优先级数字。A 记录错了顶多网站打不开，CNAME 错了顶多某个别名失效，MX 错了是整个域的收发一起瘫，这时候再去查防火墙、查白名单、查邮箱容量，全是在做无用功。

顺带说一句，改 MX 之前先截图存一份现有解析记录。见过太多人手一抖把 TXT 也删了，MX 修好之后 SPF 没了，信是能收了，发出去的全进垃圾箱。

优先级填反，邮件就多绕一道远路

那个数字是顺序，不是权重，别按机房权重那套去理解。数字小的先投，投不通再往后走。有人把主邮箱填 20、备用填 10，结果全天的信都往那台配置还没做完的备用机上砸，附件大一点的直接拒收。

双机热备听着稳，前提是两台都真能收信。备用机只装了个半成品，那它就不是备用，是个吞信的黑洞。

主机名最后那个点，能决定记录成不成立

填 mail.example.com 和 mail.example.com.，差别就在最后那一点。带点表示这是个绝对域名，不带就会去拼当前域名后缀，拼出个 mail.example.com.example.com 之类的怪东西。控制面板多半会自动补点，但你自己用命令行、批量导入或者从别处复制粘贴的时候，太容易漏。

还有个更隐蔽的：同一个主机名上既有 CNAME 又有 MX。按规范这两者不该挤在一起，不同解析器处理方式还不一样，有的干脆把 MX 忽略掉。要指到第三方邮件服务，MX 直接指对方给的那个域名就行，别先做 CNAME 再指望它带着走。

换服务商时，新旧 MX 混填是重灾区

迁移最忌讳两套 MX 并存好几天。外部发来的信一半去新服务器、一半去旧服务器，用户看到的现象就是「有的人能发进来，有的人发不进来」，然后一口咬定新服务商不行。

稳一点的做法是先把 TTL 调小，等旧缓存过期，再加新记录、验证能收，最后删旧的。低峰期动手，别赶在周一早上。

说邮件全丢，多数是退回去了

SMTP 的规矩是收不下就退，不会凭空蒸发。所以排查顺序应该是：先问发件方有没有收到退信、退信里写的什么原因；再看服务商后台的投递日志和隔离区；然后看客户端是不是用 POP3 把信拉走就删了；最后才怀疑账号本身。

见过一出问题就重建账号、重置密码的，折腾一下午，结果信一直都在旧账号的垃圾箱里躺着。

改完别只看后台绿灯，命令行自己验一遍

后台显示「解析正常」只能说明它自己查到了记录，不代表记录是对的。`dig MX example.com +short` 和 `nslookup -qt=mx example.com` 各跑一次，看返回的主机名和优先级数字跟不跟得上你填的。

再从外部邮箱发一封带附件的测试信进去，收到后翻完整信头，看 Received 链走的是不是你以为的那台机器。这一套下来也就几分钟，比跟客服扯半天有用。

MX 对了还进垃圾箱，问题常在另一层

SPF 的 TXT 记录、DKIM 的 selector、DMARC 的策略，这三样跟 MX 是两套账，但经常一起出问题。尤其改解析的时候手滑删掉一条 TXT，或者同一个域名下留了两条互相打架的 SPF，收信方看着就糊涂。

发信 IP 的反解也就是 PTR，也别忘了，很多服务商默认不给你设，要单独提工单。这块各家规则不一样，以服务商或官方页面说明为准。

挑域名邮箱托管，别只比容量

容量是最不重要的指标之一。更该问的是：邮件能不能整批导出、迁移工具给不给、投递日志保留多久、支不支持多域名和子域名、有没有 API。小团队还得看一条——员工离职之后账号怎么处理，能不能只转交不收新信。

另外，图省事在后台点「一键配置邮箱」的，配完记得去解析面板核对一遍。工具替你填的东西，不一定按你想的填。

真要给个顺序：先截图存底，再核对 MX 的主机名和优先级，然后调小 TTL 做迁移，改完用 dig 和测试邮件验，最后回头检查 SPF、DKIM、PTR。这几步做完还收不到信，再去翻服务商日志，基本不会白跑。