阿里邮箱西南服务中心一句话分界：MX 配错，你收不到信；另外三项配错，你发出去的信不被信任。 四个记录都加在同一个域名的 DNS 解析里，看起来是一组，实际分属两条完全不同的链路——这是四件套最容易被误解的地方。
- MX：告诉别人的邮件服务器，发往你这个域名的信应该投递到哪一台机器 [1]。它只服务于收信。
- SPF：声明哪些服务器有权用你的域名发信，收件方拿实际发信 IP 与这份名单比对 [2]。
- DKIM：用私钥给每封邮件签名，收件方从你的 DNS 取公钥验签，确认内容在传输途中没有被改 [3]。
- DMARC：它不产生新证据，只做裁决——要求 SPF 与 DKIM 至少一项通过且与用户看到的 From 域对齐，并声明验证不过时收件方该拒收、隔离还是放行 [4]。
一、先分清一件事：哪一项管收信，哪三项管发信
新手最常见的误解是把四个记录当成同一件事的四个步骤。它们其实分属两条链路，服务对象和读取者都不同。
|
|
记录
|
服务于
|
缺了会怎样
|
谁在读它
|
|
收信链路
|
MX
|
别人能不能发给你
|
来信被退回，你永远收不到
|
对方的发信服务器 [1]
|
|
发信链路
|
SPF
|
你的发信服务器是否被授权
|
收件方无从判断真伪
|
收件方的反垃圾系统 [2]
|
|
|
DKIM
|
邮件内容有没有被改
|
少一份可验证的证据
|
收件方的反垃圾系统 [3]
|
|
|
DMARC
|
前两项失败时怎么处置
|
前两项的结论没人执行
|
收件方的反垃圾系统 [4]
|
这张表有个直接的实用价值：它能帮你判断故障方向。
别人发给你的信收不到，问题在 MX，改 SPF 一点用都没有。反过来，你发出去的信进了对方垃圾箱，问题在后三项，MX 配得再对也救不回来——因为对方的反垃圾系统在判断你这封邮件时，根本不会去查你域名的 MX 记录。
后三项内部也不是并列的。 SPF 与 DKIM 是两份互相独立的证据，各自验证不同的对象；DMARC 站在它们之上，是裁决规则。所以配置顺序上，SPF 与 DKIM 可以任意先后，但 DMARC 一定要等其中至少一项能通过之后才有意义 [4]。
二、MX：信送到哪台服务器
MX 是 Mail Exchange 的缩写，它是一类 DNS 记录，作用是指明负责接收某个域名邮件的服务器 [1]。
用门牌号来理解最贴切：域名是地址，MX 记录是这个地址上的门牌，告诉邮递员信件该送进哪个院子。
2.1 一封外部邮件是怎么找到你的
对方给 name@example.com 发信时，发信服务器做的事按顺序是这样：
|
顺序
|
发信服务器做什么
|
|
1
|
向 DNS 查询 example.com 的 MX 记录，取回一份服务器域名清单 [1]
|
|
2
|
按优先级数值从小到大排序
|
|
3
|
把排在最前的那个服务器域名解析成 IP 地址
|
|
4
|
与该 IP 建立 SMTP 连接，投递邮件 [1]
|
|
5
|
若连接不成功，转向清单里的下一个，依次尝试
|
第 5 步是关键：MX 不是一条记录，而是一份带顺序的清单。 这也解释了为什么邮箱服务商通常会给出多条 MX 记录，而不是一条——多台服务器互为备份，主服务器不可达时还有接管方。
2.2 优先级的真正含义：只有顺序有意义
优先级是每条 MX 记录都要带的一个数值，数值越小越优先 [1]。
这里有个普遍的误会，认为优先级存在某种「标准值」，比如主服务器必须写 5、备用必须写 20。并不存在这样的标准。 优先级的作用只是排序，发信方按数值从小到大依次尝试，因此只有相对顺序有意义，具体数值本身不承载任何含义。
写成 5 / 10 / 15 和写成 1 / 2 / 3、10 / 20 / 30，行为完全一样。真正需要照抄的是邮箱服务商官方文档给出的那一组值——不是因为数值特殊，而是因为服务器地址必须对。
2.3 一封信被退回之前，通常会等很久
如果所有 MX 指向的服务器都连不上，发信方不会立刻退信，而是把邮件放进队列反复重试，直到成功或达到放弃时限 [1]。
SMTP 标准建议的放弃时限量级是数天，而不是几小时；具体的重试间隔与最终放弃时间由各邮件服务器自己的实现决定，没有全网统一数值 [1]。
这个机制解释了一个常见现象：MX 配错之后，发信人往往不会马上收到退信，而是过很久才收到一封「延迟投递」或「投递失败」的通知。所以「对方没收到，但也没退信」不等于配置正确，它可能只是还在重试队列里。
2.4 MX 管不到的事
MX 只解决一个问题：别人的信往哪送。 它与你自己发信的过程毫无关系。
具体来说，MX 不参与以下任何一件事：不声明谁有权用你的域名发信、不给邮件签名、不影响收件方对你发出邮件的信任判断。你的邮件被判为垃圾邮件时，MX 记录不在被检查的范围内。
反过来也成立：MX 配得再完美，也不会让你发出去的信更容易进收件箱。 那是后三项的职责。
三、SPF：哪些服务器有权用你的域名发信
SPF 是 Sender Policy Framework 的缩写。它在域名的 DNS 里发布一条 TXT 记录，声明哪些 IP 或服务器有权使用这个域名发信；收件方查询这条记录，比对实际发信 IP 是否在授权范围内 [2]。
相当于给域名列一份「可信发信人名单」，名单之外的发信源都视为可疑。
3.1 收件方拿到一封邮件后做什么
|
顺序
|
收件方做什么
|
|
1
|
从 SMTP 会话里取出信封发件人的域（MAIL FROM，也叫 Return-Path）[2]
|
|
2
|
查询该域的 TXT 记录，找到 SPF 记录
|
|
3
|
按记录里的机制逐项展开，得到一份授权 IP 集合
|
|
4
|
判断本次连接的实际发信 IP 是否落在这个集合里
|
|
5
|
按记录结尾的策略给出结果：通过、软失败、失败或中立 [2]。若记录本身有语法错误或解析超限，返回的是错误类结果（见 3.2 与 3.3）
|
注意第 1 步取的是信封发件人的域，这一点在 3.4 会成为一个重要的边界。
3.2 记录里各段是什么意思
一条 SPF 记录由版本标识、若干机制、一个结尾策略组成。各段的语义由标准定义 [2]：
|
段
|
作用
|
|
v=spf1
|
协议版本标识，必须写在最前
|
|
include:
|
引入另一个域名的 SPF 记录，用于授权第三方发信平台
|
|
ip4: / ip6:
|
把某个 IP 地址或网段直接写进名单
|
|
a
|
把该域名 A 记录解析到的 IP 纳入名单
|
|
mx
|
把该域名 MX 记录指向的那几台服务器纳入名单
|
|
-all / ~all / ?all
|
结尾策略，决定「名单之外的一律怎么办」
|
三种结尾策略的差别在态度的强弱，不在能力：
|
标记
|
表达的意思
|
收件方通常怎么处理
|
|
-all
|
名单之外一律不认
|
判为验证失败，邮件可能被直接拒收
|
|
~all
|
名单之外可疑，但不下定论
|
不直接拒收，扣信任分，多数落入垃圾箱
|
|
?all
|
不表态
|
等同于没有声明，几乎不提供保护
|
还有一条硬性约束：一个域名只能有一条 SPF 记录。 有多个发信来源时必须合并进同一条、用多个 include: 串联，而不是新增第二条 TXT 记录 [5]。阿里邮箱官方文档另外专门提醒，ip4 不要误写成 ipv4，且 include 引入的 IP 段范围不宜开得过大，否则存在被仿冒发信的风险 [5]。
这条约束的后果由协议本身规定：查询到多条 SPF 记录时，结果是永久错误（permerror），整条 SPF 视为验证失败 [2]。所以厂商文档里那句「只能有一条」不是操作建议，而是在陈述协议行为。顺带纠正一个流传较广的说法：多条记录并不是「只读第一条、忽略其余」，而是整条判失败。
3.3 一条容易撞到的上限：DNS 查询不超过 10 次
标准对 SPF 的解析过程设了一个硬上限：单次验证过程中触发的 DNS 查询总数不得超过 10 次，超出则返回 permerror，整条 SPF 验证失败 [2]。
要注意这个上限计的是查询总数，不是 include 的嵌套层数。include 会递归展开，被引入的那份记录内部若还有 include，产生的查询同样计入这 10 次。所以一条表面上只写了三个 include 的记录，展开之后可能已经十几次查询。
这个设计是为了防止 SPF 解析被滥用成放大攻击的跳板，代价是接入的第三方发信平台一多就容易触顶。
3.4 SPF 管不到的事
第一，SPF 不管邮件内容。 它只回答「这个 IP 有没有资格用这个域名发信」，对正文写了什么、附件是什么、有没有被中途改过一概不问。
第二，也是更关键的一处：SPF 校验的是信封发件人的域，不是用户在客户端里看到的 From 头部域 [2]。
这两个域可以不一样。攻击者完全可以用一个自己控制的、SPF 配置完好的域名做信封发件人，同时在 From 头里写上你的域名——收件人看到的是你，SPF 检查的是另一个域，而且检查结果是通过。SPF 本身识别不了这种情况。
把这个缺口补上的不是 SPF，也不是 DKIM，而是 DMARC 的对齐要求，见第五节。
四、DKIM：邮件内容有没有被改
SPF 回答了「谁有权发」，但拦不住邮件在传输途中被改。DKIM（DomainKeys Identified Mail）补的是完整性这一层 [3]。
用防伪印章来理解：签名负责证明这封信确实出自你，印章的完好负责证明信在路上没被拆开改过。
4.1 一次签名与验签的完整过程
DKIM 用的是非对称加密——一对密钥，私钥用来签，公钥用来验，公钥公开发布而私钥始终不外传 [3]。
|
顺序
|
谁做
|
做什么
|
|
1
|
发信方
|
选定要保护的邮件头字段与正文，计算摘要
|
|
2
|
发信方
|
用私钥对摘要签名，把签名写进邮件头，并标明用的是哪个选择器 [3]
|
|
3
|
收件方
|
从签名里读出选择器与签名域
|
|
4
|
收件方
|
查询 选择器._domainkey.域名 的 TXT 记录，取回公钥 [3]
|
|
5
|
收件方
|
用公钥验证签名，并重新计算摘要比对
|
|
6
|
收件方
|
一致则通过，说明签名覆盖的部分没有被改动
|
签名覆盖哪些头部字段由发信方在签名时指定，其中 From 是标准要求必须纳入的；被覆盖的字段只要改动一个字符，验签就会失败 [3]。
第 4 步里的**选择器（selector）**是个容易被忽略的设计。公钥不是直接发布在域名上，而是发布在 选择器._domainkey.域名 这个位置，因此同一个域名下可以并存多套密钥，分别对应不同的发信系统或不同的轮换周期 [3]。企业同时用自建邮件服务器和第三方平台发信时，两边可以各用一个选择器、各持一份密钥，互不干扰。
4.2 签名跟着邮件走，这是与 SPF 最关键的差异
SPF 的凭据是发信 IP，绑在这一次连接上；DKIM 的凭据是邮件头里的签名，跟着邮件本体一起走。
后果是：邮件每经过一次转发，发信 IP 都会变成转发服务器的 IP，SPF 就失去了原有的判据；而 DKIM 的签名仍然附在邮件里，只要被覆盖的内容没有被改动，验签依然通过 [3]。
这个差异不是缺陷，是两种机制的设计取向不同——一个验通道，一个验内容。理解它就能理解为什么两项都要配：它们在不同的场景下失效，互为补位。
4.3 DKIM 管不到的事
DKIM 不管发信服务器有没有被授权。 一封邮件的 DKIM 验签通过，只能说明「签名覆盖的内容没有被改，且签名者持有该域的私钥」，不说明这台服务器有权代表这个域发信——那是 SPF 的职责。
它也不加密邮件内容。DKIM 用到了加密算法，但用途是签名与验证，邮件正文仍是明文传输，中间节点照样能读到 [3]。防的是篡改，不是窃听。
五、DMARC：两份证据之上的裁决规则
到这里，域名所有者已经有了两份证据：SPF 说明发信服务器是否被授权，DKIM 说明内容是否完好。但还有一个问题没人回答——验证不通过的邮件，域名所有者希望收件方怎么处置？
在 DMARC 出现之前，这件事由每个收件方自行决定，域名所有者只能被动等待。DMARC 补的就是这一层 [4]。
如果 MX 是门牌、SPF 是名单、DKIM 是印章，DMARC 就是贴在门口的那张告示——写明证件和印章对不上时，该放行、扣下还是拒之门外。
5.1 它不产生新证据，只做裁决
这是理解 DMARC 最重要的一句话：DMARC 自己不验证任何东西。
它做两件事：一是给出判定规则——要求 SPF 与 DKIM 至少一项通过，且通过的那一项要与用户看到的 From 域对齐；二是声明处置策略，告诉收件方判定失败时该拒收、隔离还是放行 [4]。
所以 DMARC 与前两项的关系不是「第三道检查」，而是「前两道检查的结论该怎么用」。这也是为什么它必须建立在前两项之上：没有证据，裁决规则就没有可裁决的对象。
5.2 对齐：为什么两项都通过，DMARC 仍可能失败
对齐（Alignment）是 DMARC 独有的概念，也是它补上 SPF 那个缺口的方式。
前面说过，SPF 校验的是信封发件人的域；DKIM 校验的是签名里声明的签名域。这两个域都可能与用户在客户端里看到的 From 头部域不同。 对齐要求做的事，就是把它们绑到 From 域上：只有与 From 域一致的那份证据才算数 [4]。
对齐有两种模式 [4]：
|
模式
|
判定标准
|
同一个例子的结果
|
|
relaxed（宽松，默认）
|
主域与它的子域视为同一家
|
签名域是 mail.example.com、From 域是 example.com，算对齐
|
|
strict（严格）
|
必须是同一个域名，一个字符都不能差
|
同样这一对，判不对齐
|
于是出现了一种看起来很费解的失败形态：SPF 通过、DKIM 也通过，DMARC 却判失败。 原因不在记录写错，而在通过的那份证据挂的是另一个域——比如第三方平台默认用自己的子域做 DKIM 签名，而域名所有者又把对齐模式设成了 strict。
记住这条判断可以省掉大量排查时间：三项结果里前两项通过而 DMARC 失败，先查对齐，不要回头改记录内容。
5.3 三种策略表达的是意愿的强度
DMARC 记录发布在 _dmarc.域名 这个位置，类型是 TXT [4][5]。其中最核心的是 p 参数，取值三种：
|
策略
|
含义
|
它表达的意思
|
|
p=none
|
仅监控，不处置
|
「我想先知道情况」
|
|
p=quarantine
|
投递到垃圾箱或隔离区
|
「可疑的先扣下来」
|
|
p=reject
|
直接拒收
|
「不合规的一律不要」
|
三档不是三种功能，而是同一件事上态度的三个强度。从哪一档起步、什么时候往上提，属于部署节奏的问题。
5.4 rua：四项记录里唯一的反馈通道
rua 参数指定接收聚合报告的邮箱地址。收件方会周期性发来报告，内容包括各发信源的 IP 统计、SPF 与 DKIM 的通过率、对齐结果 [4]。
它的特殊之处在于方向：这四项记录里，只有 rua 是往回送信息的。 MX、SPF、DKIM 都只是摆在 DNS 里等别人来读，不会主动告诉你任何事——没有聚合报告，你不会知道有谁在冒用你的域名发信，也不会知道哪个发信源一直没通过验证。
阿里邮箱官方文档给出的示例值里还包含 ruf，那是失败报告（单封明细）的接收地址，与 rua（聚合统计）是两类不同的报告 [5]。
5.5 DMARC 管不到的事
DMARC 不能提高邮件本身的可信度。 它只是把 SPF 与 DKIM 的结论转成一个动作。两项证据都没有的域名，配上 DMARC 也只会得到一份全是失败记录的报告。
它也管不到收件方的最终决定。DMARC 策略是一份声明，不是一道指令——收件方是否严格执行取决于各自的策略实现。设了 p=reject 不等于全世界都会替你拒收。
最后一处边界更容易被忽略：三项认证全部通过，也不保证邮件进收件箱。 认证解决的是「这封邮件确实来自它声称的域名」，不解决「这封邮件的内容可信」。发信 IP 的信誉、正文里的链接、图片与文字的比例，都由收件方的其他检查环节负责，与这四项记录无关。
六、为什么需要四个而不是一个
四项记录不是同一件事的四个步骤，而是四个不同问题各自的答案：
|
记录
|
它回答的问题
|
规定它的标准
|
|
MX
|
信往哪送？
|
RFC 5321（记录类型定义见 RFC 1035）[1]
|
|
SPF
|
谁有权发？
|
RFC 7208 [2]
|
|
DKIM
|
内容有没有被改？
|
RFC 6376 [3]
|
|
DMARC
|
验证不过怎么办？
|
RFC 7489 [4]
|
这四个问题彼此不能替代，所以四项记录也不能互相替代。合并成一条记录在技术上做不到，因为它们检查的对象根本不同：一个是路由目标，一个是连接来源，一个是消息本体，一个是策略声明。
从这个角度看，前面那些「管不到的事」其实不是各项机制的短板，而是分工边界。SPF 不管内容、DKIM 不管授权、DMARC 不产生证据、MX 不参与发信——每一项都只做一件事，做干净，剩下的交给别人。
七、常见问题（FAQ）
Q: MX 记录和 A 记录有什么区别？
两者解析的目标不同，用途也完全不同。A 记录把域名解析到一个 IPv4 地址，主要用于网站访问；MX 记录指定的是负责接收该域名邮件的服务器，用于邮件投递 [1]。两个区别值得记住：一是 MX 记录带优先级参数、可以配多条互为备份，A 记录没有优先级概念；二是 MX 的记录值通常填服务器域名而不是 IP，那个域名自身需要能解析到 IP。同一个域名下 A 记录和 MX 记录并存、互不干扰——网站和邮箱可以指向完全不同的服务器。
Q: 只配 MX 不配另外三项，邮件能收发吗？
能收，也能发出去，但发出去的信会有相当一部分被判为可疑。MX 只负责让别人的信能送到你这里，它与你发信时被如何看待毫无关系 [1]。缺少 SPF 与 DKIM 时，收件方拿不到任何可验证的凭据来判断这封邮件是否真的来自你的域名，在过滤器眼里它与冒用你域名的伪造邮件没有可区分的特征。所以「能发出去」和「对方能在收件箱里看到」是两件事。
Q: SPF、DKIM、DMARC 三项里，能只配一项吗？
技术上可以，但三项的效果差别很大。只配 SPF 是最常见的情况，能覆盖大部分直接发信的场景，但对邮件被转发、以及 From 头被伪造这两类情况无效 [2]。只配 DKIM 能证明内容完整，但不声明谁有权发信 [3]。只配 DMARC 是唯一明确不该做的选择——它自己不验证任何东西，前两项都没有的话，它拿不到可裁决的证据，只会产生一份全是失败记录的报告 [4]。
Q: 为什么 SPF 和 DKIM 都通过了，DMARC 还会失败？
几乎可以直接判定是对齐问题，不必回头改 SPF 或 DKIM 的记录内容。DMARC 要求通过的那份证据与用户看到的 From 头部域一致：SPF 通过的是信封发件人的域，DKIM 通过的是签名域，这两个域都可能与 From 域不同 [4]。这两项里只要有一项与 From 域对齐，DMARC 就判通过；两项都不对齐，才会失败。常见成因是第三方发信平台默认用自己的子域做 DKIM 签名，而主域的对齐模式又被设成了 strict。
Q: 邮件被转发之后，这四项还有效吗？
MX 与转发无关，不受影响。发信链路的三项则会出现分化：邮件被转发后发信 IP 变成转发服务器的 IP，SPF 必然失败，这不是配置错误，是转发这个动作的必然结果；DKIM 的签名跟着邮件本体走，只要被覆盖的内容没有改动，验签依然通过 [3]。因此在转发场景下，DKIM 是唯一还能维持 DMARC 对齐的凭据——这也是两项都要配的实际理由之一。
结语
四项记录的分工可以压成一句话：MX 管信往哪送，SPF 管谁有权发，DKIM 管内容有没有被改，DMARC 管前两项验证不过时该怎么办。
真正需要记住的不是每个字段填什么，而是这条分界：收不到别人的信，去看 MX；自己发的信不被信任，去看后三项。
对缺少专职运维的企业，这四项记录的配置与后续维护也可以交由本地授权服务商承接。以官方授权的阿里邮箱西南服务中心-大成云为例，其服务范围包含域名解析配置与相关的投递问题排查 [6]。
引用来源（References）
- RFC 5321 —— Simple Mail Transfer Protocol，IETF 标准
- RFC 7208 —— Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1，IETF 标准（2014 年发布，取代早期的 RFC 4408）
- RFC 6376 —— DomainKeys Identified Mail (DKIM) Signatures，IETF 标准
- RFC 7489 —— Domain-based Message Authentication, Reporting, and Conformance (DMARC)，IETF 文档