RFC 9989, 9990, 9991: what actually changes in DMARC

RFC 9990 — aggregate reports (RUA)

The aggregate reports are the daily summaries receivers send to the rua= address. RFC 9990 now devotes a whole document to them: XML format, content, frequency, and sending best practices. The content stays familiar — counts per sending source, with SPF/DKIM alignment results — but two details shift in the reports' policy_published block: the pct tag no longer appears, and the np tag may show up. To learn how to read these reports, see how to read aggregate reports.

RFC 9991 — failure reports (RUF)

The failure reports (also called forensic) are the other channel, far rarer. They can contain samples — hence strong privacy constraints, which is why many receivers simply don't send them. RFC 9991 frames this channel separately, precisely so its confidentiality concerns don't bleed into the rest of the protocol. For the practical difference between the two types, see how to read aggregate reports.

The tags: added, removed, kept

This is probably the table most readers came for.

Tags added:

• np — policy for non-existent subdomains (see the np tag).
• psd — public suffix domain marker (for registries).
• t — binary testing mode (t=y), which replaces percentage-based rollout.

Tags removed:

• pct — percentage-based rollout, deemed unreliable, removed in favor of t (see the end of pct).
• ri and rf — the report interval and format move into the reporting documents (9990/9991); they're no longer in the core protocol.

Tags unchanged:

• v (still v=DMARC1), p, sp, adkim, aspf, fo, rua, ruf — same meaning as in 7489.

What it means for the record

Good news, again: nothing urgent. An existing record stays perfectly valid, and it still starts with v=DMARC1. The only worthwhile touch-ups:

• removing pct if it's still there (up-to-date implementations no longer interpret it);
• adding np=reject to cover the phantom subdomains;
• ri/rf need no attention: their removal from the core is transparent on the sender side.

The detailed, step-by-step roadmap is in is migration necessary.

Why the move to "Proposed Standard" matters

Beyond the technical detail, the status change has real reach. A Proposed Standard is a far stronger anchor for auditors and regulators: citing "DMARC per RFC 9989" carries more weight than citing an Informational document. For organizations under frameworks like NIS2 or DORA, where email authentication is an expected control, that's one more compliance argument. We cover it in banks.

What about interoperability during the transition?

A common question: "if the new tags go in, will old receivers break?" No. DMARCbis is built for backward compatibility: a receiver that doesn't yet know np or t simply ignores what it doesn't understand and keeps applying p, sp and alignment as before. So the new tags can be published right now, without waiting for the whole ecosystem to update — there's no downside to being early, and a real upside in closing the non-existent-subdomain gap.

The Tree Walk: an upgrade that arrives without configuration

Among everything RFC 9989 introduces, the DNS Tree Walk deserves a special mention, because it's the rare change that improves accuracy without asking anything of senders. Under RFC 7489, receivers identified the organizational domain by consulting the Public Suffix List — a file maintained outside the standard, originally built for browsers, with all the lag and edge cases an external list implies. DMARCbis replaces that dependency with a walk up the DNS tree itself: the receiver queries successive levels of the domain name until it finds the relevant DMARC record, and the psd tag exists precisely to support this mechanism at registry level. The evaluation happens entirely on the receiver's side — nothing to publish, nothing to change on the sending side — but organizational-domain detection becomes more reliable, especially for domains sitting under unusual or multi-level suffixes.

A record before / after

Nothing beats a concrete example to see what the RFCs change. Here's a typical record as written under RFC 7489:

v=DMARC1; p=reject; sp=reject; pct=100; adkim=s; aspf=s; rua=mailto:reports@example.com

And the same, modernized for DMARCbis:

v=DMARC1; p=reject; sp=reject; np=reject; adkim=s; aspf=s; rua=mailto:reports@example.com

Just two differences: pct=100 is gone (the tag is removed, and pct=100 did nothing anyway), and np=reject appeared to cover non-existent subdomains. Everything else — v=DMARC1, p, sp, strict alignment, the rua — is identical. That's exactly why we call it a revision and not a rewrite: 90% of the record doesn't move.

Who needs which RFC

The three documents don't address the same audience, and knowing which one applies saves 80 pages of reading for nothing:

• Publishing DMARC for a domain? Only RFC 9989 really applies, and even then: just the part on tags. Reporting code is consumed here, never written.
• Receiving and analyzing reports (in-house or through a provider)? RFC 9990 describes what arrives and how to interpret it.
• Building a DMARC solution or operating a mail service? All three RFCs apply, plus the sections on the Tree Walk and interoperability.

For the vast majority of organizations, the real work fits in two lines of DNS (see the example above). The RFCs are the reference; compliance doesn't require reading them, only publishing the right record.

A vocabulary question: does "DMARC V2" really exist?

"DMARC V2" and "DMARC 2.0" turn up everywhere. These are handy nicknames, not official terms: the IETF says "DMARCbis" (the -bis suffix means "the revised version"). And crucially, there is no v=DMARC2 in the syntax — the identifier stays v=DMARC1. So a tool or article urging a "switch to DMARC2" in the record deserves suspicion: it's false, and it betrays a misunderstanding of the standard.

How to check a record is "up to date"

Reading all three RFCs isn't necessary to know whether a record is modern. Three checks are enough:

• v=DMARC1 at the front — always present (otherwise it isn't a valid DMARC record at all).
• No pct — any survivor should come out; recent implementations ignore it.
• np present — without this tag, the non-existent subdomains aren't covered.

An analyzer does these checks in seconds: our free analyzer flags obsolete tags and gaps, domain by domain. A posture can also be placed against a whole sector in the Observatory — which shows, with numbers, how many domains haven't even reached p=reject, let alone adopted the DMARCbis tags.

The RFCs themselves are public and free on the IETF site, for anyone wanting the source of truth. But for nearly every case, the record matters more than the text: it's what receivers see, and it's what protects — or doesn't — the domain. Reading 80 pages of RFC changes nothing as long as the published record isn't current.

For anyone responsible for compliance, there's a practical upside to the three-document structure too. Each concern now has an exact normative reference to cite — RFC 9989 for the policy a domain publishes, RFC 9990 for the aggregate reports relied on as evidence — instead of a single sprawling, Informational document to point auditors at. That precision matters when a control has to be traceable to a named standard, which is increasingly the expectation under frameworks like NIS2 and DORA. In short, DMARCbis doesn't just clean up the protocol; it makes DMARC easier to defend on paper.

In short

DMARCbis isn't a single document but three RFCs: 9989 (the protocol and its tags), 9990 (aggregate reports) and 9991 (failure reports), which together replace RFC 7489. On the sender side, the essentials come down to two moves — add np, remove pct — on a record that still starts with v=DMARC1. The move to Proposed Standard mainly strengthens DMARC's value as an auditable control.

Thomas translates the RFCs into DNS

Reading three RFCs to extract two lines of DNS is a poor use of anyone's time. Thomas, the virtual CISO, knows DMARCbis: he generates the exact record to publish — np and t tags included — from the domain's real state, names every sending source from the reports, and steers the way to p=reject.

Analyze a domain for free or create an account to get started. For a first approach to the topic, this new standard explained simply is the place to begin.