DMARCbis: rewriting the manual for a lock that's been on the door for years

You know the type. You have a lock on your door — works perfectly. Has done for years. Never had an issue.

And then a new version of the manual appears.

Not a new lock. Not an extra deadbolt. Just the same manual, but with clearer diagrams and less ambiguous sentences. So the locksmith in Germany interprets it exactly the same way as the one in Portugal.

That’s DMARCbis.

First: what’s that lock again?

Email security has rested on three pillars for years:

• SPF → who is allowed to send email on behalf of your domain
• DKIM → has the content been tampered with in transit
• DMARC → what should happen when a check fails

If your DMARC is properly configured (ideally at p=reject), the problem is solved: nobody can impersonate your domain in an email. The lock is on the door. Has been for years.

“But there’s a new standard!”

A new term is blowing through the world of email security: DMARCbis.

And as tends to happen in this world, it quickly gets inflated beyond what it actually is.

“New standard against spoofing.” “Next step in email security.” “Better protection of the From field.”

Sounds impressive. But when you look past the marketing layer, reality is far less exciting.

What DMARCbis actually is

DMARCbis (RFC 9989) is the successor to the original DMARC specification. But “successor” is misleading here.

It’s not a reinvention. Not a new security layer. And it doesn’t change how spoofing is fundamentally prevented.

What it does do:

• Clarifies ambiguous parts of the original specification
• Makes interpretation more consistent across mail servers
• Modernises descriptions of alignment and policy evaluation
• Cleans up technical ambiguity

In short: DMARCbis makes DMARC more consistent, not more powerful.

It’s like going from version 1.0 of the IKEA manual to version 1.1. The cabinet is the same. The screws are the same. Only step 7 is now drawn less confusingly.

What doesn’t change

This matters more than what does:

• ❌ no new anti-spoofing mechanisms
• ❌ nothing changes about SPF or DKIM
• ❌ no new DNS tags
• ❌ the “From: field problem” remains exactly the same

The core stays identical: SPF + DKIM + alignment determine whether an email is legitimate.

Why it sounds “new and exciting”

Email is an old protocol. And anything that gets adjusted about it quickly feels new, more secure, more modern, stricter.

But in reality, DMARCbis is this: a rewrite of the user manual for a lock that’s been on the door for years.

The real security has been elsewhere for a long time

What’s often forgotten: the major email providers have been doing the real work themselves for years.

Google, Microsoft and Apple:

• Already enforce DMARC more strictly than the standard requires
• Filter spoofing aggressively at server level
• Block suspicious domains before they reach the inbox

DMARCbis changes nothing fundamental about that. The scale and control of those providers are the actual line of defence — not an RFC document.

The real problem isn’t in the protocol

The email world has a persistent pattern: every new RFC gets sold as “the solution to spoofing.”

But spoofing hasn’t been the core problem at protocol level for major providers in years. The problem lies elsewhere:

• Human interpretation (display names that resemble known senders)
• Social engineering (“your account has been blocked, click here”)
• Lookalike domains (micr0soft.com instead of microsoft.com)

You don’t solve that with a new RFC version. You solve it with awareness and training.

The real problem: almost nobody actually turns the lock

The irony is that while the world debates DMARCbis, the vast majority doesn’t even use existing DMARC correctly.

The numbers (early 2026, based on millions of domains):

• ~60% of all domains do effectively nothing against spoofing
• 32% have DMARC set to p=none — monitoring without action
• 22% are on p=quarantine — suspicious mail goes to spam
• Only 18% enforce with p=reject — unauthorised mail is refused

(Sources: dmarcdkim.com, dmarceye.com Q1 2026, Red Sift December 2025)

And that’s just about the existence of records. The reality is worse: domains with DKIM keys that don’t resolve, 1024-bit keys that should have been rotated years ago, SPF records never updated after a provider switch.

The “forever none” problem is real: organisations set DMARC to none for monitoring, see the complexity of their mail flows, and never dare to scale up to reject. The lock is on the door, but it’s left ajar.

Conclusion

DMARCbis is not a revolution. It’s maintenance.

And that’s exactly what mature internet standards look like when they’re finally stable: no big leaps. No new magic. Just refinement of what already works.

But that doesn’t mean DMARC doesn’t matter. Quite the opposite: it’s the foundation that Microsoft, Google and Apple build their filtering on. If your SPF, DKIM and DMARC aren’t correctly configured, those providers have nothing to rely on. The entire chain fails — and your email lands in spam, or worse: someone else can send mail on behalf of your domain.

The good news for small business owners: with a smaller organisation, it’s relatively straightforward to get everything right. You don’t have complex mail flows, dozens of third-party senders, or legacy systems. Configure it once and you’re in the top 11% who actually have it sorted.

Or in plain language:

The door was already locked. DMARCbis just makes the manual clearer. But the lock still needs to be properly set — and for most businesses, it isn’t yet.

Curious how your website performs? Try the free website check.