DMARC changed status in May 2026

by Francis Rozange | Sep 8, 2026 | Email Marketing

Abstract 3D render: a glowing glass seal pressing onto a document plate, older fragments drifting away

For eleven years DMARC was an informational document. Published in March 2015 as RFC 7489, it had not even gone through the IETF’s standards process: it arrived through the independent submission stream, with Informational status.

In other words, the mechanism on which Google, Yahoo and Microsoft built their authentication requirements was, formally, nobody’s standard.

That ended in May 2026.

One RFC replaced by three

The work known as DMARCbis has landed. RFC 7489 is obsoleted by three separate documents, all at Proposed Standard, all this time produced by the IETF DMARC working group:

RFC 9989 carries the mechanism itself. It obsoletes RFC 7489 and RFC 9091, the experimental extension for public suffix domains, now folded into the body of the text.

RFC 9990 specifies aggregate reports, the daily XML files you receive at the address declared in the rua tag.

RFC 9991 specifies failure reports, message by message.

The split is not cosmetic. It isolates the part of the system that worked worst.

The part that worked badly, in figures

A paper presented at the ACM CoNEXT conference in December 2024, reviewed by a programme committee, collected more than forty thousand aggregate reports received by a large European university between April 2022 and November 2023.

Result: 94.93 percent of those reports did not follow the syntax defined by RFC 7489, and 92.22 percent did not conform to the XML schema.

Twenty reports out of twenty-one, produced by professional mailbox operators, out of spec.

Earlier work presented at USENIX Security in 2023 had shown the upstream face of the same problem: 49 percent of domains publishing DMARC enable aggregate reporting, and 26 percent of those configurations are malformed, therefore unable to receive the reports they ask for. Among the world’s top ten thousand domains, 10 percent were in that state.

That is the real context in which a company declares “we have DMARC in place”.

What actually changes in your records

The pct tag disappears. It allowed a policy to apply to a percentage of failing messages, typically for a phased rollout. RFC 9989 classifies it as historic and explains why: operational experience showed it was almost never applied correctly, except for the values 0 and 100. A tag named “percentage” that in practice had only two working values had no reason to exist.

A t tag replaces it, with values y and n. It indicates whether the domain owner wants the declared policy actually applied, or is in a testing phase. Two values, explicitly, instead of a hundred of which two worked. The rf and ri tags also move to historic.

The Public Suffix List gives way to a DNS tree walk. This is the deepest change. To find which policy applies to invoice.billing.example.com, the receiver no longer consults an external list maintained by a third party: it walks up the DNS tree, with a cap of eight queries however many levels there are. Two new tags accompany that mechanism, psd to declare a public suffix domain and np to set the policy for non-existent subdomains.

p=none does not disappear, contrary to what is being said. RFC 9989 even makes it an explicit fallback: if the record found contains no valid p tag but does carry a syntactically correct rua, the receiver must behave as though it had read p=none and continue processing.

The discovery order is standardised: author domain, then organizational domain, then public suffix domain. And if the walk finds no record at all, the rule is categorical: the receiver must not apply DMARC to the message.

What it does not change

Alignment remains alignment. The visible From domain must match the domain validated by SPF or by DKIM, and operators accept relaxed alignment: only one of the two is needed.

An SPF that falls into permerror because it exceeds the ten DNS lookup limit does not align. A DKIM signature produced with too short a key or an obsolete algorithm does not align either. DMARC repairs nothing: it observes.

And the forwarding chain remains the weak point. A mailing list that rewrites the subject breaks the DKIM signature; ARC, specified by RFC 8617 in 2019, exists to carry the authentication verdict across those relays, but it has remained at Experimental status.

What to do tomorrow morning

Pull out your current DMARC record and read it, tag by tag. If it contains pct, it rests on a mechanism the standard has just removed.

Then check that the address declared in rua actually receives something. A quarter of measured configurations did not. Send yourself a test report and open it.

Finally, resist the temptation to move to p=reject because a dashboard shows a green light. A reject policy applied while a legitimate flow is not yet aligned, an invoicing tool, a website form, a recruitment platform, deletes that flow without leaving a usable trace. Progress is made with reports that are read, not reports that are requested.

Sources

LaFactory works email on the evidence: headers, DNS records, rejection logs. No open rate promises, ever. Get in touch for a deliverability audit.