DMARCbis Has Arrived: What RFC 9989 Means for Your Cold Email Infrastructure

In May 2026, the IETF officially published DMARCbis — the most significant update to the DMARC specification since the original RFC 7489 was released in 2015. The update arrives as three separate Standards-Track documents: RFC 9989 (the core protocol), RFC 9990 (aggregate reporting), and RFC 9991 (failure reporting). Together, they obsolete RFC 7489 and, for the first time, promote DMARC from an Informational document to a formal Internet Standard.

If you're running cold email infrastructure, here's the important headline upfront: there is no DMARC2, and nothing in your current setup breaks. DMARCbis was deliberately designed so that mail servers running the legacy standard can safely ignore the new tags without errors. All DMARC records still start with v=DMARC1. Existing, correctly configured records remain fully functional. You do not need to rush a DNS update.

But there are changes worth understanding — particularly because one widely-used tag has been removed entirely, and the change exposes a structural problem that's been hiding in plain sight for over a decade.

---

What Changed: Tags Removed, Tags Added

Change	Tag	What It Means
Removed	pct=	Percentage-based staged rollout mechanism — gone entirely
Removed	rf=	Failure reporting format tag — folded into RFC 9991
Removed	ri=	Reporting interval tag — removed as rarely implemented correctly
Added	t=	Testing mode flag — binary on/off replacing percentage rollout
Added	np=	Non-existent subdomain policy — closes a subdomain spoofing loophole
Added	psd=	Public Suffix Domain tag — supports registry-level DMARC policies

---

Why Removing pct= Actually Matters

The pct= tag was DMARC's only built-in mechanism for staged enforcement rollout — letting domain owners apply their DMARC policy to only a percentage of mail traffic while testing. It was designed to help teams safely move from monitoring to full enforcement without switching cold overnight.

Here's the uncomfortable data point this removal has surfaced: in a Q1 2026 snapshot of actively monitored domains, 39.9% of domains with a valid DMARC policy remain permanently at p=none — providing zero actual spoofing protection despite running a monitoring setup. Of the domains that do enforce a stricter policy, 93.8% apply it to 100% of traffic with no staged rollout at all. Only 6.2% ever used pct<100 in practice.

In other words: the staged rollout mechanism that was supposed to help domains safely transition from p=none to p=reject was barely used. Most domains either never enforce at all or jump straight to full enforcement. DMARCbis's removal of pct= doesn't create this gap — it just stops pretending the gap was being bridged.

What Replaces It

Under RFC 9989, if your domain currently has a non-default pct= value, you have two options going forward: switch to t=y (testing mode — a binary all-or-nothing signal that the policy is provisional) or commit fully to enforcement and drop the percentage tag entirely. There's no longer a granular middle ground for gradual rollout.

This matters for cold email senders. Since bulk sender requirements now effectively treat p=none as a trust gap, and gradual percentage-based rollout is no longer a sanctioned mechanism, the jump from p=none to p=quarantine needs to be more deliberate and monitored than before.

---

The np= Tag: Closing a Real Spoofing Loophole

The np= (non-existent subdomain policy) tag addresses a specific vulnerability that's been exploitable for years: an attacker could forge an email from a non-existent subdomain — like secure-login.yourdomain.com — potentially bypassing the main domain's DMARC policy, since the subdomain doesn't exist and historically wasn't covered cleanly.

With np= configured, forged email claiming to come from a non-existent subdomain gets explicitly rejected under the new policy. If left unset, np= defaults to whatever your existing sp= (subdomain policy) is set to — so most domains don't need immediate action, but understanding the tag matters for anyone auditing their configuration.

---

What This Means for Cold Email Infrastructure

For teams running cold email infrastructure across multiple secondary sending domains, DMARCbis has three practical implications:

No urgent action required. Your existing v=DMARC1 records with p=none, p=quarantine, or p=reject continue working exactly as before. Google, Yahoo, and Microsoft's bulk sender requirements are unaffected.

Remove deprecated tags at your next DNS edit. If any of your sending domains use pct=, rf=, or ri=, clean these out the next time you touch that domain's DNS records — not urgently, but as routine hygiene.

Reconsider your enforcement strategy. Since gradual percentage-based rollout is no longer sanctioned, plan your transition from p=none to p=reject as a more deliberate, monitored full switch. This is particularly relevant for secondary sending domains used in cold email infrastructure, which often sit at p=none indefinitely.

---

Should You Update Your DMARC Records Right Now?

No rush is required. DMARCbis adoption sits at approximately 0.1% across monitored domains as of June 2026, with only a handful of DMARC reporters globally currently supporting the new aggregate reporting format.

The recommended approach from deliverability experts: wait until major mailbox providers (Google, Yahoo, Microsoft) have implemented and validated the new specification before making strategic record updates.

For cold email senders, the more urgent priority remains unchanged: every sending domain needs a valid SPF record, a 2048-bit DKIM key, and at minimum a p=none DMARC record to meet current bulk sender requirements. DMARCbis is a long-term protocol evolution — not a new compliance deadline. See our SPF, DKIM, and DMARC explainer for the setup guide that applies right now.

---