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: RFC 9989 covers the core DMARC protocol, RFC 9990 covers aggregate reporting, and RFC 9991 covers failure reporting. Splitting them allows each component to evolve independently without dragging the others along.
Here's what changed and what you need to know.
The DNS Tree Walk Replaces the Public Suffix List
The most significant architectural change in RFC 9989 is how organizational domain boundaries are determined.
The original RFC 7489 relied on the Public Suffix List (PSL), a manually maintained file listing which domain suffixes are public registries. To find the organizational domain for mail.example.co.uk, you'd look up co.uk in the PSL, then take one label to the left to get example.co.uk. It works, but it has problems: external dependency, manual maintenance, potential staleness, and no support for domains that want DMARC policies at non-obvious namespace boundaries.
RFC 9989 introduces the DNS Tree Walk as the alternative. Instead of consulting the PSL, 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 denial-of-service 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. Cleaner semantics: the distinction between "policy exists but is being staged" and "policy is active against a subset of traffic" is now unambiguous.
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.
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 (RFC 9990)
The aggregate reporting spec was extracted from RFC 7489 into its own document. The format remains XML with several refinements:
The 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.
A 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 when some receivers have updated and others haven't.
An 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.
You can check your current DMARC record with the DMARC checker at mrdns.com, or use the email health check for a combined SPF and DMARC grade.
Failure Reporting (RFC 9991)
Failure reports (RUF, per-message reports sent when authentication fails) are now in their own document. 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 field was absent from the original spec, leading to inconsistent implementations across reporting providers.
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 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
pcttags from your DMARC records if you're using them. Receiver behavior around deprecated tags will vary as implementations update. - If you're using
pct=0for staged rollouts, move tot=yto signal test mode explicitly. - If you're operating mail infrastructure (MTAs, DMARC reporting tools, monitoring systems), the
Identity-Alignmentrequirement in RFC 9991 and thepsd/treewalk changes in RFC 9989 require implementation updates. - Public Suffix Domain operators should evaluate adding
psd=yonce 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.
If you're still on p=none and haven't worked through your sending sources, now is a good time to start. Sign up for Generator Labs to monitor your domain's authentication posture and catch issues before they affect deliverability.