DMARCbis is here. What is changing. And what is not.

Anyone who checks mail security knows this: one tool for SPF, another for DMARC, a third for TLS status. A separate service for every question. At some point, this bothered me enough that I built it all into a single tool, an analysis that checks SPF, DKIM, DMARC, and the associated mechanisms in one go. Conveniently, these settings are all located in the DNS, meaning they are publicly viewable and can be evaluated for any domain without access to its systems.

In the process, I inevitably had to dive very deep into the rules governing how it all works. And then something happened that you don't experience every day: right in the middle of my work, the exact set of rules I was mapping was officially updated.

In May 2026, the IETF published DMARCbis—as the revision is called in the community—with three new RFCs (9989, 9990, and 9991) that replace the previous DMARC standard from 2015 (RFC 7489). Anyone dealing with the topic has probably noticed, often accompanied by the question I've been asked most frequently since then:

"Do I need to do anything now?"

In short: no, your record will keep working. There are a few adjustments in the details, especially if you are moving towards enforcement in stages. The larger part is of a formal nature: DMARC has been cleaned up and is now a true, IETF-backed standard. DMARC never had this status in the eleven years prior: before, it was strictly speaking a specification submitted via the Independent Submission Stream, without formal IETF consensus.

The lack of this consensus had practical consequences. One example is the pct tag, which allowed DMARC enforcement to be applied gradually to a percentage of emails. In practice, only the values 0 and 100 worked reliably. Mail receivers implemented intermediate values so differently that the result was barely predictable. DMARCbis draws the logical conclusion, drops pct and introduces the clearer t (testing) tag for test operation. The Working Group documents the background in RFC 9989, Appendix A.6, a passage well worth reading, with more details on this later.

Crucial for all changes: there is no "DMARC2". The record still begins with v=DMARC1, and everything that works today will continue to work. No reason for hectic DNS changes.

However, what has changed under the hood is worth a closer look. This post provides an overview and points to dedicated posts for the details, which will be added over time.

One Standard, Three Documents

DMARC was previously contained in a single document (RFC 7489). DMARCbis splits this into three RFCs:

• RFC 9989 – the core protocol: How to publish a policy, how receiving servers check emails against it, and what happens in case of a failure. This is the part that contains the most changes and is relevant for domain owners.

• RFC 9990 – Aggregate Reporting: the daily XML reports that show which sources are sending on behalf of a domain and how they perform with SPF, DKIM, and DMARC.

• RFC 9991 – Failure Reporting: the rarer, event-based reports on individual failed emails.

The purpose of this split: the three areas can evolve independently of each other in the future without having to reopen the entire standard every time. Anyone dealing with reporting doesn't have to plow through the core protocol, and vice versa.

In everyday terms, this means: when people talk about "the new DMARC specification", they usually mean RFC 9989. The other two are supporting documents for the reporting infrastructure.

A quick note on the name: "bis" is the usual designation in the IETF environment for the revision of a specification (from the Latin for "twice"). Working drafts then carry names like 5321bis or 5322bis, the ongoing revisions of the SMTP and mail format standards. Similarly, the DMARC revision was managed as "DMARCbis". However, the term never became official: the result is simply still called DMARC (RFC 9989), with the same version identifier v=DMARC1. "DMARCbis" is therefore the working name of the revision, not a new protocol. This is also why there is no "DMARC2".

What Specifically Changes

The actual innovations of DMARCbis can be summarized in a few points. Each of these will get its own detailed post, but here is the overview:

• Cleaned-up tags. Three tags are being removed (pct, rf, ri), and three are being added (np, psd, t). Existing records remain valid; obsolete tags will be ignored by receivers. What this means in detail and what you should remove from your record is covered in a separate post: DMARCbis Tag Changes: Why t Doesn't Replace pct

• The DNS Tree Walk. To determine the Organizational Domain, the Public Suffix List is replaced by a DNS-based process: receivers walk up the DNS tree label by label instead of consulting an externally maintained list, controlled via the new psd tag. For most domains, the result remains unchanged; for complex subdomain structures, it becomes more precise. (separate post following)

• The p=reject recommendation, reversed. For domains with normal user mailboxes (think mailing lists, forwards), DMARCbis now advises against p=reject and recommends p=quarantine instead, as long as the authentication chain is not fully controlled. One of the most remarkable turnarounds, discussed in detail in a (separate post).

• "Full DMARC participation", now normative. For the first time, the standard defines in normative and thus binding language what correct DMARC implementation actually means, both for senders and for receiving systems. (separate post following)

Where This Fits In, and What's Next

DMARC does not work alone. It builds on SPF and DKIM: without clean SPF or DKIM authentication that matches the sender domain, DMARC fails. Both will therefore get their own foundational posts, independent of DMARCbis, as the revision does not change SPF and DKIM themselves.

And looking ahead: the topic of email security does not stand still. ARC, the transport side (MTA-STS, DANE, DNSSEC, TLS-RPT), and prospectively DKIM2 are the next building blocks. These will be added step by step.

What to Do Now (and What Not to Do)

The good news first: in the vast majority of cases, nothing urgent. Nevertheless, it is worth taking a quick look at your own record in three places:

• Remove obsolete tags. If pct, rf, or ri are in your record, you can remove them during your next scheduled DNS change. Not a must, as receivers ignore them, but cleaner. Why the three were removed is explained in the tag post. t replaces the testing purpose of the old pct; details are also there.

• Consider np. This is the most practically useful innovation: with np, you set a separate policy for non-existent subdomains, thereby blocking spoofing via subdomains that do not even exist in your DNS. Previously, sp had to cover this; now it can be done cleanly and specifically.

• Keep calm about the rest. No v=DMARC1 change, no rebuilding, no migration. What runs cleanly today will continue to run.

If you are touching your record anyway, this is a good moment to check it completely against the current state of the art: not just for the DMARCbis changes, but for the entire chain of SPF, DKIM, and DMARC.

See for Yourself

The fastest way to see where you stand is to run your domain through a check. That is exactly why I built the Mailaudit tool. It checks SPF, DKIM, DMARC, and the associated mechanisms in one run and shows where a domain stands: https://mailaudit.cloudpandas.com/

And if questions arise from that: everything is open for discussion.

DMARCbis series

1. Overview (this post)

2. Tag Changes

3. DNS Tree Walk

4. p=reject / Full Participation

5. NIS2