DMARC is now an IETF Proposed Standard: what's new in RFCs 9989–9991
← Blog Last updated<br>May 20, 2026<br>DMARC is now an IETF Proposed Standard: what's new in RFCs 9989–9991<br>Matteo<br>18 min. read<br>The DMARC protocol (Domain-based Message Authentication, Reporting, and Conformance) was updated in May 2026 and is now an IETF Proposed Standard . It is published as RFC 9989 , RFC 9990 , RFC 9991 , replacing the Informational RFC 7489 from 2015.<br>While the new DMARC isn’t a revolution , it contains some important changes. This article aims to be a comprehensive list of the most relevant changes in the new RFCs.<br>Introduction<br>DMARC is an email security protocol that helps protect your domain from being impersonated by scammers and phishers, an attack known as spoofing .<br>DMARC builds upon two other foundational protocols of email, SPF and DKIM . It’s a common misconception that SPF and DKIM alone are enough to protect from spoofing, but in practice that’s not the case.<br>The protocol mainly does three things:<br>It provides an algorithm to verify alignment of authentication mechanisms , such as SPF and DKIM. Checking alignment means making sure that the sender of an email matches what’s declared by SPF and DKIM.<br>It defines a DNS record format that lets domain owners specify how their emails should be handled when alignment fails, and tune other parameters.<br>It defines a reporting mechanism that lets domain owners gain visibility into their email flows, investigate authentication and alignment failures, and adjust their SPF, DKIM and DMARC settings accordingly.<br>In the past few years, the DMARC Working Group led by the IETF (the Internet Engineering Task Force) worked on a new updated specification with the aim of addressing some of the limitations of the original protocol. In the process, lessons learned during the first decade of DMARC deployment were also incorporated.<br>The new specification was internally referred to as DMARCbis and is now officially published as a Proposed Standard , as of 20 May 2026. For comparison, the original DMARC specification, first published in 2015 as RFC 7489, had Informational status and was an independent submission not led by an Internet standards organization like the IETF.<br>The new DMARC took many years to finalize (roughly from 2018 to 2025), and a general consensus was finally achieved on all matters. The result is three new documents:<br>RFC 9989 : main document.<br>RFC 9990 : aggregate reporting.<br>RFC 9991 : failure reporting.<br>What’s changing<br>Broadly speaking, these are the changes in the new RFCs compared to RFC 7489:<br>A general restructuring of the specification, that is now easier to read, with better examples, more guidelines and clearer definitions.<br>A new section specifies the “conformance requirements for full DMARC participation” , helping domain owners and email receivers determine if they’re following the best practices around DMARC.<br>In the DMARC policy record, some tags were removed (pct, rf, ri) and some were added (np, psd, t). Note that this is not considered a breaking change so there is no such thing as DMARC2 : DMARC records will continue to start with the v=DMARC1 string.<br>In the context of determining the Organizational Domain, both for DMARC record discovery and identifier alignment, the Public Suffix List mechanism has been replaced with the more flexible (and complex) DNS Tree Walk algorithm .<br>The above changes allow for better support of Public Suffix Domains (PSD), which previously couldn’t fully participate in DMARC.<br>The ”indirect email flows ” issue, i.e. forwarding and mailing lists breaking DMARC alignment, remains unsolved, with RFC 9989 now discouraging a reject policy when there’s a chance of mailing lists being used as recipients in an organization.<br>Aggregate reporting has been made stricter and the XML report format has been updated to incorporate the new record tags and acknowledge real-world practices.<br>Similar small changes were made to failure reporting , including a new section acknowledging the privacy implication.<br>Let’s go through the changes in detail.<br>General restructuring and improved definitions<br>The updated DMARC specification is based on the original RFC 7489 but has been restructured and is now easier to read, with improved examples and more practical guidance.<br>As mentioned, it’s now split into three different documents, published as three different RFCs. These are the main document, the aggregate reporting specification, and the failure reporting specification.<br>Several definitions have been updated or added. For example:<br>The DMARC policy is now formally called Domain Owner Assessment Policy .<br>When the DMARC policy is none, the state is called Monitoring Mode , while in other cases it’s called Enforcement .<br>The “report receiver” is now called Report Consumer .<br>Requirements for full DMARC participation<br>A new section makes it clear what it means to fully participate in DMARC .<br>In particular, domain owners :<br>Must send SPF-aligned and DKIM-aligned email...