DMARC is now an IETF Proposed Standard: What that means today

In 2015, the IETF published DMARC (RFC 7489) as an Informational RFC, and in the eleven years since then, adoption has been optional to some degree. As an Informational RFC, there was no strict standardization of the protocol beyond efforts by mailbox providers. Even then, there were ambiguities that different vendors resolved differently. While major players like Google, Yahoo, and Microsoft could initiate change within the industry (and establish bulk email sender requirements), the email ecosystem has evolved since the publishing of the original spec. 

That change is swiftly approaching. In May 2026, the IETF published RFC 9989, colloquially known as DMARCbis, which officially moved this long-awaited update to DMARC to Proposed Standard status. This RFC, alongside RFC 9990 (aggregate reporting) and RFC 9991 (failure reporting), brings DMARC one step closer to becoming a well-defined Internet Standard. The updated document formalizes DMARC to match the way email runs today. Together with the upcoming DKIM2 document in draft, they set out to establish a baseline for email authentication in today’s email world.

All three RFCs are on the Standards Track as Proposed Standards. In the IETF process, Proposed Standard is the first and most common step on the Standards Track. It means the spec has gone through community review, reached rough consensus, and is considered stable enough for implementation.

• RFC 9989 is the core DMARC protocol spec. It defines how domain owners publish policy, how receivers evaluate messages against it, and what happens when authentication fails. This RFC would replace RFC 7489 as the authoritative reference for DMARC.
• RFC 9990 covers aggregate reporting. These are the daily XML reports that receivers send back to domain owners, showing which IP addresses sent mail on their behalf and how it performed against SPF, DKIM, and DMARC checks. If you've ever looked at your RUA data, this is the spec that governs what's in it and how it gets delivered.
• RFC 9991 covers failure reporting. Unlike aggregate reports, failure reports are near-real-time and per-message. When a single message fails DMARC authentication, a failure report provides the domain owner with detailed information about that message. They're requested via the ruf tag in your DMARC record and are useful for quickly diagnosing authentication gaps.

While the Proposed Standard designation matters, so do the technical changes across the suite. 

For starters, the pct tag will be no more. This tag allowed senders to apply their DMARC policy to only a percentage of failing mail, which led to inconsistent enforcement across receivers. Now, DMARC should apply to all traffic, full stop. If you've been using pct as a long-term configuration rather than a transition mechanism, it's time to finish the move. The update introduces a new t=y or t=n tag to define a testing mode that effectively replaces the use-case for `pct`. Two other tags that have been removed were the seldom-used rf and ri tags.

Public Suffix Domain (PSD) support is also now formally part of the core spec. The main change here is how public suffixes are identified. Previously, receivers relied on the Public Suffix List, a manually maintained list that public suffix operators had to submit to and then hope every receiver had an up-to-date copy of. PSD replaces that with a DNS Tree Walk, meaning public suffixes are identified directly from DNS, controlled by the public suffix itself, and work everywhere without waiting on list updates.

In addition, the psd=n tag allows designating subdomains as Organizational Domains. This affects alignment and policy inheritance.

On the reporting side, the work is now deliberately split out. RFC 9990 defines the aggregate report format as a standard, including the XML schema, handling of policy changes mid-reporting period, and delivery requirements. RFC 9991 does the same for failure reports: near-real-time, per-message reports that help domain owners quickly identify specific authentication failures. Both documents are now Standards Track, which means receiver implementations have clearer conformance targets than they ever did under the old single-document model.

One practical note on failure reports: RFC 9991 explicitly states that these can include full message headers and body content, which may contain personally identifiable information. 

If your DMARC is correctly configured at enforcement, nothing changes operationally today. RFC 9989 doesn't break existing records and doesn't require republishing anything. But there are a few things worth acting on:

• Audit your use of pct. Receivers may still tolerate the tag during a transition period, but the intent of the new spec is clear.
• Reconsider p=none. The community has formally agreed on what correct DMARC implementation looks like, and senders sitting in monitoring mode indefinitely are increasingly out of step with where the industry is heading.

DMARC becoming a Proposed Standard doesn't transform the threat landscape overnight, but it does signal that we’re one step closer to what looks good across the entire protocol. These RFCs signal a fantastic move in the right direction for email and the internet as a whole. A safer digital ecosystem benefits everyone, and getting to the right level of enforcement early saves you from one massive headache when DMARC finally becomes an Internet Standard.

If you want to know where your domains currently stand, Red Sift Investigate checks your DMARC, SPF, DKIM, BIMI, MTA-STS, and TLS configuration by sending a real email, not