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

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 a dedicated article on what RFC 9989/9990/9991 change in DMARC.

What actually changes

Three changes deserve 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 a dedicated article on the t tag.

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.example.com even if that subdomain doesn't exist. Setting np=reject shuts that door with zero risk to legitimate mail. The psd tag is for public suffix domain operators (registries). For most organizations, np is the one that matters: a dedicated article on the np tag is coming soon.

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 a dedicated article on the DNS Tree Walk.

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

Here's the reassuring part: 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.
• An existing record stays valid: no receiver will reject it because it "dates from" 7489.

In other words, nothing has to change for the protection to hold. The new features are improvements to adopt at leisure, not urgent fixes.

Is action needed?

A domain already at p=reject with clean alignment is in good shape. Three small, easy, risk-free steps are still worth taking:

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

For a domain 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 will be covered in a dedicated article.

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. The real posture of entire sectors — how many domains sit at p=none, for instance — is on display 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, it means relying on DMARC is no longer a bet on a "best practice" but on an established standard — a strong argument when the choice has to be justified 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 the servers, DKIM signs the messages, DMARC(bis) requires one of the two to align with the 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 a host: the publication is still a simple TXT record. The new features (np, t) are just new tags inside that TXT, and any DNS can host a TXT.

Does moving to DMARCbis require a new tool? Not that either. The record can be edited by hand. A tool mainly answers what to publish (which tags, which policy) based on a 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 a sender, but the hygiene it encourages — reaching enforcement, locking down non-existent subdomains — strengthens 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. The new tags can wait for a convenient moment; 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. Recipients see no difference — except that forged mail in the sender's name is more reliably blocked, which protects them and the brand.

A security note: keys belong in the right place

DMARC, SPF and DKIM rely on secrets — chief among them the 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; centralizing and encrypting this kind of secret (DKIM keys, DNS credentials, API tokens) is precisely the job of Hucency Vault. Good key hygiene is the natural complement to a good DMARC policy.

Thomas handles DMARCbis

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

Free DMARC analysis of a domain or an account, and Thomas does the heavy lifting.