DMARCbis Explained: What Actually Changes in the New DMARC Standard

DMARC turned eleven years old still carrying the "Experimental" label RFC 7489 gave it in 2015. That was always a little strange for a standard that, by 2026, sat behind the inbox filtering decisions of essentially every major mail provider on earth. In May 2026, the IETF closed that gap: RFC 7489 is obsolete, and DMARC is now defined by three companion documents, RFC 9989, 9990, and 9991, collectively nicknamed DMARCbis. Between them, they promote DMARC to a full Internet Standard and clean up a handful of ambiguities the original spec left unresolved for over a decade.

If you already have a working DMARC record, the short version is: nothing breaks, nothing needs to change today, and you have years of runway before that stops being true. The longer version is worth knowing, because two of the changes are worth adopting deliberately rather than waiting for a deprecation deadline to force the issue.

Why DMARC needed a "bis"

RFC 7489 was published as Informational rather than Standards Track, which is unusual for something this load-bearing. It meant DMARC's own defining document couldn't be cited as authoritative IETF consensus, just as a description of what a group of large mailbox providers had already agreed to do. Eleven years of real-world deployment surfaced places where that description was incomplete: tags that receivers implemented inconsistently because the spec's wording allowed more than one reading, and gaps the spec never addressed at all, like what a receiver should do with a subdomain that doesn't exist in DNS.

DMARCbis is the IETF DMARC working group's attempt to close those gaps using running code as evidence, then advance the result to full Standards Track. That process is also why it split into three documents instead of one: the core policy mechanism, aggregate reporting, and organizational-domain determination for public suffix domains all had their own separate sets of ambiguities to resolve, and separating them let each move through review independently.

What actually changes

pct= is deprecated in favor of t=. The original spec never fully resolved whether pct applied to a domain's entire outbound mail stream or only to the messages that failed authentication, and different receivers picked different interpretations. DMARCbis drops the percentage rollout model entirely and replaces it with a binary testing flag:

_dmarc.example.com.  TXT  "v=DMARC1; p=reject; t=y; rua=mailto:[email protected]"

t=y marks the policy as being in a testing state. Receivers are expected to treat a testing-flagged policy less strictly in practice while still generating full reports, without the domain owner having to guess what fraction of traffic a given pct value actually covered. t=n (or omitting the tag) means the policy is live. It's a coarser lever than pct was, but a coarser lever that means the same thing to every receiver is a better trade than a precise one that means three different things depending on who's reading it.

np= closes the non-existent subdomain gap. Before DMARCbis, a domain's p= policy applied to subdomains via sp= (or p= itself, if sp= wasn't set) whether or not that subdomain existed in DNS at all. That's exactly backwards from a security standpoint: a subdomain that doesn't exist has no legitimate reason to send mail from anywhere, so it's the case that most deserves a strict default, and instead it inherited whatever policy the domain happened to have picked for subdomains that do send mail.

_dmarc.example.com.  TXT  "v=DMARC1; p=quarantine; sp=quarantine; np=reject; rua=mailto:[email protected]"

np= lets you set reject for nonexistent subdomains specifically, independent of whatever sp= says for subdomains that are actually in use. Most domains have far more unused subdomain names than active ones, and every one of them is a potential spoofing source until np= closes it off.

Aggregate reporting gets a clearer format contract. One of the persistent annoyances in DMARC reporting has been that the spec called for GZIP-compressed XML, and receivers didn't reliably follow it, some send .zip instead of .xml.gz, and any parser has had to handle both since day one. RFC 9990 tightens the reporting document to remove that kind of ambiguity going forward and formalizes fields that were previously handled inconsistently, like how policy overrides get reported. It doesn't retroactively fix reports already sitting in your inbox, but new reports from updated senders should be more uniform.

Public suffix domains get an explicit story. RFC 9991 addresses a case the original spec left fuzzy: how DMARC applies to public suffix domains themselves, entities like github.io or .co.uk, that host many independent third-level domains rather than being a single organization's mail domain. This mostly matters if you operate a domain registry, a SaaS platform issuing subdomains to customers, or anything else sitting at a public suffix boundary. If you're a normal domain owner, this part of DMARCbis largely doesn't touch you.

What doesn't change

p=, sp=, rua=, ruf=, adkim=, aspf=, and the alignment model all carry forward unmodified. The _dmarc. subdomain location, the requirement to pass SPF or DKIM plus alignment, and the none → quarantine → reject rollout philosophy are all untouched. If you've already got a working DMARC record, as covered in DMARC Explained, essentially all of that reference material is still current.

The transition timeline

DMARCbis is explicitly designed for a long, soft transition. pct still works, and will for years, since senders and receivers alike need time to update software before anyone can safely assume t= support is universal. RFC 9989 doesn't set a hard sunset date for pct; it's a deprecation in the sense that new deployments should prefer t=, not in the sense that existing pct= records stop functioning on a fixed date. The same applies to np=: not adopting it doesn't break anything, it just leaves nonexistent subdomains inheriting whatever policy your existing sp= (or p=) already specifies.

What to actually do about it

For most domains, two changes are worth making at the next opportunity, not urgently:

1. Add np=reject if you haven't already, alongside whatever p= and sp= you're running. This is close to a strict improvement with minimal downside: nonexistent subdomains have no legitimate mail to protect against false positives.
2. If you're mid-rollout using pct to ramp up enforcement gradually, finish that rollout as planned. There's no reason to switch to t=y/t=n partway through; adopt the new tag on your next new deployment instead of retrofitting an in-progress one.

Everything else, the record format, the reporting addresses, the alignment tags, needs no action at all.

dig TXT _dmarc.example.com

MyDMARC's DMARC checker has been updated to recognize t= and np= alongside the existing tag set, and flags a record still relying on pct= with a note rather than an error, since it's still valid, just on its way toward being the less-preferred option.

How this connects to the rest of email authentication

DMARCbis changes the policy layer only. It still depends entirely on SPF and DKIM being configured correctly underneath it; nothing here changes how either of those work. If you're setting up DMARC for the first time, DMARC Explained covers the full anatomy of a record, and Your Domain Has No SPF Record and DKIM Records Explained cover the two records DMARC alignment actually checks against.

How DNS monitoring fits in

A DMARC record migrating from pct= to t=, or gaining an np= tag, is a deliberate, low-risk change. A DMARC record silently losing its policy entirely, or reverting from reject back to none during a provider migration, is not. OneDollarDNS monitors your _dmarc TXT record for any change, whether it's an intentional DMARCbis upgrade or an unintentional regression, and alerts you either way instead of leaving you to notice only when spoofed mail starts arriving.