u/pampurio97

Hi, having followed the IETF work around DMARCbis, I've published a list of changes in the new DMARC RFCs compared to the original spec from 2015.

I've also included some context and excerpts from the working group debate, which shows why some decisions may be surprising:

https://dmarcwise.io/blog/new-dmarc-2026

I'm personally still skeptical that changes like replacing pct with t are worth it, as we'll now have to use both to ensure compatibility with both specs, likely forever.

I also feel there may not be enough practical guidance around the use of the new psd tag, especially psd=n vs psd=u. The definition of the tag tells you to go read the tree walk algorithm, which isn't as straightforward as the PSL (nobody's going to read 40+ paragraphs of text).

What do you think?

After years of work from the IETF working group, the DMARC specification was updated. Three new RFCs are now officially published, replacing the old RFC 7489 from 2015:

• Main document: https://datatracker.ietf.org/doc/html/rfc9989
• Aggregate reporting: https://datatracker.ietf.org/doc/html/rfc9990
• Failure reporting: https://datatracker.ietf.org/doc/html/rfc9991

DMARC is now an IETF Proposed Standard.

The Appendix C of the main document contains a list of changes: https://datatracker.ietf.org/doc/html/rfc9989#name-changes-from-rfc-7489

The main changes are:

• A general restructuring of the specification, that is now easier to read, with better examples, more guidelines and clearer definitions.
• 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.
• 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.
• 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.
• The above changes allow for better support of Public Suffix Domains (PSD), which previously couldn’t fully participate in DMARC.
• The ”indirect email flows” issue, i.e. forwarding and mailing lists breaking DMARC alignment, remains unsolved, with the new specification now discouraging a reject policy when there’s a chance of mailing lists being used as recipients in an organization.
• 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. Similar small updates were made to the failure reporting specification, including a new section acknowledging the privacy implication, but it's otherwise unchanged.