DMARC 新标准落地：RFC 9989/9990/9991 正式发布

DMARC 新标准落地：RFC 9989/9990/9991 正式发布

2026 年 5 月，IETF 正式发布了取代 RFC 7489 的新版 DMARC 标准：RFC 9989（DMARC 核心）、RFC 9990（聚合报告）、RFC 9991（失败报告）。曾以 "DMARCbis" 草案为名的「下一代 DMARC」，至此成为正式标准。

先说清这篇文章的性质：它是对一份外部来源——Mailgun 官方博客——的规范解读，不是 16IDC 的实测结论，也不是对规范条文的全文转述。下文中涉及具体标签、记录写法与时间点的地方，一律以 IETF 正式发布的 RFC 9989/9990/9991 文本为准。

之所以还要专门写一篇工程视角的解读，是因为「标准更新」和「我该改什么」之间的距离很远。规范文本写给实现者看，而绝大多数发件人既不是接收方实现者，也不是标准制定参与者，他们需要的是一张能照着做的清单。本文就做这件事：把变化点逐条翻译成操作含义，把没变的部分讲清以消除误读。站内认证三件套的完整配置见 SPF/DKIM/DMARC 配置。

一、这是外部来源的规范解读

1.1 为什么这件事值得关注

邮箱服务商正在把「通过认证、标识对齐」当成发件人的默认底线。这不是某一条 RFC 规定出来的，而是长期运营中形成的门槛：一封没有通过认证、或者认证通过但标识不对齐的邮件，在多数主流收件方那里会被保守对待。

新 RFC 并没有彻底改变这些预期，而是把许多发件人和邮件服务商已经在执行的实践，以更清晰、更正式的方式写进了规范。这个区别很关键：它意味着新标准追认了大量既有实践，而不是发明了一套新规则。你过去为了通过收件方判定所做的配置，绝大部分在新标准下仍然是对的。

值得关注的真正原因是三件事。第一，规范从此有了明确的三份文档边界，将来各部分可以各自演进，你必须知道自己关心的是哪一份。第二，策略发现机制发生了变化，这个变化主要影响接收方，但会改变「你需要在哪里发布记录」的直觉。第三，一些你正在使用的标签被明确废除，不是为了让你立刻改，而是为了让你的配置不再背负历史包袱。

1.2 它不是一次周末紧急重配

对大多数已经在使用认证域名、正确对齐标识的发件人来说，这次更新更像是一次「文档现代化」，而不是「周五之前必须重配 DNS」的紧急事件。

判断自己属于哪一类很简单，回答一个问题：你现在收到的 DMARC 聚合报告里，通过率是否稳定在高位、失败的来源是否都已知且已处置？如果是，那么这次更新对你就没有紧急动作，只需在下一次例行体检时按新标签整理记录。

如果答案是否，那么你要做的事和这次标准更新关系不大——那是本来就该做的对齐与清理工作，新标准只是提供了一个重新审视它们的时机。

把这件事定性为「文档现代化」而不是「紧急重配」，还有一个实际好处：它让你不必在业务压力下仓促收紧策略。仓促收紧的典型后果是事务邮件大面积退信，而这类事故的排查成本远高于按部就班完成的成本。

二、一份变三份：核心、聚合报告、失败报告

2.1 三份文档各管什么

最直观的变化是文档结构：原来一份 RFC 7489 现在拆成了三份。

RFC 9989 负责策略与对齐——也就是「发件人声明什么策略」「接收方怎样判断对齐」「失败时怎么处理」这套核心逻辑。RFC 9990 负责聚合报告——也就是 rua 地址收到的那类汇总数据，用来回答「谁在替我发信、有多少失败」。RFC 9991 负责失败报告——也就是向 ruf 地址投递的、带原始邮件片段的取证信息。

拆分的直接好处是阅读路径变清晰。以前想知道「我该写哪些标签」，得在一份文档里翻过大量关于报表格式的章节；现在你只打开 9989 就够。反过来，如果你要排查「为什么聚合报告里某类失败特别多」，你得知道报表格式的权威描述在 9990 里。

2.2 分开写的好处与代价

好处是各部分可以独立演进。报表格式的调整不必动核心策略语义，核心策略的澄清也不必连带重新定义报表字段。对实现者来说这是实实在在的减负：一次修订的影响面被限制在一份文档里。

