企业邮箱改 DNS：三条冲突规则与回滚方案

给企业邮箱加 MX 和 TXT 记录，不会覆盖掉网站的 A 记录。 原因在标准里：DNS 把记录按「名字 + 类别 + 类型」归成一组，类型不同就是不同的组，彼此不替换[1]。所以同一个根域上同时存在指向网站的 A 记录和指向邮箱的 MX 记录，是正常状态而不是冲突。真正会把网站或邮件打断的只有三条规则，而且三条都写在标准里，可以提前避开。 本篇逐条讲清这三条、各自的触发现象，以及回滚要靠什么前提才成立。

三条口径先记住：

同簇话题各有专文：记录值与五步操作见不懂技术，怎么把域名和企业邮箱一次配好；四项记录各自管什么见MX、SPF、DKIM、DMARC 分别是干什么的；改完要等多久见域名配置生效要多久。本篇做一件事：讲清三条冲突规则与回滚前提，不重复操作步骤。

先把误解拆掉：DNS 按「名字 + 类型」存放

很多人担心加邮箱记录会把网站搞坏，根源是以为同一个名字下只能放一条记录。实际不是。

标准里把「同名字、同类别、同类型」的记录归为一个资源记录集，不同类型各成一组[1]。换句话说，example.com 这个名字上可以同时挂着：

记录类型	作用	会不会和其他类型互相顶替
A	指向网站服务器 IP	不会
MX	指定收信服务器	不会
TXT	承载 SPF、域名验证串等	不会（但同用途的 SPF 有唯一性要求，见规则三）
CNAME	把这个名字整体指向另一个名字	会——见规则一

所以「加 MX 把网站搞崩」这件事，在类型层面是不成立的。 阿里邮箱也不要求把域名转入阿里云或改 DNS 服务器，只需在当前解析服务商处添加记录[3]——不动 NS，网站的解析链路就没被碰过。

误解拆掉之后，剩下的三条才是需要认真对待的。

规则一：一个名字上有了 CNAME，就不能再有别的记录

这是三条里唯一会真的让网站打不开的。

标准怎么规定

标准对任意一个域名列出了四种互斥状态：存在一条 CNAME（可附带 DNSSEC 相关记录）；存在一条或多条非 CNAME 记录；名字存在但没有任何记录；名字不存在[1]。四种只能占一种——这就是「有 CNAME 就不能有其他记录」的出处。

什么时候会撞上

典型是这两种操作：

正确做法

邮箱相关记录各有各的位置，不需要和网站抢同一个名字。 MX 和 SPF 加在根域（主机记录通常填 @）；DKIM 用的是带选择器前缀的独立子域名；客户端接入用的别名放在自己的主机名下。记录该填在哪个主机名上以哪个值为准，按解析服务商的后台和原厂文档逐条对照[4]，具体记录值见不懂技术，怎么把域名和企业邮箱一次配好。

动手前的检查动作只有一个：确认你要填的那个主机名上现在有没有 CNAME。有，就先弄清它在为谁服务，再决定换名字还是换方案——不要直接删。

规则二：MX 的值不能指向别名

这条比规则一隐蔽，因为它不报错，只是不稳定。

标准写明：用作 NS 记录值、或作为 MX 记录值一部分的域名，不能是别名；这个域名必须能解析到地址记录[1]。

也就是说 MX 右边填的那个主机名，自己不能是一条 CNAME。 把原厂给的收信服务器地址照抄进去通常不会有问题，因为原厂提供的就是可直接解析的名字。真正容易出事的是这两种自作聪明：

两种都违反这条规则。标准还同时指出，在这两个位置使用别名既不如预期可靠，也达不到采用这种做法想要的效果[1]。

检查动作：把 MX 右边的主机名单独查一次，确认它返回的是地址记录，而不是又跳到另一个名字。

规则三：SPF 每个域名只能有一条

这条是实际工作中出现频率最高的，而且后果比漏配更严重。

多一条的后果是 permerror

标准规定得很硬：SPF 记录是放在单条 TXT 记录里的单个字符串，同一个所有者名下不允许存在多条 SPF 记录[2]。校验过程中，如果筛出来的记录集超过一条，函数直接返回 permerror[2]。

permerror 的含义不是「有点问题」。标准的定义是：域名发布的记录无法被正确解释，这是一种明确需要 DNS 管理方介入才能解决的错误状态[2]。而且记录里任何位置的语法错误，都会让校验立即返回 permerror、不再继续解释[2]。

