Five Changes to DMARC (Domain-based Message Authentication, Reporting, and Conformance) IT Teams Can’t Ignore

For more than a decade, DMARC ran on a single document: RFC 7489, published in 2015 as an Informational RFC. It was never a formal IETF standard, just a widely adopted reference that email providers, mailbox operators, and DNS administrators treated as the de facto rulebook. That changed in May 2026, when the IETF DMARC Working Group published a three-document update, and RFC 9989 replaces RFC 7489 as the authoritative core specification. Two companion documents, RFC 9990 and RFC 9991, now govern aggregate and failure reporting respectively.

None of this breaks existing DMARC records. A policy published under the old rules still evaluates the same way under the new ones, and mailbox providers aren’t going to reject your mail because your record predates the update. But the fact that RFC 9989 replaces RFC 7489 is not a cosmetic footnote. It signals a genuine shift in how organizational domains are discovered, what counts as compliant DMARC deployment, and which tags are worth keeping in your DNS. IT and security teams that manage email authentication should understand what changed and why it matters, even if nothing needs to be touched today.

Why the Update Took Eleven Years

RFC 7489 was published through the IETF’s Independent Submission Stream rather than by a working group, which meant it carried Informational status rather than Standards Track status. In practice, that distinction mattered less to day-to-day operations than it did to the protocol’s formal standing: an Informational RFC is a published reference, but it has never gone through the same interoperability testing and consensus process that a Standards Track document requires.

Getting DMARC onto the Standards Track meant the IETF needed evidence of stable, interoperable deployment across independent implementations, which takes years to accumulate at internet scale. The working group effort, informally called DMARCbis for most of its life, spent roughly seven years resolving ambiguities that had accumulated since 2015, how organizational domains should be determined, how percentage-based rollout should behave, and how public suffix domains like .bank or .gov should participate. The result, published in May 2026, is that RFC 9989 replaces RFC 7489 as a Proposed Standard, with DMARC formally reaching a status it never held during its first eleven years of widespread use.

The Domain Discovery Method Has Changed

The single largest architectural change sits in how receivers determine a domain’s “Organizational Domain” — the level in a DNS hierarchy where DMARC policy is expected to apply if no record exists at the exact sending domain.

Under RFC 7489, receivers answered that question by consulting the Public Suffix List, an externally maintained registry commonly hosted at publicsuffix.org. It worked, but it had known weaknesses: different mail receivers cached different snapshots of the list, there was no defined update cadence, and the entire mechanism depended on a resource the DMARC specification itself never controlled.

This is one of the clearest places where RFC 9989 replaces RFC 7489 with a fundamentally different mechanism. Instead of consulting an outside list, receivers now perform what the spec calls a DNS Tree Walk: starting at the sending domain, a receiver queries for a _dmarc TXT record, then moves up one label at a time, repeating the query at each level until it finds a published record or reaches a cap of eight lookups. The organizational boundary is now determined entirely within DNS itself, with no external dependency.

For most single-domain senders, this changes nothing observable. For organizations running complex subdomain structures, delegated sending domains, or multiple business units under one root domain, it can matter quite a bit. A receiver still running the older Public Suffix List logic and a receiver running the new Tree Walk algorithm may, in some edge cases, land on different organizational domains for the same address, which is why publishing an explicit _dmarc record at every domain and subdomain that actually sends mail is now the safer practice, rather than relying on inheritance from a parent domain.

Tag Changes Worth Auditing Now

Alongside the discovery mechanism, several DMARC record tags were retired or introduced. None of these require an emergency change, but they’re worth reviewing at your next scheduled DNS update:

• pct (percentage) — removed. This tag let domain owners apply a policy to only a portion of mail, as a way to stage a rollout. Receivers implemented it inconsistently, producing unpredictable enforcement. It’s replaced by a binary t (testing) tag, and during the transition period the safest approach is to include both tags together.
• rf (report format) — removed. This tag was rarely implemented by receivers to begin with, so its removal has little practical effect.
• ri (report interval) — removed. Receivers largely ignored requested intervals in practice, sending aggregate reports on their own daily schedule regardless of what the record specified.
• np (non-existent subdomain policy) — added. This lets domain owners set a distinct policy for subdomains that don’t exist in DNS at all, closing a gap that RFC 7489 left ambiguous.
• psd (Public Suffix Domain) — added. Relevant mainly to operators of public suffix domains such as .bank or .gov; ordinary domain owners can generally leave it unset.

If your current records include a size limit appended to a reporting address, such as rua=mailto:reports@example.com!10m, that syntax is also no longer meaningful under the new spec and can be safely dropped.

What “Full Participation” Now Means in Writing

One change that hasn’t gotten as much attention as the Tree Walk is that the new core document spells out, in normative language, what counts as full DMARC participation for both senders and receivers. Previously, RFC 7489 described DMARC’s mechanics but left compliance expectations relatively implicit, which contributed to the patchy, half-implemented deployments that have been a persistent problem in email security for years. The updated spec now states explicit requirements: senders must produce aligned SPF and DKIM identifiers, must maintain a mailbox to receive and actually review aggregate reports, and must not rely on SPF alone to satisfy a p=reject policy. Receivers, in turn, must check for a policy record, perform alignment checks, and support the mailto: reporting URI. For IT teams that have treated DMARC as a “set it and forget it” DNS entry, this formal definition is a useful checklist for auditing an actual deployment against documented expectations, rather than against informal industry convention.

What We’ve Learned

The headline fact is straightforward: RFC 9989 replaces RFC 7489 as the authoritative DMARC specification, and it does so alongside RFC 9990 and RFC 9991 for aggregate and failure reporting. Existing v=DMARC1 records keep working, and nothing about this update forces an immediate rewrite of production policy. But the underlying mechanics have shifted in ways that matter for anyone managing DMARC at scale — the move away from the Public Suffix List toward a DNS-native Tree Walk, the retirement of tags that receivers never implemented consistently, and a normative definition of what full participation actually requires. None of this is urgent in the sense of an outage or a security incident. It is, however, a reasonable prompt to review DNS records at the next planned maintenance window, confirm subdomains that send mail have their own explicit policies, and strip out tags the new specification no longer recognizes. Eleven years is a long time for a security-critical protocol to run on an Informational document, and the transition to a properly ratified standard is worth understanding even where it doesn’t demand action today.