What DMARCbis Changes, and What It Leaves Unsolved

DMARCbis, the updated version of the DMARC standard, is almost official. It is expected to publish in 2026 and will replace the current RFC 7489 specification. If you operate a domain that sends email, here is what the new standard actually means for you, in plain language.

DMARC is the system that tells inbox providers whether mail claiming to come from your domain is really from you. If you send invoices, newsletters, password resets, or anything else from your own domain, DMARC is what stops a scammer from impersonating you. Most of what DMARCbis changes is quiet plumbing. One change is not quiet, however, and it matters to anyone who runs a domain.

The Short Version

Here is the whole update in five points.

• Your existing DMARC record keeps working. You do not need to change it. The tag that identifies a DMARC record (v=DMARC1) stays the same.
• The gradual-rollout feature is being removed. DMARC had a built-in "dimmer switch" that was supposed to let you turn up protection slowly - apply the rules to, say, only 10% of suspicious mail at first, then work up to 100%. The dimmer never actually worked. DMARCbis takes it out.
• Some internal plumbing is being replaced. Inbox providers used to rely on an external list to figure out where your organization's domain ends. Now they will ask DNS directly. Most domain owners will not notice.
• New official guidance for domains with mailing lists. If people on your domain post to email lists (open-source project lists, industry forums, association newsletters), do not crank DMARC all the way up - it will break the lists.
• A handful of rarely-seen tags are being renamed or removed. Your record does not care. It keeps working.

The rest of this post is about the dimmer switch, because that is the change that matters.

The Change That Actually Matters

Think of DMARC as having three settings.

• Off (the default p=none): no rules applied. You get reports, but inbox providers do nothing with suspicious mail.
• Quarantine (p=quarantine): suspicious mail goes to the spam folder.
• Reject (p=reject): suspicious mail gets blocked before it reaches anyone.

Going from "off" straight to "reject" is the scary move. The moment you flip that switch, any email from a sending source you forgot about - your payment processor, an old marketing tool, a legacy CRM, a forgotten invoicing platform - starts getting silently blocked. Real messages disappear. Customers do not get the receipts they were expecting. This is the scenario that keeps most teams stuck in the "off" position for years.

The old DMARC spec had a feature that was supposed to prevent this. It was called the pct tag, and it worked like a dimmer. You could tell inbox providers: "apply the reject rule to only 10% of suspicious mail for the first week, then bump it to 50%, then 100%." In theory, you would find the forgotten sending sources along the way, without breaking everything at once.

In practice, the dimmer did not work. Different inbox providers interpreted the percentage differently, and many did not apply partial settings at all. Our proprietary data shows that the pct tag was rarely used correctly and, across most domains, not used at all. You published pct=10 and hoped; the actual percentage of mail that got the rule applied was anyone's guess.

DMARCbis removes the dimmer entirely. The closest replacement is a new binary setting called the t tag: "testing" (treats a reject policy as if it were just quarantine) or "full enforcement" (the default). No percentage. No gradient. Just off or on.

The new spec does not replace the dimmer with a working version. It takes out the broken feature and leaves the gradual-rollout problem to you.

The Boring Changes, Briefly

If you are curious about the other pieces:

• The "where does your domain end" question is now answered by DNS lookups rather than by an external list called the Public Suffix List. For ordinary single-domain users, nothing changes in practice. If you run a platform that issues customer-branded subdomains (a hosting provider, a site-builder, a payments-as-a-service setup), or if your domain sits under an unusual public suffix, you will want to check that your DMARC records resolve the way you expect.
• The mailing list rule is now official. The new spec explicitly warns against a full reject policy on domains that have active mailing list traffic. The reason is the same operational pain point every list admin already knows: mailing lists rewrite email headers in ways that break DMARC, so a reject policy punishes innocent subscribers. The usual fix is a carve-out - put list traffic on a separate subdomain with a looser policy.
• A few tag renames. Three old tags (pct, rf, ri) are going away. Three new ones (psd, np, t) come in. Readers who want the full spec can find it at draft-ietf-dmarc-dmarcbis-41. For everyone else, your existing record does not care.

What DMARCbis Doesn't Solve

Removing the dimmer is an honest move. The feature did not work, and the new spec does not pretend it did. But removing it does not fix the underlying problem.

Here is what we see across a Q1 2026 snapshot of domains actively monitored on the DMARCeye platform.

• Four in ten domains with DMARC set up are stuck in "just watching" mode, sometimes for years. Rules turned on? None. Protection against spoofing? Zero. They have gone to the trouble of setting up DMARC and installing a monitoring tool, and they still do not block anything.
• Of the domains that do block, nineteen out of twenty flipped the switch all at once, going straight to 100% enforcement with no trial run. For most, this works out fine. For the ones where it does not, the first sign of trouble is usually a customer asking why they never got a receipt.

Two outcomes, one cause. DMARC offers no working middle ground between watching and blocking. The feature that was supposed to bridge the gap was unreliable, and DMARCbis removes it without replacing it with something that works.

What You Should Do

For most domain owners, the answer is: nothing urgent. Here is the longer version, depending on your situation.

• If you have never set up DMARC: set it up in "just watching" mode. You will start getting reports showing every source that sends mail claiming to be from your domain. You do not need to wait for DMARCbis. A record you publish today still works after the new spec lands.
• If you have been stuck in "just watching" mode for a long time: DMARCbis does not change your situation. The reason you are stuck is not the spec - it is the lack of a safe way to cross. Tools that show you what would break before you flip the switch are worth more than ever.
• If you used the dimmer (pct tag) to ramp up gradually: your record stays valid, but a DMARCbis-compliant inbox provider will treat your pct<100 record as if it were at 100%. Plan the transition now. The closest replacement is the new t=y testing mode.
• If your domain has active mailing lists: take the new official guidance seriously. A full reject policy on a domain with list traffic breaks legitimate subscribers. Most teams solve this with a carve-out - list traffic gets its own subdomain with a looser policy.

What This Asks of You

Nothing urgent. DMARC is still DMARC after DMARCbis, and the record you publish today will still be accepted the day the new spec becomes official. What changes is more philosophical than technical: treat the move from "watching" to "blocking" as a problem you will need to solve with visibility and tools, not with a built-in spec feature.

Tools that watch your DMARC reports, flag unknown senders before you turn blocking on, and tell you in plain language what would break under a stricter policy become more valuable as the standard itself becomes stricter. DMARCeye is built around exactly that role. Our free online tools (DMARC configurator, SPF, DKIM, and BIMI checkers) cover the setup side in under ten minutes.

Try DMARCeye free today and see what your domain's email reports actually say, before the spec shifts.