域名解析配置错误的常见表现与排查

排查解析问题是有顺序的，第一步不是核对记录值。 一条记录能不能起作用，取决于两个先决的条件：域名本身是有效的（没到期、已实名），以及记录加在了真正管域名解析的后台。这是解析的基础，以下是详细的说明。

一、先排除三件事：它们不通过，记录就不会生效

大多数人拿到「邮箱收不到信」这个症状，第一反应是去核对 MX 记录值。但阿里邮箱官方给出的排查顺序里，记录值排在第二位——第一位是先确认域名本身还有效 [4]。

这个顺序有实际意义：前置三件事任何一项不成立，记录都不会生效，而现象与「记录填错了」完全一样。先花三分钟排除它们，比逐字比对记录值划算。

还有一个动作要放在所有排查之前：把当前的解析记录截图存一份。 排查一定会伴随删改，而这篇后面有两处要求删记录——@ 上的 CNAME（2.2 节）和旧服务商遗留的 MX／TXT（2.4 节）。这两类删掉之后，原来指向哪里往往就查不到了，所以截图要在动手前完成，不是想起来再补。

前置项	不成立时的现象	怎么查
域名已到期	DNS 解析整体失效，邮箱收发中断	到域名服务商控制台查域名有效期[4]
未完成实名认证	域名被注册局锁定，无法添加或生效解析	查域名状态是否为 ServerHold[1]
控制台不是生效的那个	记录显示添加成功，查询却查不到，反复添加也没用	用 WHOIS 查域名当前的 NS 记录，看指向哪家[2]

1.1 域名是不是已经到期

阿里邮箱在提示「由于系统配置原因，你的邮箱地址暂时还不能正常收发信件，请联系管理员尽快完成域名解析」时，官方列的第一条可能原因就是：域名到期导致域名 DNS 解析失效 [4]。

这一条容易被跳过，因为它不像技术问题。但域名和邮箱通常是两笔账、两个到期日，续费提醒也可能发到已经离职的人的邮箱里。查一次只要打开域名服务商控制台看有效期，花不了一分钟。

1.2 域名有没有完成实名认证

这是中国大陆特有的一道关卡，而且它的规则比「记得去实名」复杂。官方给出的完整口径是 [1]：

第二条和第三条一起看，就能解释一个很迷惑的现象：域名刚注册那几天解析是能加的，过了几天忽然全部失效。 那不是配置被改了，是短暂解锁的窗口过去、域名被重新锁上了。遇到这种时间特征，先查域名状态，不要去查记录值。

官方给的解析流程顺序也印证了这一点：注册域名 → 实名认证 → 登录控制台 → 邮箱搬家（可选）→ 添加或切换解析 [1]。实名认证排在添加解析之前，是前置条件不是并行项。

1.3 你加记录的那个控制台，是不是生效的那个

这一条是「每条记录都填对了，查询却查不到」的头号原因，也最反直觉。

官方的表述是：当域名的 DNS 服务器指向非阿里云的 DNS 服务商（例如 Cloudflare、Hostinger 等）时，在阿里云域名控制台添加的解析记录不会生效，因为域名解析实际由第三方 DNS 服务器管理 [2]。

换句话说，域名注册在哪里、和域名解析由谁管，是两件可以分开的事。很多企业的域名注册在阿里云，但当初为了套 CDN 或者建站方便，把 NS 改到了别家——之后所有解析都只在别家的后台生效，阿里云控制台里那些记录只是躺在那里。

官方给了两条解决路径 [2]：

绝大多数情况该走方法一。方法二会把一个邮箱问题扩大成整站问题，只有在原 DNS 后台确实进不去的时候才考虑。

顺带说明一件常被误解的事：使用阿里邮箱不需要把域名转入阿里云，也不需要强制把 DNS 服务器改到阿里云。只要拥有该域名的 DNS 管理权限，在当前 DNS 服务商处添加对应记录就可以；阿里邮箱也支持跨阿里云账号、跨国际站与国内站绑定域名 [2]。

如果原域名注册商已经失联、或者 DNS 后台登不进去，官方的建议是通过注册商官方渠道找回账号，或通过正规渠道把域名转移到可管理的注册商——但域名转移通常需要数天，要提前规划 [2]。

二、症状一：收不到邮件，先看 MX

前置三件事排除之后，「收不到邮件」这个症状基本可以锁定在 MX 记录上。下面三节是真正会导致收不到信的三类根因——记录值不属于同一组、@ 上有 CNAME 挡着、旧记录没删；2.3 那一节不是根因，是纠正两个流传较广的误判，因为按错的方向查会白花时间。

