DMARCbis (DMARC V2): what actually changes, in plain English

In May 2026, the IETF published DMARCbis — the modernized version of the DMARC standard, often called "DMARC V2" or "DMARC 2.0." It replaces the original RFC 7489, which dated back to 2015. If you already have a DMARC record, the first question is fair: do I have to redo everything? The short answer is no — but there are a few new things genuinely worth knowing. This guide explains what DMARCbis is, why it exists, what actually changes, and what you can do today.

DMARCbis, in one sentence

DMARCbis is a revision of DMARC: same goal (tie SPF and DKIM to the visible From: domain to stop spoofing), but a rewritten, better-structured text with clearer definitions, a few new tags, and a more robust way of attributing domains. If you're new to this, start with what is DMARC; DMARCbis doesn't overturn a single principle described there — it refines them.

Why a new version

RFC 7489 had an odd status: Informational. In plain terms, it was a reference document, not an official IETF standard. Ten years of massive use later, the working group wanted to fix that gap. DMARCbis therefore moves DMARC, for the first time, onto the standards track (as a Proposed Standard). Along the way, field experience made it possible to drop what worked poorly, clarify the gray areas, and add what was missing.

The three DMARCbis RFCs

DMARCbis isn't a single document but three, which clarifies a once-confusing structure:

• RFC 9989 — the core protocol (policies, alignment, tags). The direct successor to 7489.
• RFC 9990 — the aggregate reports (RUA), the daily feedback channel.
• RFC 9991 — the failure reports (RUF), rarer and subject to privacy constraints.

Together, these three RFCs obsolete RFC 7489. We break down their contents in RFC 9989/9990/9991: what changes in DMARC.

What actually changes

Three changes deserve your attention. None is a breaking change, but each has a practical effect.

1. The pct tag is gone, replaced by t

The old pct tag applied the policy to a percentage of mail (pct=25, then 50, then 100) for a gradual rollout. In practice, it behaved unpredictably across receivers. DMARCbis removes it and introduces a binary testing mode, the t tag (t=y means "I'm experimenting, don't enforce strictly yet"). Ramping up now relies on observing the reports rather than on a percentage. We dig into this in the end of pct, hello t testing mode.

2. Two new subdomain tags: np and psd

The np tag sets the policy for non-existent subdomains — a classic spoofing target, because an attacker can forge invoice.your-domain.com even if that subdomain doesn't exist. Setting np=reject shuts that door with zero risk to your legitimate mail. The psd tag is for public suffix domain operators (registries). For most organizations, np is the one that matters: see the np tag explained.

3. The DNS Tree Walk replaces the Public Suffix List

To determine the "organizational domain" (for example, that mail.my-bank.com belongs to my-bank.com), DMARC relied on the Public Suffix List, an externally hand-maintained list. DMARCbis replaces it with the DNS Tree Walk: a sequence of step-by-step DNS queries (eight at most), with no dependency on a third-party list. More robust, more predictable. Details in the DNS Tree Walk.

What doesn't change (and that's reassuring)

Here's the part that should put you at ease: DMARCbis is not a breaking change.

• Records still start with v=DMARC1. No v=DMARC2, no new format to learn.
• The p, sp, rua, ruf, adkim, aspf, fo tags keep exactly the same meaning.
• The alignment principle — the heart of DMARC — is unchanged.
• Your current record stays valid: no receiver will reject it because it "dates from" 7489.

In other words, you have to change nothing to stay protected. The new features are improvements to adopt whenever you like, not urgent fixes.

Do you need to act?

If your domain is already at p=reject with clean alignment, you're fine. Three small, easy, risk-free steps are still worth it:

1. Add np=reject to lock down your phantom subdomains.
2. Remove a now-useless pct if it's still lingering in your record.
3. Confirm your reports still arrive (the RUA channel is now framed by RFC 9990).

If you're still stuck at p=none, the priority isn't DMARCbis: it's reaching enforcement. The method is the same as before — see how to get to p=reject without breaking email. The full migration roadmap is in do you need to migrate to DMARCbis.