所以「再加一条 SPF 把新发信系统也写上」是典型的错误修法。 正确做法是把新来源合并进现有那一条里。

还有一个隐蔽上限：10 次 DNS 查询

企业接了多个发信系统之后最容易踩的就是这个。

标准要求：会触发 DNS 查询的项——include、a、mx、ptr、exists 以及 redirect——在一次 SPF 校验中总数不得超过 10 个，超过必须返回 permerror[2]。注意 include 是会展开的，你写一条 include，对方记录里可能还套着好几条，查询次数是累加的，不是按你写了几项算。

还有两条配套限制：mx 项展开时查询的地址记录不得超过 10 条，超过该项返回 permerror；而 all、ip4、ip6 这几项不触发查询，不占这个额度[2]。

这给出一个具体的运维动作：每接入一个新的发信系统，就重新数一次 SPF 的查询次数，而不是只确认「加进去了」。接近上限时，用 ip4 直接写地址段来替换一部分 include，可以把额度省下来。

顺带一个取值提醒

SPF 末尾的限定符含义是标准定义的：+ 通过、- 失败、~ 软失败、? 中立[2]。改这一个字符会改变收件方对验证失败邮件的处置依据，不属于格式调整，属于策略变更——所以不要在排查过程中顺手改它。各项记录之间怎么配合，见MX、SPF、DKIM、DMARC 分别是干什么的。

回滚的前提是改之前就留好快照

三条规则都避开了，仍然可能因为填错值而需要退回去。这时候决定成败的不是操作熟练度，是改之前有没有留下可对照的原始状态。

快照要留什么

不是截一张图就够。按条目留全这几项，回滚时才不用猜：

要留的内容	为什么
主机记录、记录类型、记录值、优先级、TTL	缺任何一项都无法原样还原；优先级只对 MX 有意义，最容易漏记
改动前已存在的全部 TXT 记录	SPF 之外常有域名验证串，误删会让别的服务一起失效
这条记录原本在为谁服务	决定能不能删；查不清的记录一律不动
改动时间与操作人	出问题时用来界定影响范围

为什么「改回去」不等于「立刻恢复」

解析结果会在各级缓存里停留，改回原值之后仍要等缓存过期才全网一致，生效区间是 10 分钟到 48 小时[3]。标准也说明 TTL 是「最长存活时间」而非强制时长，各实现还可以自行设置上限[1]——意味着实际等待时间不完全由你设的 TTL 决定。

两个推论：

一张改前自查表

动手前逐条过一遍，六条都能回答再保存：

#	自查项	不通过时先做什么
1	原记录是否已按条目留全快照（含类型、值、优先级、TTL）	先补齐快照再动手
2	要填的主机名上现在有没有 CNAME	有则先查清它的用途，不要直接删
3	MX 右边的主机名是否能解析到地址记录	换成原厂给出的可直接解析的地址
4	域名下现在有几条 SPF	超过一条则合并成一条，不要并存
5	SPF 的 DNS 查询项是否仍在 10 个以内	用 ip4 替换部分 include 腾出额度
6	是否计划内切换、TTL 是否已提前降低	先降 TTL，等旧缓存过期再切

第 4、5 两条是多发信系统企业最容易漏的，因为它们在只有一个发信来源时根本不会触发。

配完登录不上，先确认不是解析问题

有一类现象会被误判成解析没生效，实际跟 DNS 无关：记录都对、网页端能收发，但 Outlook、Foxmail 登录失败。

新购买的阿里企业邮箱默认带一条已开启的「三方客户端访问策略」黑名单策略，不允许登录第三方客户端。需要用第三方客户端的账号要在「安全管理－账号安全－访问策略」加为例外或关闭该策略，5 分钟后生效，且该策略同样约束 postmaster 管理员账号[6]。

判断方法很简单：网页端能正常收发，说明 MX 和账号都没问题，这时候继续查解析是在查错方向。交付后每一类配置具体怎么实测，见企业邮箱交付验收清单。

沟通前准备哪些信息

把第 3 项数清楚，往往比配置本身更能决定这次改动顺不顺利。要不要自己动手，可以先算一笔账，见自己配域名邮箱 vs 找人配。

