DMARCbis Adoption Has Started

After tracking DMARCbis adoption for two years we finally has a pulse. On July 7, 2026, small Danish website eccentric.dk sent us the first DMARCbis report since the standard was published. Within two weeks, a dozen more reporters followed. Thirteen new DMARCbis reporters in the first month.

In May 2026 the IETF published RFC 9989, together with RFC 9990 for aggregate reporting and RFC 9991 for failure reporting, and DMARC became a Proposed Standard (the update people calls DMARCbis).

The growth has started, but look at the other side of the ledger before you touch DNS. All of it is long tail: 16 DMARCbis reporters out of the 4,475 we track (0.4%). So keep running your rollout as if original DMARC governs the inbox. Because for now, it does.

What happened

DMARC is now on the Standards Track as a Proposed Standard, and it obsoletes both RFC 7489 and the experimental Public Suffix Domain extension, RFC 9091.

The DMARC working group spent more than seven years on DMARCbis, grinding through interoperability problems, indirect mail flows, and tag cleanup before it finally landed as three separate RFCs. The core protocol, aggregate reporting, and failure reporting can now evolve on their own, without reopening the whole specification each time.

There is no v=DMARC2

The most common question first: what happens to the version tag? Nothing. The version stays v=DMARC1.

RFC 9989 defines the v tag as REQUIRED, case sensitive, and states that the only possible value is DMARC1. Anything else, and the entire record must be ignored. So while people casually call the update DMARC2, there is no v=DMARC2 in DNS. Every record you publish MUST start with v=DMARC1.

This decision is what makes the transition safe. New tags are additive, and a receiver that does not understand a tag ignores the tag, not the record.

The pct tag is gone

The biggest change for anyone mid-rollout: pct is gone. Under RFC 7489 you could publish pct=25 with p=reject and ask receivers to reject only a quarter of failing mail. RFC 9989 removes the tag entirely.

The working group explains why: "operational experience showed that the 'pct' tag was usually not accurately applied, unless the value specified was either 0 or 100 (the default), and the inaccuracies with other values varied widely from one implementation to another." In other words, receivers didn't implement it consistently, so the spec stopped pretending they did. In its place comes the t tag.

Not everyone was happy with the swap. Gmail's Wei Chuang objected: "We question the benefit versus the implementation effort and confusion of deprecating the DMARC policy 'pct' percentage mode and replacing it with 't' test." Keep that objection in mind, it tells us something about how fast receivers will move.

The new t testing flag

The t tag is binary. The default, t=n, applies your stated policy as written. Setting t=y puts the record in testing mode and asks receivers to apply the policy one level below what you published: reject becomes quarantine, quarantine becomes none, and none stays none. Reports are not affected and keep full visibility during testing phase.

This covers the old pct=0 use case, but it is a single step down, not a percentage. No 5 percent, no 25 percent, no gradient at all. That gap is exactly why rollout mechanics still matter, more on that below.

The Public Suffix List is replaced by the Tree Walk

Original DMARC decided the Organizational Domain by consulting the Public Suffix List, a community maintained file run by Mozilla. DMARCbis replaces that external dependency with a DNS Tree Walk. The receiver starts at the Author Domain and walks up the DNS tree one label at a time, querying for a DMARC record at each level. To stop abuse, the walk is capped at 8 DNS queries. A domain with 8 or more labels gets its leftmost labels stripped until 7 remain before the walk continues. Test in practice how the algorithms work with DmarcDkim.com's DMARCbis checker.

New np tag for subdomains that do not exist

np sets a policy for nonexistent subdomains of the Organizational Domain. Same syntax as p, so it accepts none, quarantine, or reject. If np is absent, receivers should fall back to sp, then to p. This closes a gap when attackers were forging mail from subdomains that were never created at all, names that return NXDOMAIN, and original DMARC had no dedicated answer for them.

The psd tag

psd flags whether a domain is a Public Suffix Domain. The default u lets the Tree Walk decide. Registry and sector operators set psd=y to publish policy across the names beneath them, and a domain that wants to declare itself an Organizational Domain boundary can set psd=n. If you are an ordinary sender, leave it out.

Tags removed for cleanup

Two more tags are gone. rf, the report format tag, is removed because only one format was ever used. ri, the report interval, is removed because receivers ignored it and sent reports on their own cadence anyway.

The Inbox Has Not Moved Yet

Now the part that should shape what to do actually. A published standard is not deployed behavior. Almost all of receivers that decide whether your mail lands, quarantines, or bounces still evaluate it under original DMARC semantics.

