DMARC Is Now a Proper Internet Standard: What Changed in RFC 9989/9990/9991
DMARC Is Now a Proper Internet Standard: What Changed in RFC 9989/9990/9991
DMARC 正式成为互联网标准：RFC 9989/9990/9991 有哪些变化
DMARC has been an Informational RFC since 2015. That changed this month. RFC 9989 replaces RFC 7489 and elevates DMARC to Standards Track, reflecting over a decade of deployment experience and near-universal adoption across the email ecosystem. 自 2015 年以来，DMARC 一直是信息类 RFC（Informational RFC）。本月这一情况发生了变化。RFC 9989 取代了 RFC 7489，将 DMARC 提升为标准跟踪（Standards Track）协议，这反映了过去十多年来在电子邮件生态系统中积累的部署经验和近乎普及的应用现状。
The spec was also split into three separate documents: RFC 9989 — core DMARC protocol RFC 9990 — aggregate reporting (RUA) RFC 9991 — failure reporting (RUF) Splitting them allows each component to evolve independently. Here’s what changed. 该规范也被拆分为三个独立文档： RFC 9989 — DMARC 核心协议 RFC 9990 — 聚合报告 (RUA) RFC 9991 — 失败报告 (RUF) 拆分后，每个组件都可以独立演进。以下是具体变化。
The DNS Tree Walk Replaces the Public Suffix List
DNS 树遍历（Tree Walk）取代公共后缀列表（PSL）
This is the most significant architectural change. RFC 7489 used the Public Suffix List to determine organizational domain boundaries. To find the org domain for mail.example.co.uk, you’d look up co.uk in the PSL, then take one label to the left. It works, but the problems are real: external dependency, manual maintenance, potential staleness, no support for non-obvious namespace boundaries. 这是架构上最重大的变化。RFC 7489 使用“公共后缀列表”（PSL）来确定组织域的边界。要查找 mail.example.co.uk 的组织域，你需要先在 PSL 中查找 co.uk，然后向左取一个标签。这种方法虽然可行，但存在实际问题：外部依赖、人工维护、潜在的滞后性，以及对非显式命名空间边界缺乏支持。
RFC 9989 introduces the DNS Tree Walk as the alternative. The algorithm walks up the DNS tree looking for _dmarc TXT records, starting from the sending domain and moving toward the root. It caps at eight queries to prevent DoS amplification. For most domains this changes nothing operationally. For complex organizations with deep subdomain hierarchies, or operators running public suffix domains that want their own DMARC policies, it’s a meaningful improvement. The new psd tag lets a domain declare itself as a Public Suffix Domain, enabling DMARC policy coverage at that level. RFC 9989 引入了“DNS 树遍历”作为替代方案。该算法从发送域开始，向上遍历 DNS 树查找 _dmarc TXT 记录，直到根域。为防止拒绝服务（DoS）放大攻击，查询次数上限为 8 次。对于大多数域名，这在操作上没有任何改变。但对于拥有深层子域架构的复杂组织，或希望为公共后缀域名设置独立 DMARC 策略的运营商来说，这是一项重大改进。新增的 psd 标签允许域名声明自己为“公共后缀域”（Public Suffix Domain），从而在该级别实现 DMARC 策略覆盖。
New Tags
新增标签
t — Test Mode Replaces the behavioral role of pct. Where pct=0 meant “apply policy to 0% of failing messages,” t=y explicitly signals that the policy is in test mode and shouldn’t be enforced. The distinction between “policy exists but is being staged” and “policy is active against a subset of traffic” is now unambiguous. v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc@example.com t — 测试模式 取代了 pct 的行为角色。过去 pct=0 意味着“对 0% 的失败邮件应用策略”，而 t=y 则明确表示该策略处于测试模式，不应被强制执行。“策略存在但处于分阶段实施中”与“策略对部分流量生效”之间的区别现在变得清晰明确。 v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc@example.com
np — Non-Existent Subdomain Policy Allows separate policy handling for subdomains that have no DNS records at all. Previously, sp applied to all subdomains. Now you can distinguish between legitimate configured subdomains (sp) and mail claiming to originate from subdomains that don’t exist in DNS (np). Non-existent subdomains sending mail are almost always spoofing, so np=reject is often the right default. np — 不存在的子域策略 允许对完全没有 DNS 记录的子域进行单独的策略处理。此前，sp 适用于所有子域。现在，你可以区分合法的已配置子域（sp）和声称来自 DNS 中不存在的子域（np）的邮件。不存在的子域发送的邮件几乎总是欺诈行为，因此 np=reject 通常是正确的默认设置。
psd — Public Suffix Domain Marks the domain as a Public Suffix Domain for the DNS Tree Walk algorithm. psd — 公共后缀域 将该域名标记为 DNS 树遍历算法中的公共后缀域。
Removed Tags
已移除标签
- pct — Gone: Percentage-based partial enforcement has been removed. Use t=y for test mode instead.
- rf — Report Format Removed: Only AFRF format was ever widely implemented. The tag was vestigial.
- ri — Report Interval Removed: Aggregate reports are daily. The tag existed, receivers rarely honored it, and the spec now reflects reality.
- pct — 已移除：基于百分比的部分强制执行已被移除。请改用 t=y 进行测试模式。
- rf — 报告格式已移除：只有 AFRF 格式得到了广泛实现，该标签已成为冗余。
- ri — 报告间隔已移除：聚合报告默认为每日发送。该标签虽存在但接收方很少遵守，新规范现已回归现实。
Aggregate Reporting Changes (RFC 9990)
聚合报告变更 (RFC 9990)
The aggregate reporting spec was extracted from RFC 7489 into its own document. The format remains XML with several refinements: 聚合报告规范已从 RFC 7489 中剥离，成为独立文档。格式仍为 XML，但有几项改进：
- DKIM selector is now mandatory in reports: Previously optional, it’s required for understanding which DKIM key configuration is producing results — which matters for key rotation debugging.
- New discovery method field: Indicates whether the receiver used psl or treewalk to find the organizational domain. Useful for diagnosing alignment issues during the transition period.
- Extension framework: Allows future XML schema additions within defined namespaces without breaking existing parsers. The schema changes are backward-compatible. Well-formed RFC 7489 reports will still parse. If you’re running your own DMARC report parser, the new fields are additive.
- DKIM 选择器在报告中变为必填项：此前为可选，现在必须提供，以便了解是哪种 DKIM 密钥配置产生了结果——这对密钥轮换调试至关重要。
- 新增发现方法字段：指示接收方是使用 psl 还是 treewalk 来查找组织域。这对于在过渡期间诊断对齐问题非常有用。
- 扩展框架：允许在定义的命名空间内添加未来的 XML 模式，而不会破坏现有的解析器。模式更改是向后兼容的。符合 RFC 7489 标准的报告仍可正常解析。如果你运行自己的 DMARC 报告解析器，新字段是附加的。
Failure Reporting Changes (RFC 9991)
失败报告变更 (RFC 9991)
The changes here are more significant for implementors: 对于实现者而言，这里的变化更为重要：
- Identity-Alignment is now a mandatory ARF header: Failure reports must include this field listing which authentication mechanisms failed to produce an aligned pass.
- Rate limiting is now required: RFC 9991 explicitly mandates that report generators implement rate limits to prevent DoS amplification.
- dmarc is now a formal ARF authentication failure type: The Authentication-Failure ARF header now includes dmarc as a valid type value.
- Privacy guidance is significantly expanded: Detailed guidance on PII redaction, URI validation, and secure transport for failure reports.
- 身份对齐（Identity-Alignment）现在是强制性的 ARF 标头：失败报告必须包含此字段，列出哪些身份验证机制未能产生对齐通过结果。
- 现在必须进行速率限制：RFC 9991 明确要求报告生成器实施速率限制，以防止 DoS 放大攻击。
- dmarc 现在是正式的 ARF 身份验证失败类型：Authentication-Failure ARF 标头现在将 dmarc 作为有效的类型值。
- 隐私指南大幅扩展：增加了关于个人身份信息（PII）脱敏、URI 验证以及失败报告安全传输的详细指南。
What You Actually Need to Do
你实际上需要做什么
For most domain owners, nothing changes immediately. RFC 9989 is backward-compatible with RFC 7489 and your existing DMARC record continues to work. 对于大多数域名所有者，短期内无需任何操作。RFC 9989 与 RFC 7489 向后兼容，你现有的 DMARC 记录将继续有效。
The practical checklist:
- Remove pct tags from your DMARC records. If you’re using pct=0 for staged rollouts, move to t=y to signal test mode explicitly.
- If you’re operating mail infrastructure (MTAs, DMARC reporting tools), the Identity-Alignment requirement in RFC 9991 and the psd/treewalk changes in RFC 9989 require implementation updates.
- Public Suffix Domain operators should evaluate adding psd=y once receiver support is established.
实用清单：
- 从你的 DMARC 记录中移除 pct 标签。如果你正在使用 pct=0 进行分阶段部署，请改用 t=y 来明确标记测试模式。
- 如果你在运营邮件基础设施（MTA、DMARC 报告工具），RFC 9991 中的身份对齐要求以及 RFC 9989 中的 psd/treewalk 变更需要进行相应的实现更新。
- 公共后缀域运营商应在接收方支持到位后，评估是否添加 psd=y。
The Standards Track designation matters for enterprise and government procurement environments where “Informational RFC” raised compliance questions. DMARC is now a proper internet standard, not a proposal. “标准跟踪”这一地位对于企业和政府采购环境至关重要，因为此前“信息类 RFC”的身份常引发合规性质疑。DMARC 现在是正式的互联网标准，而不再仅仅是一项提案。