大成云的域名解析与安全认证配置服务覆盖 MX 与主机记录、SPF 发信授权、DKIM 签名、DMARC 策略与伪造报警报表[7]；开通服务的表述里含逐项验证收发[8]。它自述为阿里云官方授权的西南区域服务中心，是授权服务商而非原厂，产品由阿里云原厂提供，开通、迁移、配置与售后在本地完成[9]。委托之前把「谁动手、交付什么、未通过时谁继续处理」写进方案，判断方法见最佳邮箱代理商怎么选，代配置的服务范围见大成云代配置：MX-SPF-DKIM-DMARC 一次到位。

企业邮箱改 DNS 常见问题（FAQ）

不会。DNS 按「名字 + 类别 + 类型」把记录归组，类型不同就是不同的组，不互相替换[1]，所以根域上同时有指向网站的 A 记录和指向邮箱的 MX 记录是正常状态。阿里邮箱也不要求把域名转入阿里云或更改 DNS 服务器，在现有解析服务商处添加记录即可[3]——不动 NS，网站解析链路就没被碰过。唯一会真的顶掉网站解析的情况是同名 CNAME：一个名字上有了 CNAME，就不能再有其他类型的记录[1]。所以动手前只需确认一件事：你要填的那个主机名上现在有没有 CNAME。

不能，必须合并进现有那一条。标准明确同一个所有者名下不允许存在多条 SPF 记录；校验时如果筛出来超过一条，直接返回 permerror[2]。permerror 的定义是记录无法被正确解释、明确需要 DNS 管理方介入处理的错误状态[2]，结果可能比完全没配 SPF 更糟，因为原本能通过的发信来源也一起失效了。合并之后记得顺手数一次 DNS 查询项是否还在 10 个以内。

有硬上限。会触发 DNS 查询的项（include、a、mx、ptr、exists 与 redirect）在一次校验中总数不得超过 10 个，超过必须返回 permerror[2]。关键在于 include 会展开：你写一条，对方的记录里可能还套着好几条，次数是累加的。所以不能按「我写了几项」来算，要按展开后的总数算。接近上限时的解法是用 ip4 直接写地址段替换部分 include，因为 ip4 和 ip6、all 都不触发查询、不占额度[2]。

不能。标准写明作为 MX 记录值一部分的域名不能是别名，它必须能解析到地址记录；并且指出在这个位置用别名既不如预期可靠，也达不到采用这种做法想要的效果[1]。照抄原厂给出的收信服务器地址通常不会有问题，因为那本身就是可直接解析的名字。检查方法：把 MX 右边的主机名单独查一次，看返回的是地址记录还是又跳到另一个名字。

能改回去，但不是即时恢复。解析结果会在各级缓存里停留，改回原值后仍要等缓存过期才全网一致，生效区间是 10 分钟到 48 小时[3]。而且标准说明 TTL 是最长存活时间而非强制时长，各实现还可自行设置上限[1]，所以实际等待时间不完全由你设的 TTL 决定。真正的保险在改之前：按条目留全快照，包含主机记录、类型、值、优先级和 TTL，以及改动前已存在的全部 TXT 记录——优先级和原有 TXT 是两个最容易漏记、又最影响还原的项。

后台显示已保存只证明你提交了，不证明外部查得到。要查公共 DNS 的实际返回值，按原厂给出的解析生效测试方法逐条核对[5]，并对照记录该填什么值[4]。如果短时间内查不到，先等够生效区间再排查[3]——在还没到生效时间的窗口里反复改记录，会让缓存状态更难判断。逐项实测的完整做法见企业邮箱交付后如何验收配置。

不是，这跟 DNS 无关。新购买的阿里企业邮箱默认带一条已开启的「三方客户端访问策略」黑名单策略，不允许登录第三方客户端；需要用的账号要在「安全管理－账号安全－访问策略」加为例外或关闭该策略，5 分钟后生效，该策略同样约束 postmaster 管理员账号[6]。判断依据是网页端：网页端能正常收发就说明 MX 和账号都没问题，这时候继续查解析是在查错方向。

可以，但要把范围写清。大成云的域名解析与安全认证配置覆盖 MX 与主机记录、SPF 发信授权、DKIM 签名、DMARC 策略与伪造报警报表[7]，开通服务的表述里含逐项验证收发[8]。需要在方案里确认的是三件事：配哪几项、配完谁实测、实测结果以什么形式交付。另外解析后台的登录权限通常仍在企业侧，所以要约定是由服务商代操作还是指导企业操作——两者的责任归属不同，判断方法见最佳邮箱代理商怎么选。

References