2.1 官方有两组解析记录，挑一组，不要混用

这是排查时最容易被忽略的一处。阿里邮箱官方文档给了两组解析记录，并明确「早期的解析参数和新的解析参数一样，都可以正常使用，新老参数挑选其中一组进行配置即可」 [2]。官方对这两组的定名是「标准解析记录（适用于各版本阿里邮箱，除集团邮）」和「集团邮／旧版解析记录」 [1]。

记录类型	主机记录	优先级	标准解析记录	集团邮／旧版解析记录
MX	@	5	mx1.qiye.aliyun.com	mxn.mxhichina.com
MX	@	10	mx2.qiye.aliyun.com	mxw.mxhichina.com
MX	@	15	mx3.qiye.aliyun.com	（旧版无第三条）
CNAME	imap	—	imap.qiye.aliyun.com	imap.mxhichina.com
CNAME	pop3	—	pop.qiye.aliyun.com	pop3.mxhichina.com
CNAME	smtp	—	smtp.qiye.aliyun.com	smtp.mxhichina.com
CNAME	mail	—	qiye.aliyun.com	mail.mxhichina.com
TXT	@	—	v=spf1 include:spf.qiye.aliyun.com -all	同左，两组一致

两点要特别留意。第一，SPF 值在两组里是同一个——spf.qiye.aliyun.com，注意中间有 qiye，写成 spf.aliyun.com 会导致验证取不到值。第二，网上流传的配置示例往往只给其中一组的 MX、却配另一组的 CNAME，新旧混配是「记录都加了但有的功能不通」的典型成因。排查时先确认现有记录属于哪一组，再统一到同一组。

2.2 @ 上已经有 CNAME，MX 就加不进去

这一条的症状很有辨识度：在控制台点「一键添加邮箱解析」，提示**「添加失败，请重试」**，重试多少次都一样 [1]。

根因不是网络问题。按 DNS 规范，MX 记录与 CNAME 记录不能共存于同一主机名（例如 @）；如果之前给 @ 配过 CNAME（常见于把根域名指向建站平台），必须先删掉那条 CNAME 才能添加 MX。官方另有《解析记录冲突规则》专篇说明各类记录的共存关系 [1]。

要注意这个删除动作有业务影响：@ 的 CNAME 往往正撑着官网访问。所以正确做法是先确认那条 CNAME 是谁在用、能不能改成 A 记录或换到 www 上，再动手，不要为了加 MX 直接删掉 [1]。

2.3 优先级和条数：官方口径和常见误解不一样

关于优先级，官方的准确表述是 [1]：一个域名可以配置多条 MX 记录；优先级数值越小、优先级越高；发送方会优先尝试连接数值最小的服务器，只有当高优先级服务器不可用时，才会尝试低优先级的。

由此可以纠正两个流传较广的说法：

真正会导致收不到信的是记录值填错、主机记录没填 @、或者记录根本没生效。

2.4 旧服务商遗留的记录没删

换邮箱服务商之后，DNS 里可能同时挂着两套记录。官方在排查清单里明确要求：检查是否存在其他邮件服务商遗留的 MX 记录或 TXT 记录（如旧的 SPF 记录），如有请先删除，再添加阿里邮箱的解析记录 [2]。

这里有两点常被漏掉。一是旧的 TXT／SPF 也要删，不只是 MX——旧 SPF 留着会和新 SPF 构成「两条 SPF」，直接触发第三节那条硬规则。二是判断依据是「记录值不属于当前在用的那一组」，不需要去记各家服务商的服务器地址：把现有 MX 与 TXT 逐条对照 2.1 那张表，不在表里的就是待清理项。

2.5 确认记录到底生效了没有

改完之后不要靠邮箱后台的状态判断，用命令直接查。官方给出的验证方式是 [3]：

平台	查 MX 记录	查 TXT 记录（SPF）
Windows	nslookup -type=mx example.com	nslookup -type=txt example.com
Mac／Linux	dig mx example.com +short	dig txt example.com +short

把 example.com 换成自己的域名。返回值与 2.1 表中同一组的记录值一致，就说明这一侧没问题，可以往下排查投递环节。

不习惯命令行的，官方在解析指南里也给了图形化的核对路径——阿里云域名解析控制台自带解析查询工具，输入域名即可看到当前各类记录的返回值 [3]。两条路径查的是同一件事，命令行的好处是能绕开控制台自身的显示缓存，所以判断「到底生效没有」时优先用命令。

三、症状二：域名验证失败或发信被拒，先看 SPF