DmarcDkim.com's live DMARCbis adoption tracking puts numbers on this daily. As of July 23, 2026, DMARCbis adoption among reporting providers sits at 0.4 percent: 16 DMARCbis reporters out of the 4,475 DMARC reporters we observe globally. That tiny number needs unpacking because it flatters the trend.

Three of the 16 are GMX, WEB.DE, and mail.com are brands of one company, United Internet AG. They emit DMARCbis style reports at a 100 percent rate, but they have been doing it since July 27, 2024, nearly two years before RFC 9989 was published. They adopted the working group draft, and credit to them for the head start.

The actual post-publication story starts on July 7, 2026, when eccentric.dk, a small Danish domain, became the first reporter to send us DMARCbis reports after the standard was published. Someone had to be first, and it was not a tech giant, shoutout to eccentric.dk. In the two weeks that followed, a dozen more reporters showed up, mostly small European domains, our own DmarcDkim.com reporting among them. That is the entire post-RFC wave so far: thirteen reporters, all arriving within a single month, all from the long tail.

Meanwhile Google, Yahoo, Microsoft Enterprise Outlook, Mimecast, Proofpoint and other providers that route most of the world's mail are reporting, and validate, under original DMARC. The mailbox providers you most need to satisfy are still on RFC 7489 behavior, which means:

• a receiver on original DMARC reads your pct value and honors it

• a receiver on original DMARC has no idea what t=y means and ignores it

Strip out pct today because the standard says it is gone, and you lose your only throttle on the majority of receivers that still respect it.

The DmarcDkim.com Recommended Rollout

The safe play during the transition is to speak both dialects in one record. Keep pct so original DMARC receivers ramp enforcement gradually, and add t=y so DMARCbis receivers apply a one-step downgrade instead of full enforcement while you watch reports.

Move through the stages below and only advance when your aggregate reports contains consistent DMARC pass rate over weeks. Use DMARC Analytics Dashboard for safe DMARC rollout with automatic milestones.

Stage 1: Monitor

Start in pure monitoring. Old and new receivers only observe and report; no mail is affected.

v=DMARC1; p=none; rua=mailto:your-domain.com@rua.dmarcdkim.io

Hold at each step long enough to catch monthly senders: newsletters, invoices, payroll notices, any system that only fires on certain days.

Stage 2: Begin enforcement at 5 percent

Set the target policy to reject, throttle old receivers to 5 percent with pct, and add t=y so new receivers treat the record as a quarantine test rather than an immediate reject.

v=DMARC1; p=reject; pct=5; t=y; rua=mailto:your-domain.com@rua.dmarcdkim.io

Old receivers reject only 5 percent of failing mail. New receivers ignore pct but downgrade reject to quarantine because of t=y. Watch reports for a full business cycle.

Stage 3: Raise to 15 percent

v=DMARC1; p=reject; pct=15; t=y; rua=mailto:your-domain.com@rua.dmarcdkim.io

Stage 4: Raise to 50 percent

v=DMARC1; p=reject; pct=50; t=y; rua=mailto:your-domain.com@rua.dmarcdkim.io

Stage 5: Full enforcement

When reports stay boring at 50 percent, commit. Drop pct, drop t=y so the default t=n applies, and add subdomain protection. This is the record that matches the DMARCbis world.

v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:your-domain.com@rua.dmarcdkim.io

From here your policy is enforced everywhere. Old receivers reject all failing mail. New receivers do the same, and also honor np for subdomains that do not exist.

What To Do Right Now

No emergency DNS change is needed. Existing v=DMARC1 records stay valid, but it is a good moment for an audit.

• Already at p=reject with no pct? You are in good shape. Add np=reject for extra subdomain coverage.

• Mid rollout with a pct value? Keep it, and layer in t=y so both generations of receiver understand your intent.

• Still carrying rf or ri? Drop them. They do nothing.

• Leave psd out unless you actually operate a public suffix domain.

• Keep reading your aggregate reports. Nothing about DMARCbis changes the fact that reports drive a safe rollout.

Final note

Adoption is finally moving. Thirteen new reporters in the first month after RFC 9989 is not a revolution, but it is the first real movement since United Internet adopted the draft back in 2024, and we watch the curve daily. It is still all long tail. The providers that matter most validate under original DMARC, and they will for a while yet. So the smart record speaks to both generations: a pct ramp for today's receivers, t=y for tomorrow's. The standard itself is a decade of cleanup, the PSL dependency gone.

DmarcDkim.com tracks DMARCbis adoption across providers every day and generates records that stay correct under both original DMARC and DMARCbis. Run a free DMARCbis check, watch your reports, and move from monitoring to full enforcement without losing legitimate mail with DmarcDkim.com.