代价落在执行侧：你需要在脑子里同时维护三份文档的地图。 遇到一个具体问题时，先判断它属于核心策略、聚合报告还是失败报告，才能找到权威答案。以前只有一个入口，现在有三个，查找成本上升。

对普通发件人，这个代价可以降到很低，方法是只记一条分界线：关于「我该发什么策略」看 9989，关于「我在报表里看到什么」看 9990，关于「某封具体邮件为什么被判失败」看 9991。 绝大多数日常问题落在 9990，因为报表是唯一持续可见的反馈。

三、DNS Tree Walk：改造主要发生在接收方

3.1 沿 DNS 层级向上查找

新标准引入 DNS Tree Walk 作为策略发现方式：接收方可以沿 DNS 层级向上查找策略，而不是依赖静态的公共后缀列表。

要理解这个变化的意义，先看旧机制的问题。接收方要判断一封邮件来自哪个「组织域」，过去靠一份公共后缀列表来切分——比如知道 example.co.uk 是一个完整的公共后缀，那么 a.example.co.uk 的组织域就是 example.co.uk。这份列表需要持续维护，而它的更新永远滞后于真实世界的域名变化：新出现的公共后缀、临时注册的二级结构、历史遗留的多级命名，都会让列表判断失准。

DNS Tree Walk 把判断依据换成了 DNS 本身：接收方从邮件的域名出发逐级向上，找到第一个发布了 DMARC 记录的层级，把它当作组织域。这样判断依据不再是外部维护的静态列表，而是域名所有者自己发布的记录。

这主要影响超大或复杂域名结构，比如部分 .edu、.gov 环境里那种多级域名体系——接收方以前靠公共后缀列表识别「哪个才是组织域」，列表更新不及时就会误判；新机制让接收方沿 DNS 逐级向上找到第一个发布 DMARC 记录的层级。改造主要发生在接收方，需要接收方侧实现变更。

3.2 发件人该怎么做

大多数发件人仍然应该在主动发件的域名上发布明确的 DMARC 记录。

这句话必须强调，因为 Tree Walk 的表述容易被误读成「以后可以不用发记录了，接收方会自己往上找」。事实相反：Tree Walk 找到的正是「第一个发布了记录的层级」，如果一路向上都找不到记录，那么这次查找什么也没找到。你不发布记录，就没有任何可被发现的东西。

所以这个机制对发件人的真实含义是：记录的位置变得更重要了。你发布在哪一级、哪些子域有独立记录、哪些子域靠上级记录兜底，这些选择会直接影响接收方如何认定你的组织域。特别是那些大量使用「不存在子域」的场景——攻击者随手编造的子域，如果上级有记录，它就会被该记录覆盖。

这也解释了为什么新标准新增了专门处理「不存在的子域」的标签（下一章展开）：Tree Walk 让「向上找」变成常规路径之后，「上面那一级说了什么」的权重自然上升。

四、标签的增减与工程含义

4.1 新增 np 与 psd

新标准新增了两个标签。

np 用于描述「不存在的子域」策略。过去的实践中，攻击者常用一个随手编造的子域发信（比如 billing-secure.example.com 这种从未存在过的名字），而收件方对这类域名的处理缺乏明确依据。有了 np，发件人可以显式声明「对于不存在的子域，我要求什么策略」，而不必指望子域策略 sp 去覆盖一个并不存在的名字。

psd 用于标记「公共后缀域」。它面向的是那些本身就是公共后缀、下面挂着大量互不相关组织的域名。这个标签的意义在于让这类域名的策略声明有明确的语义，而不是与普通组织域混在一起解释。

对绝大多数普通发件人来说，np 是有实际价值的（它堵住一个真实存在的冒用面），psd 则基本用不到——除非你运营的正是某种公共后缀结构。按需评估这个词很准确：不是「都加上更安全」。

4.2 废除 pct、rf、ri 意味着什么

被废除的是 pct、rf、ri 这几个过时标签，测试行为改由新的 t 标签描述。

最重要的一条是 pct 的废除，因为它改变了很多人熟悉的操作习惯。过去收紧策略的标准做法是灰度：p=quarantine; pct=25，让策略只对一部分邮件生效，观察一段时间再往上抬百分比，最后到 100。这套做法在旧规范下是主流的渐进路径。