邮箱后台反复提示未通过 SPF 验证，或者发出去的信被退回，问题基本在这条 TXT 记录上。官方把「邮件被拒收（SPF 失败）」的成因归为三类：SPF 未配置、语法错误、投递 IP 不在 SPF 范围内 [3]。

3.1 两条硬规则

第一条，每个域名只能有一条 SPF 记录。 官方原文：SPF 记录只能有一条，如果有多个出口 IP，请合并到一条 [3]。所以「再加一条给新服务商用」这个动作本身就是错的——多条并存会让验证失败，而不是取其中一条生效。

第二条，记录类型是 TXT，主机记录填 @，值以 v=spf1 开头。 阿里邮箱的标准值是 v=spf1 include:spf.qiye.aliyun.com -all，新旧两组解析参数共用这一个值 [1]。

官方还给了一条容易忽略的安全提醒：合并多个出口时务必确保这些 IP 可信，若 IP 段范围过大、包含了他人的 IP，存在被仿冒发信的风险 [3]。

3.2 四种写错法，与官方的语法示例

写错的形式	后果	正确做法
挂了两条以上 SPF 记录	验证失败。常见于换服务商时新增了一条、旧的没删	合并成一条，用多个 include: 串联 [3]
include: 的域名拼错，例如漏掉 qiye 写成 spf.aliyun.com	取不到授权列表，验证失败	按官方值逐字符核对 [1]
ip4 写成 ipv4	语法错误	官方专门提醒：ip4 不要写成 ipv4 [3]
加在了子域上（例如 mail.example.com）而不是主域	主域发信仍然验不过	主机记录填 @ [1]

官方给出的三种合并语法可以直接照用 [3]：

场景	语法示例
域名 + 域名	v=spf1 include:spf.qiye.aliyun.com include:spf1.dm.aliyun.com -all
域名 + 单个 IP	v=spf1 include:spf.qiye.aliyun.com ip4:x.x.x.x -all
域名 + IP 段（官方标注「谨慎」）	v=spf1 include:spf.qiye.aliyun.com ip4:x.x.x.x/24 -all

3.3 有多个域名的，每个域都要单独配一份

这一条在多品牌、多主体的企业里踩得最多。官方对多域与域别名场景的要求是：每个域独立配置 MX 记录，并且 SPF、DKIM、DMARC 需为每个域单独生成 [3]。

也就是说主域配好了，别名域不会自动继承。症状表现为「主域发信正常，用别名域发信一律进垃圾箱或被拒」——遇到这种一半正常一半不正常的情况，先确认是不是按域漏配了。

四、症状三：进垃圾箱或被标未验证，看 DKIM 与 DMARC

邮件能发出去、对方也收到了，但落在垃圾箱里，或者被标记为未验证。这一层不再是「通不通」的问题，是收件方信不信的问题。

4.1 修复顺序：先把收发弄通，再处理信誉

顺序不能反。官方在配置说明里把这层关系写清楚了：需要先配置好 MX 记录用于收信，才能正常发信；同时收信方通常会对 SPF、DKIM、DMARC 有配置要求 [3]。

所以排查动作是：先确认 MX 与 SPF 已经通过（第二、三节），再来补 DKIM 和 DMARC。反过来做，会把「记录没生效」和「收件方不信任」两类问题混在一起，多花几倍时间。

4.2 DKIM 签名无效：官方的三个检查点

DKIM 的记录值不是通用值，需要从邮箱后台取：主机记录形如 default._domainkey，记录值由邮箱管理员登录管理后台，进入企业定制—域名管理—域名设置查看 [1]。

签名无效时，官方列了三个检查点 [3]：

第三条最容易漏。改过密钥位数却没回到配置界面确认，签名不会生效，而 DNS 里那条记录看起来是新的——这也是「记录明明改了却没用」的一种。官方在解析记录表的备注里同样提醒：若后期切换了加密位数，需要获取新记录值重新配置解析 [1]。

4.3 DMARC 从 p=none 起步

DMARC 的作用是告诉收件方，SPF 或 DKIM 验不过时该怎么处理。官方给的示例值主机记录为 _dmarc，值为 [1]：

两个邮箱地址要换成本组织能正常接收邮件的地址，用于接收收信方的报告；官方建议使用同域邮箱 [3]。rua 收聚合统计，ruf 收失败明细，是两类不同的报告。

关于策略强度，官方两篇文档给的示例不同：一篇用 p=none（只监控不拦截）[1]，另一篇用 p=quarantine（隔离）[3]。排查场景下应当从 p=none 起步——先让报告跑几天，确认自己的发信来源都能通过验证，再收紧。一上来就用 quarantine 或 reject，会把还没配好 SPF 的那些发信来源（营销平台、CRM、工单系统）发出的正常邮件一起拦掉，反而制造新故障。

