What is DMARCbis?

DMARCbis is the IETF's re-specification of DMARC, published in 2026 as RFC 9989 (core protocol), RFC 9990 (aggregate reporting), and RFC 9991 (failure reporting) — obsoleting the original RFC 7489 from 2015. It removes the `pct`, `ri`, and `rf` tags, adds `np` and `psd`, makes the external destination authorization record mandatory, and replaces Public Suffix List lookups with a DNS Tree Walk for organizational- domain discovery.

The short version

DMARC was originally specified in RFC 7489, published in 2015 as an informational document describing what a handful of large mailbox providers and senders had already deployed. In 2026, the IETF’s DMARC working group replaced it with three standards-track RFCs, collectively known as DMARCbis:

RFC 9989 — the core protocol: the DNS record, its tags, policy application, and alignment.
RFC 9990 — aggregate reporting (the rua reports every DMARC monitoring tool, including DMARCLoop, is built on).
RFC 9991 — failure reporting (ruf).

RFC 7489 is obsoleted, not merely superseded — it’s no longer the current specification, and DMARCLoop’s tools, rule catalogue, and generated records all target RFC 9989’s tag set. If you’re reading DMARC advice written before 2026, check whether it still applies; a fair amount of long-standing folk wisdom (starting with pct=10, for instance) no longer maps onto anything in the current spec.

Why re-specify it at all

DMARC had run for a decade as an informational RFC describing existing practice, with several tags that had drifted from how receivers actually behaved (ri being the clearest example — see below). DMARCbis moves DMARC onto the standards track and reconciles the spec with what large receivers were already doing, rather than what the 2015 document said they should do.

What actually changed

The detail lives in publishing a DMARC record, which has the full tag table; the summary:

pct, ri, and rf are removed, not deprecated. pct’s percentage-based rollout is replaced by the t=y testing-mode flag; ri is moot now that RFC 9990 mandates daily aggregate reports regardless of what a record requests; rf only ever had one defined value (afrf) and was redundant.
Two new tags: np sets a policy specifically for non-existent subdomains (previously its own separate extension, RFC 9091), and psd marks a record as belonging to a Public Suffix Domain.
The external destination authorization record is now a MUST. If your rua or ruf address points at a different domain than the one publishing the record, that destination has to publish an authorization TXT record (example.com._report._dmarc.reports.example.net). RFC 7489 said receivers should check this; RFC 9990 says they must — skip it and reports to a third-party address silently stop arriving.
A DNS Tree Walk mechanism replaces reliance on the Public Suffix List for finding a domain’s organizational domain, which matters for relaxed alignment and for policy inheritance to subdomains.

None of this changes the record’s basic shape — v=DMARC1; p=...; rua=mailto:... still works the same way it always has. It changes what the less-common tags do and tightens what receivers are required to enforce.

Does this affect a record published under the old spec?

Old records keep working. Current receivers ignore unknown or removed tags, so a record with a leftover pct=50 from 2019 doesn’t break — it’s just inert. The practical impact is forward-looking: don’t add pct, ri, or rf to a new record, don’t follow rollout advice that leans on gradual pct increases, and if you’re relying on a third-party reporting address, confirm the authorization record is in place — that’s the one change with a real failure mode (reports silently not arriving) rather than just an unused tag.

Where to check your own record

Publish or update a record with the DMARC Record Wizard, which generates against RFC 9989’s current tag set, and confirm what’s actually live with the DMARC Inspector.