pct 废除之后，这条路径要换思路：策略状态的表达方式变了，用 t 标签更准确地描述「当前处于测试行为」这一状态。也就是说，过去用百分比表达「我还没完全准备好」，现在用明确的测试状态表达同样的意思——从「部分生效」变成「声明自己在测试」，语义更清楚，也不再让人误以为「发出去的策略只对四分之一邮件有效」。

rf 与 ri 的废除同样属于清理性质：它们都是过时标签，接收方在实践中普遍忽略，保留它们只是让记录变脏——这也是后面新旧记录对照里，这两项被直接删掉的原因。

这里必须点出一个关键区别，避免误读：标签被废除，不等于功能失效。 接收方会忽略未知或过时标签——这意味着你不改记录也能继续工作，现有配置不会因为规范更新而突然崩掉。为了整洁，可以主动移除 pct、rf、ri，但这是一次整理，不是一次抢修。

4.3 旧记录到新记录的对照

新旧记录的差别用示例看得最清楚。假设 example.com 过去发布的是：

v=DMARC1; p=quarantine; pct=100; rua=mailto:[email protected]; ruf=mailto:[email protected]; rf=afrf; ri=86400

按新规范整理后：

v=DMARC1; p=quarantine; sp=reject; np=quarantine; rua=mailto:[email protected]; ruf=mailto:[email protected]; t=r

逐处看改了什么、为什么改。删掉了 pct、rf、ri——接收方本来就忽略，留着只是脏。sp=reject 明确子域策略，不再依赖「不写就沿用主域策略」这种隐式行为。新增 np=quarantine，覆盖不存在的子域，堵住编造子域的冒用面。t=r 表示当前处于「按测试模式记录结果」阶段，替代了过去用 pct 表达「我还没完全收紧」的做法。

rua 与 ruf 两个报表地址保持不变——这说明一件事：这次整理动的是表达方式，不是观测能力。 报表该怎么收、收到哪里，逻辑没有变。

用 nslookup -type=TXT _dmarc.example.com 可以随时核对当前记录。核对的意义不只是确认改动生效，更是在半年后还能回答「我们当初为什么这么配」。

新旧标准整体对比如下：

五、没有改变的部分

5.1 对齐仍然是唯一的通过条件

这一节比前面所有变化都重要，因为它是「核心逻辑不变」的具体内容。

DMARC 依然在「可见发件人域名与 SPF 或 DKIM 任一认证标识对齐」时通过，而不是要求两者都对齐。对齐仍分为严格（精确匹配）或宽松（同一组织域，例如 mg.example.com 与 example.com）。

也就是说，判断标准依旧是「SPF 或 DKIM 中对齐」，而不是「SPF、DKIM、DMARC 三者各自独立通过」。这个区别在排障时非常实用：报表里出现「三项都通过、DMARC 仍然失败」，说明的是对齐问题，不是认证问题。方向对了，修复往往只是改一个发信域的配置，而不是重做整套认证。

5.2 域名对齐不等于 IP 信誉，通过也不等于进箱

同时要把域名对齐与 IP 信誉区分开：共享 IP 与专属 IP 影响信誉管理和排障可见性，但不改变 DMARC 对齐的判定方式。

通过 DMARC 只证明域名被授权使用，并不能保证进收件箱——信誉、互动和内容仍然决定邮件最终落在哪里。这条边界在任何一次标准更新里都不会消失，因为 DMARC 回答的是「这封信有没有资格代表这个域名」，而不是「收件人想不想看这封信」。

把这两件事混为一谈，会导致一种很常见的误判：认证配齐了、DMARC 通过了，但邮件仍进垃圾箱，于是怀疑标准或配置有问题。实际上问题在信誉与互动那一侧，和 DMARC 无关。这两层的分工与优化方法见 邮件送达率优化。

六、现在该做的四件事

6.1 核对是否还在依赖 pct 灰度

第一件事：核对 DMARC 记录是否还在依赖 pct 灰度。

具体做法是把每个发信域的当前记录取出来，看有没有 pct、rf、ri。如果有 pct，先回答一个问题：这个百分比是「正在进行的收紧过程」，还是「当年设了就忘了的历史残留」？

如果是前者，你需要把「部分生效」的表达换成测试状态（t 标签）加明确的策略，并按自身的发送流量验证后再收紧——收紧的依据是你的报表，不是规范发布日期。如果是后者，直接移除即可，它没有在起任何作用。