Where does the market stand?

DMARCbis adoption is gradual: receivers update their implementations at their own pace, and the new tags (np, t) will appear in reports little by little. You can watch the real posture of entire sectors — how many domains are only at p=none, for instance — in the DMARC Observatory. The finding is stark: across many sectors, most domains still enforce no policy at all. DMARCbis won't change that on its own; alignment discipline will.

From 2015 to 2026: why now

DMARC was published as RFC 7489 in 2015, with Informational status. Over a decade, it became a de facto standard: Google, Microsoft and Yahoo require it from bulk senders, and regulations like NIS2 or DORA make it an expected control. That gap — critical use resting on a merely "informational" document — needed fixing. DMARCbis is the result of several years of IETF work to turn field experience into a real standard: promote the protocol onto the standards track, drop what worked poorly (pct), and close the blind spots (np for non-existent subdomains, the Tree Walk in place of the PSL). The May 2026 timing isn't arbitrary: it acknowledges the maturity of a protocol that has become unavoidable. In practice, for you, it means relying on DMARC is no longer a bet on a "best practice" but on an established standard — a strong argument when you have to justify your choices to management or an auditor.

Frequently asked questions about DMARCbis

Does DMARCbis replace SPF and DKIM? No. DMARCbis touches neither SPF nor DKIM: it remains the layer that ties them to the visible domain via alignment. SPF declares your servers, DKIM signs your messages, DMARC(bis) requires one of the two to align with your From:. The three still work together — see how SPF, DKIM and DMARC work together.

Is my v=DMARC1 record still valid? Yes, completely. DMARCbis deliberately kept the v=DMARC1 identifier so nothing breaks. A record written for RFC 7489 stays a perfectly valid DMARCbis record; no receiver will reject it.

Do I need to wait for my DNS host to "support" DMARCbis? No. DMARCbis asks nothing special of your host: you still publish a simple TXT record. The new features (np, t) are just new tags inside that TXT, and any DNS can host a TXT.

Do I need a new tool to "move" to DMARCbis? Not either. You can edit your record by hand. A tool mainly helps you know what to publish (which tags, which policy) based on your domain's real state — that's Thomas's role, below.

Does this concern small domains? Yes, but without urgency. A small domain mainly benefits from setting np=reject (free, risk-free) and, if it isn't protected yet, from aiming for p=reject — DMARCbis or not. Size doesn't change the logic, only the number of sources to align.

A couple more common questions

Will DMARCbis improve my deliverability? Indirectly. DMARCbis itself doesn't change how mailbox providers score you, but the hygiene it encourages — reaching enforcement, locking down non-existent subdomains — strengthens your domain reputation, and enforcing domains are trusted more. The deliverability win comes from p=reject, which DMARCbis makes cleaner to reach, not from the new tags alone.

Is there a deadline to adopt DMARCbis? No. There's no cutoff date and no penalty for staying on a 7489-style record. Adopt the new tags when convenient; the only thing worth doing promptly is np=reject, because it closes a real gap at zero cost.

Does any of this change how my emails look to recipients? Not at all. DMARC operates behind the scenes, in DNS and at the receiving server. Your recipients see no difference — except that forged mail in your name is more reliably blocked, which protects them and your brand.

A security note: keep your keys in the right place

DMARC, SPF and DKIM rely on secrets — chief among them your DKIM private keys. Leaving them lying around in a config file or an email is exactly the kind of slip an attacker loves. DMARC.com is published by Hucency, a cybersecurity company; to centralize and encrypt this kind of secret (DKIM keys, DNS credentials, API tokens), take a look at Hucency Vault. Good key hygiene is the natural complement to a good DMARC policy.

Let Thomas handle DMARCbis for you

Tracking a standard's evolution while you run a business isn't your job. Thomas, your virtual CISO, generates the exact DNS to publish (DMARCbis tags included: np, t), names every sending source from your reports, scores your readiness on rolling data, and tells you the precise moment it's safe to tighten — from p=none all the way to p=reject.

Analyze your domain for free → or create an account and let Thomas do the heavy lifting.