DMARCbis (RFC 9989): what changed from RFC 7489

Short answer: in May 2026 the IETF published DMARCbis as RFC 9989 (the protocol), RFC 9990 (aggregate reports) and RFC 9991 (failure reports). They replace RFC 7489. Existing DMARC records keep working. The changes that matter for most domains: pct is retired, and there are new t and np tags.

Why a new version

RFC 7489 was published in 2015 as an Informational document, not a standard. DMARCbis puts DMARC on the IETF Standards Track (as a Proposed Standard), splits reporting into its own documents, and fixes parts of the original that implementations had handled differently. It also replaces RFC 9091, the experiment that applied DMARC to public suffix domains.

What changed

Change	RFC 7489	RFC 9989
Finding the organisational domain	Public Suffix List	A DNS tree walk up the domain's labels, capped at eight queries
`pct=`	Apply the policy to a percentage of failing mail	Historic: ignored by receivers that follow RFC 9989
`t=`	Not defined	New. `t=y` asks receivers to apply one level less than the policy (reject becomes quarantine, quarantine becomes none)
`np=`	Not defined	New. Policy for subdomains that do not exist; falls back to `sp`, then `p`
`psd=`	Not defined	New. Lets a public suffix operator (such as a registry) mark itself, or a domain declare itself as the organisational boundary
`rf=`, `ri=`	Failure report format, report interval	Historic
Status	Informational	Standards Track

What you should change

If you use `pct` to roll out gradually

Receivers on the new standard will treat p=quarantine; pct=25 as full quarantine. If you need a softer step, use t=y instead, and expect older receivers to ignore it. Most domains are better off moving through the stages without either. See moving from p=none to p=reject.

_dmarc.example.com. IN TXT "v=DMARC1; p=reject; t=y; rua=mailto:dmarc-reports@example.com"

If attackers use made-up subdomains

Phishing from names like secure-login.example.com, which do not exist in your DNS, is common. np=reject blocks them even if you need a softer sp= for real subdomains while you finish your rollout.

_dmarc.example.com. IN TXT "v=DMARC1; p=reject; sp=quarantine; np=reject; rua=mailto:dmarc-reports@example.com"

Everything else

Nothing else needs to change. v=DMARC1, p, sp, rua, ruf, adkim, aspf and fo work as before. A record that was valid under RFC 7489 is still valid.

Both versions in use for a while

Receivers will move to RFC 9989 at different speeds. For the next year or two, write records that make sense under both: avoid relying on pct, and treat t and np as improvements that some receivers will not yet apply.

The tree walk in practice

For almost every domain, the tree walk finds the same organisational domain the Public Suffix List did. The difference shows up for deep subdomains and for domains under suffixes the list handled inconsistently. If mail.example.com.au has no DMARC record, a receiver walks up to example.com.au and uses that record, just as before.

Check your record

The DMARC checker validates every tag, explains pct, and shows which record actually applies to a domain.