DMARCbis (RFC 9989): what changed and what to check

DMARCbis is the IETF's standards-track replacement for the original informational DMARC specification (RFC 7489), published as RFC 9989. It is not a new policy senders must opt into - existing DMARC records keep working - but it formalizes ambiguities that mailbox providers and auditors previously had to interpret on their own, and it changes a few mechanics worth checking.

Why this matters even though "DMARC" hasn't changed its name

DMARCbis is DMARC, now on a standards track instead of informational status. The practical effect is that mailbox providers and compliance frameworks now have an authoritative spec to point to instead of years of accumulated interpretation - which means ambiguous cases that used to be handled inconsistently (how aggregate reports should be structured, how subdomain policy inherits) now have a defined answer.

What changed at the protocol level

The Public Suffix List dependency is gone. The original DMARC spec relied on the Public Suffix List (PSL) to determine organizational domain boundaries - a list that is externally maintained, not always current, and inconsistently implemented across validators. DMARCbis replaces this with a DNS Tree Walk: a validator checks for a DMARC record at each level of the domain hierarchy, from the exact sending domain up to the top-level domain, until it finds one. This removes a class of bugs where a subdomain's policy silently depended on PSL data a given mail system hadn't updated.

Tags removed. pct (percentage of mail subject to policy), rf (report format), and ri (report interval) are removed - pct in particular had become a bad practice, since partial enforcement unpredictably exempts a slice of spoofed mail from policy.

Tags added. np (policy for non-existent subdomains, closing a gap where attackers could spoof subdomains that have no mail-sending purpose), psd (marks a domain as a Public Suffix Domain), and t (testing flag).

New guidance on `p=reject`. DMARCbis adds explicit recommendations around applying p=reject for domains that don't send mail at all, reducing the spoofing surface for parked and non-sending domains.

Do you need to redo your DMARC setup?

In most cases, no. If your existing record authenticates correctly today, it continues to work under DMARCbis - the spec update targets validator behavior and closes ambiguity, not senders' day-to-day records. The one practical action: if your record still uses pct for partial rollout, finish that rollout and remove it, since pct is deprecated and its long-term support is not guaranteed.

A five-point record audit

1. Confirm the record resolves. dig TXT _dmarc.yourdomain.com should return a record starting v=DMARC1;.
2. Check the policy. p=none monitors only; p=quarantine and p=reject enforce. Most domains should be working toward p=reject once aggregate reports (rua) show clean alignment.
3. Confirm `rua` is set to an address or reporting service you actually monitor - a DMARC record with no reporting is flying blind.
4. Drop deprecated tags. Remove pct, rf, and ri if present; they no longer have defined behavior under DMARCbis.
5. Check subdomain policy with sp= if subdomains send mail with different trust levels than the root domain - and confirm non-sending subdomains are covered, ideally with a np=reject-equivalent posture once your DNS tooling supports the new tag.

The three documents that replaced one

DMARCbis is not a single RFC - it's three, all published together in May 2026, replacing the single informational RFC 7489:

• RFC 9989 - the core DMARC mechanism (the one usually meant by "DMARCbis").
• RFC 9990 - aggregate reporting format and semantics (what used to be an informal appendix to 7489 is now its own standards-track document).
• RFC 9991 - failure reporting.

All three moved from Informational to Proposed Standard status, which is the practical reason mailbox providers and compliance frameworks can now cite a settled spec instead of years of inconsistent interpretation of 7489.

The DNS Tree Walk, worked through

Say a message is sent from news.mail.example.com. Under the old PSL-dependent lookup, a validator needed external Public Suffix List data to know where the organizational domain boundary sat. Under the DNS Tree Walk in RFC 9989, the validator instead checks, in order:

_dmarc.news.mail.example.com   (checked first)
_dmarc.mail.example.com        (checked if the above has no record)
_dmarc.example.com             (checked if neither above has a record)
_dmarc.com                     (stops before the public TLD itself)

The first level with a published DMARC record wins. This is why a subdomain with no record of its own still inherits a policy from example.com - and why publishing an explicit, more permissive policy at a subdomain (if you want one) requires actually placing a record there rather than relying on inheritance.

What the np tag closes

Before np, a domain that never sends mail from unused.example.com had no way to say so in DNS - an attacker could spoof that exact subdomain and no DMARC policy applied unless the parent's sp= tag happened to cover it. np=reject at the organizational domain now explicitly rejects mail claiming to be from any non-existent subdomain, closing a gap that previously required manually publishing sp=reject and hoping it was interpreted correctly.

Tags removed vs. added, at a glance

MailPilot checks SPF, DKIM and DMARC against what's actually published for a domain as part of every reputation check - so a DMARCbis-era audit like the one above runs automatically rather than as a one-time manual DNS lookup.