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. The spec was also split into three separate documents:
— core DMARC protocolRFC 9989 - — aggregate reporting (RUA)RFC 9990 - — failure reporting (RUF)RFC 9991
Splitting them allows each component to evolve independently. Here's what changed.
The DNS Tree Walk Replaces the Public Suffix List #
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 9989 introduces theDNS 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.
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
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.
psd
— Public Suffix Domain
Marks the domain as a Public Suffix Domain for the DNS Tree Walk algorithm.
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.
Aggregate Reporting Changes (RFC 9990) #
The aggregate reporting spec was extracted from RFC 7489 into its own document. The format remains XML with several refinements.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.
Failure Reporting Changes (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, or
none
if all passed. This was absent from the original spec, leading to inconsistent implementations.Rate limiting is now required. RFC 9991 explicitly mandates that report generators implement rate limits. This closes a known gap: failure reports can be triggered by an attacker sending large volumes of spoofed mail, making an unrated reporting system a DoS amplification vector.** dmarc is now a formal ARF authentication failure type.**The
Authentication-Failure
ARF header now includes dmarc
as a valid type value alongside the existing dkim
and spf
types.Privacy guidance is significantly expanded. The document adds detailed guidance on PII redaction, URI validation, and secure transport for failure reports. If you're forwarding RUF reports to a third-party reporting service, the privacy section of RFC 9991 is worth reading before you do.
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.
The practical checklist:
-Remove from your DMARC records. Receiver behavior around deprecated tags will vary as implementations update.pct
tags -If you're using, move topct=0
for staged rolloutst=y
to signal test mode explicitly. -If you're operating mail infrastructure(MTAs, DMARC reporting tools, monitoring systems), theIdentity-Alignment
requirement in RFC 9991 and thepsd
/treewalk changes in RFC 9989 require implementation updates. -Public Suffix Domain operators should evaluate addingpsd=y
once receiver support is established.
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.