企业邮箱绑定域名｜3个验证点漏一个就退信

退信这件事，绝大多数时候跟邮箱服务商没关系，问题出在域名那一侧。企业邮箱绑定域名，本质就是让你的域名替邮箱服务商做担保——域名指向谁、谁有权用你的名字发信、发出去的邮件有没有盖章，这三件事任何一件没对上，对面的服务器就有充足的理由把信打回来。偏偏这三件事对应的是三条不一样的记录，配错哪一条，报错的地方还不一样。

企业邮箱绑定域名的三个验证点，缺一个都白搭

三条记录分工很清楚：MX 负责收信，告诉外面这个域名的邮件该投到哪台机器；SPF 负责发信授权，声明哪些服务器有资格用你的域名往外发；DKIM 负责签名，给每封出去的邮件盖一个能验真伪的章。很多人配完 MX，自己给自己发一封，能收到，就以为大功告成。收信和发信是两条独立的路，能收到完全不等于发得出去。

记录值别自己拍脑袋想。邮箱服务商开通之后会给你一份解析清单，主机记录、记录类型、记录值、优先级都列得明明白白，照抄就行。网上那些「通用模板」最坑人，不同服务商的 selector 名字、include 后面的域名各不相同，抄错一个字符，你能查一下午。拿不准就翻服务商后台或者官方文档，以它给的为准。

MX：先把信接进来再说

MX 记录必须带优先级，数字越小越优先。只填一条怎么都好说，填两条以上就要留神，别把主机和备用写反了。更常见的坑是域名以前用过别的邮箱，旧的 MX 忘了删——外面发信时按优先级挑，挑到那台早就停了的机器，信就卡在半路，退回来一句「无法连接」或者「投递超时」，看着压根不像邮箱的毛病。

主机记录那一栏也得注意。多数解析商要求填 @ 表示主域名，也有要求写完整域名的，填法不对会生成一条奇奇怪怪的 mail.xxx 记录，验证工具一查就标红。解析商和邮箱商两边的说明都看一眼，别只看一边。

SPF 只许一条，别叠罗汉

SPF 本质是一条 TXT 记录，开头写 v=spf1，后面跟一串 include，结尾用 -all 或者 ~all 收住。规则硬得很：同一个域名只允许存在一条 SPF。见过不少人在原来那家服务商的记录后面直接又追加一条，两条并存，接收方一查，判定无效，等于你根本没配。

正确的动作是把新服务商给的 include 合进原来那条里，中间空格隔开。这里还有个容易忽略的点，SPF 记录本身有长度上限，include 堆太多会超限，超了也是失效。真需要塞很多家的时候，一般走 SPF 的展开机制绕过去，具体怎么算以官方文档的说明为准，别凭记忆。

顺一句，include 后面跟的域名要原样照抄服务商给的，不要自作聪明换成自己的子域名，那不是优化，那是给自己埋雷。

DKIM 翻车，十次有八次死在复制粘贴

DKIM 也是一条 TXT，主机记录长得像 s1._domainkey 这样，值是一大串公钥。配置本身很少出错，错都错在搬运：公钥中间带换行，粘过去之后多出空格或者少了几个字符，验证工具就回一句 key not valid 之类的话。还有些解析商面板对长 TXT 有限制，粘进去被截掉一截，结果一模一样。

查的时候分两步走。先确认记录名对不对，selector 里那个 s1 是服务商指定的，不是你随手起的，有的服务商给的是 default，有的给的是 s1024，写错等于没配。再用命令把整条 TXT 拉出来，看有没有断裂、有没有夹空格。

自己验比等退信快得多

不用等到退信才发现问题。Linux 或者 macOS 上用 dig，Windows 上用 nslookup，三条命令对着域名敲一遍：dig +short MX example.com、dig +short TXT example.com、dig +short TXT s1._domainkey.example.com。example.com 换成你的域名，s1 换成服务商给的 selector。

结果就看三眼：MX 在不在、优先级对不对；TXT 里有没有 v=spf1 那条、是不是只有一条；_domainkey 拉出来的内容完整不完整、中间有没有断开。跟服务商清单对不上，就回去改，别靠猜。

改完记得等生效。TTL 设的多少就大致等多久，有的几分钟，有的要一两个小时，以你的解析商说明为准。这段时间里查出来的结果可能是新旧混着，别急着下判断，更别连着改两遍把自己绕进去。

退信正文其实已经告诉你哪一步崩了

退信里通常带一段英文，里面有个 5 开头的错误码，再跟一句说明。看到 SPF 字样，回去查 TXT；看到 DKIM 字样，查 selector 那条；连投递都没成功、提示无法连接的，多半是 MX 那头的事。像 550 5.7.1 这种被拒的，先别急着找客服，把退信原文复制下来，对着三条记录挨个核，比问人快。

有个组合特别好判断：收信一切正常、自己往外发就被退，基本锁定 SPF 和 DKIM。反过来外面发不进来、内部互发没问题，视线直接挪到 MX，别在 SPF 上浪费时间。

换服务商那阵最容易翻车

换邮箱是三条记录同时动的手术：旧 MX 要撤掉、旧 SPF 里的 include 要删干净、旧 DKIM 记录要清。最容易犯的错就是新的先加上、旧的忘了删，两条 MX 并排、两条 SPF 并存，外面发信全看运气，今天通明天不通。

域名刚过户或者刚换了 NS 的，解析生效有个过程，这期间的测试结果不能当准。还有个特别现实的问题：域名和邮箱往往不是同一个人在管，改记录得等另一个人有空，一来一回耽误半天。上线前先问清楚解析是谁管的，比出了事再找要省心。

DMARC 顺带提一句，它不是第四个必配项，是建在前三条之上的策略记录。_dmarc 那条 TXT 写 p=none 时基本是观察模式，不拦信。等三条记录都稳了再去动它，一上来就 reject，容易把自家正常的邮件也挡在外面。

顺序上一句话就够了：先 MX 把信收进来，再 SPF 把发信的口子开对，最后 DKIM 盖章，三样都跑通再去碰 DMARC。上线前给自己发一封、给外部邮箱发一封，两边都通再通知全公司换客户端。真遇到退信也别慌，原文留着，三条记录挨着查一遍，大部分问题十分钟内能看出毛病。剩下那些拿不准的，就照服务商给的清单原文一条条对，别信网上抄来的模板。