DMARCbis (RFC 9989) 和原有 DMARC (RFC 7489) 有什么区别？升级后现有配置需要改吗？

2026 年 7 月，IETF 正式发布了 DMARCbis 标准集，包括三个核心 RFC：RFC 9989（DMARCbis 核心规范）、RFC 9990（Sieve 拒绝码扩展）和 RFC 9991（聚合报告格式）。这是自 2015 年 RFC 7489 发布以来 DMARC 标准的最大一次修订。本文全面分析 DMARCbis 与原有 DMARC 之间的关键差异，并回答升级兼容性问题。

一、DMARCbis 的来源与修订背景

RFC 7489（即原 DMARC 标准）发布于 2015 年，是作为"实验性"（Experimental）标准发布的。经过近十年的广泛部署，IETF 成立了专门的 DMARCbis 工作组，于 2026 年将其升级为"提议标准"（Proposed Standard）并发布了三个新 RFC。

修订的主要驱动因素包括：DNS 查询效率问题、大规模部署中发现的 pct= 标签歧义、报告格式的标准化需求、以及与其他协议（如 ARC、BIMI）的交互澄清。

二、核心差异对比

1. 标准状态升级

• RFC 7489：Experimental（实验性）标准
• RFC 9989（DMARCbis）：Proposed Standard（提议标准），标准级别正式提升

这意味着 DMARCbis 获得更高的标准化地位，对业界合规性指引具有更强的影响力。

2. DNS 查询优化 — dpub-domain 机制

DMARCbis 引入了一个全新的 DNS 标签概念：dpub-domain（DMARC Public Domain，即公开域）。对于大型邮件服务商（如 Gmail、Outlook、腾讯邮箱），其出站 IP 可能分属数十甚至上百个域名。RFC 9989 允许通过 _dmarc.dpub-domain 查找父级 DMARC 策略，大幅减少 DNS 查询次数。

原有 DMARC 要求每次收到邮件都要查询 _dmarc.<domain>，费时费力；DMARCbis 的 dpub-domain 允许接收方先尝试短路径。

3. pct= 标签行为重构

原有的 pct= 标签含义为"采样处理百分比"，但在实际部署中歧义非常严重。DMARCbis 将 pct= 的语义修改为"策略应用的采样率"——即对验证失败的邮件，按 pct% 的概率应用 p=quarantine 或 p=reject 策略，其余按 p=none 处理。同时，pct= 不再影响报告生成，所有邮件（无论 pct 如何）都会产生 DMARC 报告。

4. 新增 sps= 标签（单子域策略）

原有 DMARC 仅支持 sp=（子域策略），应用于所有子域。DMARCbis 新增 sps=（Single Subdomain Policy），允许为特定单个子域指定不同于其他子域的策略。语法示例：

example.com. TXT "v=DMARC1; p=reject; sps=newsletter.example.com:quarantine; sp=reject"

上述记录表示：example.com 策略为 reject，sp=reject 禁止所有子域直接发信，但 newsletter.example.com 例外，使用 quarantine。

5. 报告格式升级

RFC 7489 仅对聚合报告（RUA）给出了非正式的 XML Schema；DMARCbis 的 RFC 9991 将其形式化为正式的 XML 格式，并新增了多项字段（详见 FAQ-04）。

6. ARC 交互澄清

原标准对邮件转发场景中 DMARC 与 ARC（Authenticated Received Chain, RFC 8617）的交互没有明确定义。DMARCbis 明确规定了接收方在处理 ARC-Sealed 邮件时的 DMARC 评估顺序和策略选择规则。

三、升级兼容性：现有配置需要改吗？

直接回答：不需要修改现有 DNS 记录。DMARCbis 被设计为完全向后兼容。RFC 7489 语法的 DNS TXT 记录在 DMARCbis 接收方上同样生效。具体来说：

• v=DMARC1; p=none; pct=100 —— 完全兼容，行为一致
• v=DMARC1; p=quarantine; sp=reject —— 完全兼容
• 所有 RFC 7489 的必填标签（v=、p=）用法不变

建议做以下检查：

1. 检查 pct= 使用是否符合你的真实意图（新语义下 pct 是策略应用采样而非报告采样）
2. 如果你的域名由大型 ESP 代发且使用了复杂子域结构，考虑使用 sps= 或 dpub-domain 优化
3. 确认 RUA 接收地址支持 RFC 9991 格式，或确认你的报告解析器能处理新格式
4. 检查邮件转发链是否配置了 ARC，因为 DMARCbis 对 ARC 的交互更严格

四、升级路线建议

• 短期（1-3 个月）：维持现有配置不变；确认你的 DMARC 报告分析工具支持 RFC 9991 格式
• 中期（3-6 个月）：评估 dpub-domain 和多子域策略需求，按需调整 DNS 记录
• 长期：考虑过渡到完整 DMARCbis 配置，应用新特性优化 DNS 查询