五、症状四：改完不生效，先分清还没生效和不会生效

改完记录刷新半小时没反应，这时候要先分清两种情况：还没生效是等待问题，不会生效是第一节那三件前置没过。判据很简单——用 2.5 那条命令查，能查到新值就是在扩散中，查不到且已经等够时间，就回第一节。

5.1 官方两篇文档的生效时长口径不一致

这一点值得如实说明，因为网上的说法五花八门，而阿里官方自己的两篇文档给的也不是同一个数：

出处	官方表述
阿里云（万网）域名设置解析 [1]	DNS 解析全球生效通常需要 10 分钟至 24 小时 不等，一般 10 分钟左右即可生效
非阿里云域名设置解析 [2]	DNS 解析记录通常需要 10 分钟至 48 小时 在全球范围内生效
修改 DNS 服务器（NS）时 [2]	全球生效通常需要 24 至 48 小时

实用的读法：下限一致（约 10 分钟），上限取更长的那个来留余量。 差异本身也有解释力——域名和 DNS 都在阿里云时链路更短，指向第三方 DNS 时多一层，等待时间自然拉长。所以如果你的域名 NS 指向别家，就按 48 小时规划，不要按 24 小时催。

另外要当心一个流传很广、但在上述官方文档里找不到出处的说法——「新增记录实时生效」。按这个偏乐观的口径去判断，很容易把「还在扩散」误读成「配错了」，然后开始反复改动记录，而这会让不同地区的缓存状态更乱。等待期内唯一该做的事是用命令查，不是改。

5.2 官方给的两个动作

改完就等，用命令确认新值已返回再做收发测试。已经排期的变更，可以在动手之前先把记录的 TTL 值调低，验收通过后再改回原值——TTL 决定各级 DNS 缓存这条记录多久，调低能缩短等待窗口。

5.3 一种看起来是故障、其实可以忽略的提示

这一条值得单独写出来，因为它会让人白排查一整轮。

登录阿里邮箱首页时，可能看到提示「在用邮箱域名 MX 记录未指向企业邮服务，会无法成功接收外域发送或答复的邮件」。官方的处理建议是：如果本地测试 MX 解析已生效且能正常收发邮件，此提示仅为网页端界面缓存或检测延迟所致，可以忽略，不影响实际使用 [1]。

判据就是 2.5 那条命令加一次实际收发。命令返回正确、内外域收发都正常，就不必理这个提示。后台的状态显示不是权威判据，DNS 查询结果才是。

六、一张症状对照总表

出问题时对照着看。第二列是本文的核心主张——每一类症状都先排除前置，再看记录本身。

症状表现	先排除什么	最常见根因	修复动作	生效预期
收不到邮件／提示尽快完成域名解析	域名是否到期；是否已实名；记录加在哪个控制台	MX 记录值填错或主机记录不是 @；@ 上已有 CNAME 导致 MX 加不进去；旧服务商 MX 未删	按标准组或旧版组统一记录值；先处理 @ 的 CNAME 冲突；删除不在表内的遗留 MX	10 分钟至 48 小时 [1] [2] [4]
域名验证失败／发信被退回	域名是否到期；是否已实名；记录加在哪个控制台	SPF 多于一条；include 域名拼错（漏 qiye）；ip4 写成 ipv4；加在子域上	合并为一条 TXT，主机记录 @，值取官方标准值	10 分钟至 48 小时 [1] [3]
进垃圾箱或被标未验证	MX 与 SPF 是否已通过	DKIM 公钥被换行截断、选择器不一致、切换过密钥位数未重进配置界面；DMARC 缺失	从后台取 DKIM 记录值重配；DMARC 从 p=none 起步观察报告	10 分钟至 48 小时 [1] [3]
改完迟迟不生效	先用命令判断是「查不到」还是「还在扩散」	查不到：前置三件事未过，或记录加在了不生效的控制台；查得到：缓存还在刷新	查不到回第一节；查得到就等，别反复改	上限按 48 小时 [1] [2]
多个域名，一部分正常一部分不正常	是否按域各配了一份	别名域没有独立的 MX／SPF／DKIM／DMARC	每个域单独配置全套记录	10 分钟至 48 小时 [3]

七、常见问题（FAQ）

