DMARCbis is here: what RFC 9989 changes and what it does not

DMARCbis, the long-awaited update to the DMARC standard, was published in May 2026. The short version: your records still start with v=DMARC1, there is no DMARC2, and no emergency change to your DNS is needed. A few new tags are worth adopting, and the standard now carries far more weight than it used to. Here is what moved and what stayed exactly where it was.

What was published

DMARCbis is not one document but three, all released together in May 2026:

• RFC 9989 is the core protocol, the rules for how DMARC records are read and enforced.
• RFC 9990 covers aggregate reporting, the daily summaries receivers send back to you.
• RFC 9991 covers failure reporting, the more detailed per-message reports.

Between them they obsolete the original DMARC specification, RFC 7489 from 2015, and also RFC 9091, which handled public suffix domains. If you have bookmarked references to RFC 7489, they now point at a retired document.

The change that matters most is a change in status

The original DMARC was published as an Informational RFC. In plain terms, that meant it described how a group of large mail providers had agreed to behave, but it was not a formal internet standard. It worked because the big players honored it, not because the standards process blessed it.

DMARCbis is different. DMARC is now a Proposed Standard on the IETF Standards Track. That is the formal path a protocol takes to become a recognized part of how the internet works. Nothing about your mail changes the day this happens, but it settles a decade of “is DMARC actually a standard” arguments, and it gives vendors, auditors and compliance frameworks something solid to point at.

Your existing records keep working

This is the part worth repeating, because it is where the panic usually starts. Every valid DMARC record you have today is still valid. They still begin with v=DMARC1. There is no v=DMARC2, no new version string, and no requirement to republish anything by a deadline. If you did nothing at all in response to DMARCbis, your protection would not weaken.

The standard was written this way on purpose. Millions of domains publish DMARC records, and breaking them overnight was never on the table. DMARCbis tidies the specification and adds a few capabilities, but it is careful to stay compatible with what is already out there.

The tags that were removed

Three tags from the old specification are gone: pct, ri and rf.

The one people ask about is pct. It let you apply your policy to only a percentage of failing mail, for example “quarantine 10 percent of failures”. It was meant to ease the move from monitoring to enforcement, but in practice it behaved inconsistently across receivers and caused more confusion than it solved. DMARCbis removes it.

If your current record still contains pct, it will not break anything. Older receivers may still honor it during the transition. It simply is not part of the standard any more, and there is now a cleaner way to stage a rollout, covered below.

The ri tag (reporting interval) and rf tag (report format) are also removed. Neither did much useful work in real deployments, so their absence will go unnoticed by almost everyone.

The tags that were added

DMARCbis adds two tags worth knowing about:

• np sets the policy for non-existent subdomains, meaning subdomains that have no DNS records at all. This closes a spoofing gap, because scammers love inventing plausible subdomains like billing.yourbusiness.com that you never created. With np=reject, mail claiming to come from a subdomain that does not exist is refused.
• psd flags a public suffix domain. This is a specialist tag for registry operators and the people who run whole families of domains, not something a typical business needs to set.

The existing sp tag, which sets a separate policy for your subdomains, stays exactly as it was. We go deeper on sp and np together in our guide to DMARC for subdomains and domains that do not send email.

Staged rollout without pct

With pct gone, the standard way to signal that you are still testing is the t tag. Setting t=y tells receivers your policy is in a testing state, so they can apply a lighter touch while you confirm your legitimate mail is authenticating correctly. It effectively replaces what pct was trying to do, but in a clearer, all-or-nothing way rather than a percentage dial.

The practical mechanics of moving from monitoring through to full enforcement have not changed much, and the safe order still matters more than the exact tags. We walk through the whole progression in from quarantine to reject.

The tree walk, briefly

One more change is under the bonnet. The old standard leaned on a public list of domain suffixes to work out where your organisational domain sat. DMARCbis replaces that with a live DNS lookup process called a tree walk, bounded to eight queries. For most single-domain businesses this changes nothing you can see, but if you run subdomains that send important mail, it is worth understanding. We cover it on its own in the DNS tree walk in DMARCbis.

What to actually do

Nothing urgent. If you want a short checklist:

• Leave your working record alone. It is still valid.
• If you run subdomains, consider adding np=reject once you are confident your real subdomain mail is authenticated.
• Drop pct from your record when you next edit it, since it no longer does anything defined.
• Keep aiming for an enforced policy, because a monitoring-only p=none still stops nothing, standard or no standard.

If you are not sure what your domain publishes right now, run the free DMARC checker and it will analyze your live record and explain it in plain terms. For the ground-up explanation of how DMARC works in the first place, start with what is DMARC. DMARCbis is a tidy-up and a promotion, not a rebuild. The record you already trust keeps doing its job.