What changed in DMARCbis (RFC 9989)

The short version

In May 2026 the IETF published DMARC as a proper Proposed Standard, split across three documents - RFC 9989 (the core protocol), RFC 9990 (aggregate reports), and RFC 9991(failure reports) - replacing the original RFC 7489 from 2015. The working name for this update was "DMARCbis."

The good news first: the version tag is still v=DMARC1, and existing records keep working. There is no "DMARC2," nothing breaks overnight, and there is no new mandate or deadline. This is a standards cleanup plus a couple of genuinely useful new controls, not a fire drill. Mailbox providers will adopt the new behavior on their own schedules.

The one change worth acting on: np

The most useful addition is the np tag: a policy for subdomains that don't exist. Attackers love non-existent subdomains - they can spoof billing.acme.com or login.acme.comeven if you never created those names. Before DMARCbis there was no clean way to say "reject mail from any subdomain I never set up."

Now there is. Add np=reject and receivers reject mail from any non-existent subdomain:

v=DMARC1; p=none; np=reject; rua=mailto:dmarc@acme.com

What makes this a near-free win: no legitimate mail comes from a subdomain you never created, so np=reject is safe to publish immediately - even while your main policy is still at p=noneand you're still watching reports. It closes a real spoofing hole with essentially zero risk to your real mail.

One caveat that almost nobody mentions: if you publish a wildcard DNS record (*.acme.com), then every subdomain technically "exists," so the non-existent case never triggers and np does nothing. If you rely on wildcards,npwon't help until you remove them.

np vs sp - they are not the same

People mix these up constantly. They cover different subdomains:

• sp - the policy for subdomains that existbut don't publish their own DMARC record (e.g. marketing.acme.com, which sends real mail).
• np - the policy for subdomains that don't exist at all (no DNS records). This is the pure-spoofing case.

A receiver picks in this order: a non-existent subdomain uses np; an existing one with no record of its own uses sp; if neither is set, both fall back to your main p. So np=rejectdoesn't weaken anything - it just lets you lock down the spoofing case earlier and harder than the rest.

pct is gone - use test mode (t=y) instead

DMARCbis removed the pct tag. The old idea - "apply the policy to only 50% of failing mail" - never worked reliably (most receivers only ever honored 0% or 100%), so it was dropped.

Two things to know:

• If your record still has pct, it's no longer doing what you think. A modern receiver ignores it and treats any pct below 100 as full enforcement. So a record at p=reject; pct=10 that you thought was a gentle 10% rollout is now rejecting everything that fails. Drop the tag.
• To stage a rollout, use the new t (test mode) tag. t=ymeans "I've published this policy, but receivers should monitor only and not act yet." It's a clean on/off switch instead of a percentage. Turn it off when your real senders pass.

v=DMARC1; p=reject; t=y; np=reject; rua=mailto:dmarc@acme.com

That record is published at reject, but still in test mode - nothing is enforced yet, so you can watch reports safely before flipping t=y off.

The DNS tree walk replaces the Public Suffix List

Behind the scenes, receivers used to consult a big externally-maintained file (the Public Suffix List) to figure out your organizational domain. DMARCbis replaces that with a DNS tree walk: the receiver simply walks up the DNS hierarchy looking for _dmarc records, bounded to a handful of lookups. This is a receiver-side change - for almost every domain owner it changes nothing you need to do. It mainly improves accuracy for unusual domain structures and for registries.

psd, and the tags that were removed

The new psdtag (public-suffix domain) flags a domain as a registry-style public suffix for the tree walk. Normal domains leave it unset - it's for registries and platforms that hand out subdomains. DMARCbis also removed two rarely-used tags, rf (report format) and ri(report interval); if your record has them, they're harmless but vestigial and can be dropped.

So what should you actually do?

Honestly, not much - and there's no rush. The big mailbox providers (Gmail, Microsoft, Yahoo) haven't finished rolling out the new behavior, and there's no deadline attached. Two changes are worth making now because they're safe and useful:

1. Add np=reject (unless you use wildcard DNS) - a real anti-spoofing win at no cost to legitimate mail.
2. Drop pct if you have it, and switch to t=y if you want to stage a policy before enforcing.

Everything else - the tree walk, psd, the report-format cleanups - is handled by receivers automatically. Your v=DMARC1 record is still valid either way.

Check your record

Our free DMARC checkernow reads your record's DMARCbis readiness - it flags a leftover pct, spots a t=ytest-mode record that isn't actually enforcing, and tells you whether np=reject is worth adding. The DMARC record generator builds a current, DMARCbis-correct record with np and test mode built in.