阿里官方两篇文档给的口径不完全一致：域名与 DNS 都在阿里云时，官方表述为全球生效通常需要 10 分钟至 24 小时，一般 10 分钟左右即可生效 [1]；DNS 在第三方服务商时，官方表述为通常需要 10 分钟至 48 小时 [2]。如果改动的是 DNS 服务器（NS 记录）本身，官方给的是 24 至 48 小时 [2]。实用的读法是下限约 10 分钟、上限按更长的那个留余量。判断有没有生效不要看后台状态，用 nslookup -type=mx 你的域名 直接查 [1]。

大概率是记录加在了不生效的那个控制台。官方说明：当域名的 DNS 服务器指向非阿里云的 DNS 服务商（如 Cloudflare、Hostinger 等）时，在阿里云域名控制台添加的解析记录不会生效，因为解析实际由第三方 DNS 服务器管理 [2]。做法是先用 WHOIS 查询域名的 NS 记录，确认当前真正生效的 DNS 服务商，登录那一家的后台添加记录；也可以把 NS 改回阿里云，但官方提示这会导致域名下原有网站及其他服务的解析短暂失效，且全球生效通常需要 24 至 48 小时 [2]。

常见原因是主机记录 @ 上已经存在一条 CNAME 记录。按 DNS 规范，MX 记录与 CNAME 记录不能共存于同一主机名，必须先删除 @ 的 CNAME 才能添加 MX [1]。要注意 @ 的 CNAME 往往正撑着官网访问，删之前先确认它的用途、评估能否改成 A 记录或迁到 www 上，不要为了加 MX 直接删掉 [1]。

不一定有问题。官方明确：若 DNS 服务商不支持添加多条 MX 记录，优先添加优先级为 5 的 mx1.qiye.aliyun.com，可满足基本的邮件收发需求 [2]。多条 MX 的作用是主备——官方口径是优先级数值越小优先级越高，发送方优先连数值最小的服务器，只有高优先级不可用时才尝试低优先级 [1]。所以看到只有一条 MX 时，不要先把它当成收不到信的原因。

不能混。阿里邮箱官方同时提供两组解析参数，一组是标准解析记录（适用于各版本阿里邮箱，除集团邮），另一组是集团邮／旧版解析记录，官方说明两组都可以正常使用，但新老参数挑选其中一组进行配置即可 [1] [2]。实践中「MX 用了新组、CNAME 还留着旧组」是记录都加了但部分功能不通的典型成因。两组的 SPF 值是同一个 v=spf1 include:spf.qiye.aliyun.com -all [1]。

会，而且是硬阻断。官方说明自 2016 年 7 月 18 日起 .com／.net 域名注册后必须实名认证，否则会被注册局锁定（ServerHold），导致无法添加或生效解析 [1]。有个容易迷惑的时间特征：注册成功后会自动提交命名审核（1 至 2 天），审核通过后状态会短暂解除锁定；若注册 5 天内未提交实名资料并通过审核，域名会再次被锁定 [1]。所以「刚注册那几天能加解析、过几天全部失效」通常不是配置被改，是域名被重新锁上了。

不能。官方原文是 SPF 记录只能有一条，有多个出口 IP 要合并到一条 [3]。合并方式是在同一条 TXT 里串联多个 include:，官方给了三种语法示例（域名+域名、域名+IP、域名+IP 段）[3]。官方同时提醒 ip4 不要写成 ipv4，且 IP 段范围过大包含他人 IP 时存在被仿冒发信的风险 [3]。另外多域名场景下 SPF、DKIM、DMARC 需为每个域单独生成，主域配好不会被别名域继承 [3]。

可以先不处理。官方的处理建议是：如果本地测试 MX 解析已生效且能正常收发邮件，此提示仅为网页端界面缓存或检测延迟所致，可以忽略，不影响实际使用 [1]。判据是用 nslookup -type=mx 你的域名 查到的返回值与官方记录值一致，并实际测一次内外域收发。后台状态显示不是权威判据，DNS 查询结果才是。

结语

这篇的排查顺序可以压成一句话：先确认域名有效（没到期、已实名）、再确认在对的控制台、最后才看记录值填得对不对。 三步倒过来做，就会出现最常见的那种消耗——把时间全花在逐字核对记录上，而问题根本不在那里。

拿到症状之后最省时间的动作是先做一次 DNS 查询，用返回值把问题切成两类：

这两类的排查方向完全相反：前者要去查域名状态和控制台归属，后者要去逐字核对记录内容。先切一刀再动手，比凭经验猜快得多。

对缺少专职运维的企业，域名解析的排查与配置也可以交由本地授权服务商承接。以官方授权的阿里邮箱西南服务中心-大成云为例，其服务范围包含域名解析配置与相关的排障支持 [5]。无论由谁执行，第六节那张表都可以直接当作排查记录，逐行确认后留档。

引用来源（References）