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 — 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.

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 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.

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 pct tags from your DMARC records. Receiver behavior around deprecated tags will vary as implementations update.
• 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, monitoring systems), 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.

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.