DMARC 新标准落地：RFC 9989/9990/9991 正式发布
2026 年 5 月，IETF 正式发布了取代 RFC 7489 的新版 DMARC 标准：RFC 9989（DMARC 核心）、RFC 9990（聚合报告）、RFC 9991（失败报告）。曾以 "DMARCbis" 草案为名的"下一代 DMARC"，至此成为正式标准。
为什么这件事值得关注
邮箱服务商正在把"通过认证、标识对齐"视为发件人的默认行为底线。新版 DMARC RFC 并没有彻底改变这些预期，但它把许多发件人和邮件服务商已经在执行的实践，以更清晰、更正式的方式写进了规范。
对大多数已经在使用认证域名、正确对齐标识的发件人来说，这次更新更像是一次"文档现代化"，而不是"周五之前必须重配 DNS"的紧急事件。核心逻辑不变：认证你的邮件、保持标识对齐、监控报告、修复不一致的发送流。
新标准改了什么
- 一份变三份：RFC 9989 负责策略与对齐，RFC 9990 负责聚合报告，RFC 9991 负责失败报告。
- DNS Tree Walk 策略发现：接收方可以沿 DNS 层级向上查找策略，而不是依赖静态公共后缀列表。这主要影响超大或复杂域名结构（如部分
.edu、.gov环境），需要在接收方侧改造实现；大多数发件人仍然应该在主动发件的域名上发布明确的 DMARC 记录。 - 标签增减：新增
np（不存在的子域名策略）和psd（公共后缀域名）标签；废除pct、rf、ri等过时标签；用新的t标签更准确地描述测试行为。接收方会忽略未知或过时标签，但为了整洁，可以主动移除pct、rf、ri。
新旧记录的差别用示例看得最清楚。假设 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 表示当前处于"按测试模式记录结果"阶段。用 nslookup -type=TXT _dmarc.example.com 可以随时核对当前记录。
新旧标准整体对比如下：
| 维度 | RFC 7489（旧） | RFC 9989/9990/9991（新） |
|---|---|---|
| 文档结构 | 单一 RFC | 核心 + 聚合报告 + 失败报告三份 |
| 策略发现 | 静态公共后缀列表 | DNS Tree Walk 沿层级向上查找 |
| 测试行为 | pct 百分比抽样 |
t 标签描述测试状态 |
| 子域名策略 | sp |
新增 np 覆盖不存在的子域名 |
| 公共后缀域名 | 无显式声明 | 新增 psd 标记 |
一个真实的影响面
DNS Tree Walk 看起来是纯实现细节，但对大型组织意义不小。假设某机构在 .edu 下是多级域名结构，接收方以前靠公共后缀列表识别"哪个才是组织域"，列表更新不及时就会误判；新机制允许接收方沿 DNS 逐级向上，找到第一个发布 DMARC 记录的层级作为组织域。这解释了为什么新标准主要影响接收方实现——发件人这边要做的，仍然是在真正发信的域名上发布明确的记录，而不是指望 Tree Walk 替自己"兜底"。
没有改变的部分
DMARC 依然在"可见发件人域名与 SPF 或 DKIM 任一认证标识对齐"时通过，而不是要求两者都对齐。对齐仍分为严格（精确匹配）或宽松（同一组织域，如 mg.example.com 与 example.com）。也就是说，判断标准依旧是"SPF 或 DKIM 中对齐"，而不是"SPF、DKIM、DMARC 三者各自独立通过"。
同时要把域名对齐与 IP 信誉区分开：共享 IP 与专属 IP 影响信誉管理和排障可见性，但不改变 DMARC 对齐的判定方式。通过 DMARC 只证明域名被授权使用，并不能保证进收件箱——信誉、互动和内容仍然决定邮件最终落在哪里。
发件人现在应该做什么
- 盘点域名与发送流：列出所有已验证的发送域名，以及它们承载的发送流（事务、营销、应用通知），及时清理或收紧不再使用的宽松策略。
- 核对对齐而非只查"通过"：用邮件头分析器确认 DKIM 签名的
d=与发送域名匹配，SPF 正确发布在发送子域名上，并与可见 From 域名共享组织域。 - 清理 DMARC 记录：移除
pct、rf、ri，按需评估np、psd，并确认子域名策略sp=是否符合预期。 - 把聚合报告当预警系统：
p=none只是主动监控，不是"以后再说"；要及时发现新增发送域、遗留发送流或冒用你域名的第三方发件。
另外，不要把这次更新与 DKIM2 混为一谈——DKIM2 是另一套关于签名模型与重放防护的独立协议讨论，目前并不是强制要求，今天的 DMARC 判定依然完全依赖 SPF 和 DKIM。
参考：RFC 9989 https://datatracker.ietf.org/doc/rfc9989/，RFC 9990 https://datatracker.ietf.org/doc/rfc9990/，RFC 9991 https://datatracker.ietf.org/doc/rfc9991/
16IDC 观察
对使用 邮件送达率优化或接入 邮件服务商的站点来说，这次标准更新提供了一个很好的"体检"时机：趁规则还没收紧，把认证配置对齐到新规范。建议结合 SPF/DKIM/DMARC 配置教程逐项核对，再用 送达率监控工具持续观察变化。更多内容请查看 邮件服务分类。
原文来源：https://www.mailgun.com/blog/deliverability/mailgun-dmarcbis-is-dead/