域名验证、SPF、DMARC 都要 TXT，会打架吗

这个问题在工单里出现得很频繁：域名要做归属验证、SPF 要加、DMARC 也要加，三样都是 TXT。加到第三条，后台提示「记录已存在」，于是有人把新值粘到旧值后面，中间加个逗号。这一步做错，前面配好的两样一起失效。

先划清分工。SPF、DKIM、DMARC 三条记录怎么写讲的是每条的值怎么拼；本篇只讲它们摆在一起时的相容规则：哪些能并排、哪些必须合并、合并时先动哪一步。

TXT 是一类记录，不是一个格子

很多人把 DNS 后台想成一张表格，一个域名一行，一行一个值。TXT 不是这么存的。TXT 是一种记录类型，同一个主机名下可以挂多条，每条独立存在，谁也不覆盖谁。

决定两条 TXT 能不能并存的，是主机名（后台里常写成「主机记录」「名称」「Name」），不是值的内容。主机名不同，就是两条互不相干的记录；主机名相同，才会被放在一起比较。

所以下面四条同时存在完全正常，不构成任何冲突：

• @ 上的 SPF：v=spf1 include:spf.qiye.163.com -all
• @ 上的站点验证：google-site-verification=...
• _dmarc 上的 DMARC：v=DMARC1; p=none; rua=...
• s1._domainkey 上的 DKIM 公钥

反过来，「一个域名只能有一条 TXT」这个说法是错的。它是把 SPF 的规则记串了门：一条 SPF 是对的，一条 TXT 不是。

五类 TXT，各占哪个主机名

下表第二列是要盯死的地方。主机名错一个字符，记录就挂在一个不存在的地方，验证永远不通过。这类错误的表现和「冲突」一模一样，原因却完全不同。

表格里最容易出的错是第三行和第四行。_dmarc 少写前面的下划线，就变成 dmarc，成了另一个主机名；_domainkey 写成 domainkey 同样失效；选择器名和后台给的不一致（后台给 s1，你填 default），这条 DKIM 就永远验不过。查 dig txt _dmarc.你的域名 返回空，不是被别人占了，是压根没写对地方。

真正会打架的只有一种：同一用途写了两条

把「同一用途」这个限定说死，剩下的情况都好办。三种记录的规则并不一样，差别还挺大。

SPF 是硬规则。RFC 7208 规定一个域名最多只能有一条 v=spf1 记录。出现两条时，接收方判定为 permerror，按校验失败处理——注意是两条一起失效，不是取第一条。原来那条本来能通过的，也一起废了。这是 TXT 里唯一会互相毁灭的场景。

DMARC 同样是硬规则。_dmarc 下出现两条，接收方会当作没有 DMARC，策略不执行，rua 报告也不会来。表现就是「配了跟没配一样」，而且后台看不出任何报错。

DKIM 正好相反。不同选择器的多条 DKIM 是设计允许的，各自独立校验。换密钥时的标准动作是先加新选择器、跑几天确认通过、再删旧的，这段过渡期里两条并存是对的。看到 _domainkey 下有两条就去删，反而可能把正在用的那条删掉。签名失效后的排查在 DKIM 验证失败那篇按结果码列过。

这个反向差别很实用：SPF 只能改、不能加，要动它就在原记录上编辑；DKIM 可以加、不必急着删。两件事的操作顺序不能互换。

几处看着像冲突，其实不是

1. 验证记录和 SPF 挤在 @ 上。两条主机名相同、类型相同、值完全不同，这是允许的。只要不都是 v=spf1 开头，就没问题。
2. 后台列表只显示一行。不少面板把同一主机名的多条 TXT 合并显示，或者只显示第一条的值。判断有几条要看 dig txt 域名 的输出，别信后台那一行。
3. 值被拆成两段带引号。单条 TXT 字符串上限 255 字节，超长的值会被拆成多个字符串，解析器拿到后自动拼回去。看到 "abc" "def" 这种写法不是两条记录，是一条被分段的记录。SPF 的 include 一多就容易撞到这个上限。
4. 两个选择器的 DKIM 并存。见上一节，是换密钥的过渡态，不用处理。
5. 这不是并存问题，是域名被顶了。@ 上如果挂了 CNAME，MX 和 TXT 会一起失效，因为 CNAME 的规则是「这个主机名归我，其它记录让路」。先跑 dig cname 域名 看有没有返回值，处理办法在 A 记录和 MX 记录里写过。

合并的动作顺序：改原记录，别新增

确认确实有两条同用途记录之后，按这个顺序做，能把出错窗口压到一次保存之内。

1. 先把现状抄全。跑 dig txt 你的域名 @8.8.8.8，把所有 TXT 行连同分段引号一起复制出来。后台显示不全时，这是唯一可靠的信息源。
2. 在本地把值拼好。SPF 的合并是把各条的机制段并进一条：v=spf1 只留一个，后面的 include:、ip4:、-all 依次排。拼的时候数一遍 include 和 redirect 的层数——SPF 有 10 次 DNS 查询上限，两条原本各自 6 次的记录并成一条，很可能直接超限。超限也是 permerror，症状和「两条并存」一样，原因换了，别修错方向。
3. 编辑，不要新增。点开那条原有记录改成拼好的值。新增一条再删旧的，中间那段时间就是两条并存，收信方在这个窗口里看到的全是失败。
4. 保存，等 TTL。生效时间取决于你自己设的 TTL，多数面板默认在 10 分钟量级，各家不同。这段时间查到旧值属正常，不要反复改。
5. 复验。再跑一次 dig txt，数 v=spf1 出现了几次，必须是一次。DMARC 同理，dig txt _dmarc.域名 只能有一条 v=DMARC1。

一次只改一样。SPF 和 DMARC 同时改，出问题时分不清是哪条引起的，只能回滚两次。

哪些验证记录能删，删了会怎样

记录越堆越多，多数人最后都想清一遍。清之前先分清三类，别一视同仁。

可以删的：各类平台的域名归属验证记录，比如 google-site-verification= 开头那串、MS=ms 开头那串。这些不参与发信链路，删了不影响收信，只是平台下次做校验时可能要求重新验证一次。

不能删的：_dmarc 和任意 选择器._domainkey。删掉 DMARC 等于退回「完全没有策略」，删掉 DKIM 会让正在用的签名失效，跑在这条签名上的 DMARC 校验随之失败。

只能有一条的：SPF。清理时最容易误伤的就是它——看到 @ 上好几条 TXT，手一快把带 v=spf1 的那条当冗余删了，几天后发信开始进垃圾箱，没人会想到是那天删的。

还有一个动作值得写进流程：换 DNS 服务商或域名过户之前，把全部 TXT 导出一份。新服务商搬家时通常只搬 A 和 MX，TXT 漏掉的话 SPF 和 DMARC 一起消失，而这件事往往要等到客户投诉收不到信才会被发现。按结果码排查的思路，SPF 记录配置错误那篇写得更细。