第二件事：检查是否有大量「不存在子域」被利用。

做法是从聚合报告里找出那些来自你从未使用过的子域的发送记录。如果存在，说明有人在用编造的子域冒用你的组织域，这正是 np 要解决的问题。按需评估是否加上 np，并把策略设成与你主策略一致的方向。

6.2 确认报表有人看，并把「对齐」当成目标

第三件事：确认聚合报告仍能收到，并且真的有人看。

这一步最容易被跳过，因为技术上「配了 rua」就等于「有报表」。但报表发到一个无人查看的邮箱，等于没有报表。判断标准很实在：上一次有人根据报表做出处置决定是什么时候？如果答不上来，那这条链路目前是断的。报表的日常查看方式见 送达率监控工具。

第四件事：把「对齐」而不是「通过」当成真正的目标。

这一条是前三条的目的。检查方式是用邮件头分析器确认：DKIM 签名的 d= 是否与发送域名匹配，SPF 是否正确发布在发送子域上，并且这些域是否与可见的 From 域名共享组织域。三项各自通过但不对齐，是最常见的失败形态；把它当成目标，很多看起来莫名其妙的问题会自己消失。

补充一个常被忽略的检查项：如果你在多个平台发信，源清单本身要盘一遍。列出所有已验证的发送域名，以及它们承载的发送流（事务、营销、应用通知），及时清理或收紧不再使用的宽松策略。这里特别要注意冷邮件这类主动外联——它应当跑在独立子域上，避免投诉把主域拖下水，相关做法见 冷启动邮件发送策略。

七、不该做的事与结论

7.1 不要立刻推 reject，不要把废除当失效

第一个不该做的：不要因为规范更新就把 p=reject 立刻推上去。

这仍然是需要按自身发送流量验证的决定。p=reject 的影响是「不合格就拒收」，而你对「哪些流量不合格」的了解程度完全取决于报表跑了多久、覆盖了多少业务周期。报表还没看清就推到拒绝，等于用生产流量做实验，失败的代价是业务邮件丢失。

第二个不该做的：不要把「标签废除」理解为「功能失效」。

接收方忽略未知或过时标签，所以旧记录继续工作没有问题。仓促改动唯一可能带来的效果，是在你还没弄清新语义的时候引入新错误。整理的时机应该由你的例行体检决定，而不是由规范发布日期决定。

顺带清掉一个常见混淆：不要把这次更新与 DKIM2 混为一谈。DKIM2 是另一套关于签名模型与重放防护的独立协议讨论，目前并不是强制要求，今天的 DMARC 判定依然完全依赖 SPF 和 DKIM。

7.2 结论

把全篇压成三句话。

第一，核心逻辑不变：认证你的邮件、保持标识对齐、监控报告、修复不一致的发送流。这四件事在任何一版规范下都是同一件事。

第二，变化集中在表达方式与发现机制：一份变三份让各部分可独立演进，代价是查找时要知道该看哪一份；DNS Tree Walk 把「组织域怎么认定」的依据从静态列表换成 DNS 自身，改造主要发生在接收方，而发件人仍然要在主动发件的域名上发布明确的记录；np、psd 补上了过去缺失的语义，pct、rf、ri 退场，测试状态改由 t 表达。

第三，动作的优先级由你的报表决定，不由规范发布日期决定。先确认报表有人在看，再按报表收紧策略；先确认自己在用哪些标签，再决定删哪些。想先从整体上补一遍认证基础，可以从 SPF/DKIM/DMARC 配置 开始；认证到位之后想让品牌在收件箱里有更强识别度，可参考 BIMI 收件箱 Logo 落地路径；需要横向对比各家平台对新标准的支持节奏，见 邮件服务商对比；退信与失败的具体归因见 邮件退信原因分析。

最后重复一次本文的性质：这是对 Mailgun 官方博客一篇规范解读的再解读，不是 16IDC 的实测结论。文中所有涉及规范条文的表述，均以 IETF 正式发布的 RFC 9989/9990/9991 文本为准；如果你要做与合规或合同相关的判断，请直接阅读正式 RFC 文本。

来源：Mailgun 官方博客《mailgun-dmarcbis-is-dead》，规范条文与标签变更以 IETF 正式发布的 RFC 9989/9990/9991 文本为准。