DMARC Is Now an Internet Standard: What RFC 9989 Changes for Your Record

DMARC has protected email domains from spoofing since 2012, and nearly every major mailbox provider enforces it. But the document everyone implemented, RFC 7489 (2015), was never an IETF standard. It was published as an *Informational* document through the independent submissions stream: a description of what the industry was already doing, not an agreed specification.

In May 2026 the IETF published the replacement, developed for several years under the working name DMARCbis, as three documents:

• RFC 9989 — the core protocol: records, policy discovery, alignment and validation.
• RFC 9990 — aggregate reporting (the daily rua XML reports).
• RFC 9991 — failure reporting (the per-message ruf reports).

RFC 9989 is on the Standards Track as a Proposed Standard, and it obsoletes RFC 7489 and RFC 9091 (the experimental extension for public suffix domains such as .gov or .bank).

The short version for domain owners: your existing record keeps working. The version tag is still v=DMARC1 — there's no DMARC2 — and p=none, p=quarantine, p=reject, sp, adkim, aspf, rua and ruf all mean what they meant before. A few tags changed, though, and one of them is in many records.

`pct` is gone. It told receivers to apply the policy to only a percentage of failing messages, and generations of guides — including older versions of ours — recommended ramping up with pct=25, then 50, then 100. In practice receivers implemented it inconsistently — values other than 0 and 100 were rarely applied as written. RFC 9989 drops it.

If your record says pct=100, it's harmless — it was the default anyway. If it says anything lower, receivers following the new specification will ignore it and apply your policy to all failing mail. Decide which you actually mean, then either remove pct or replace it with the new test-mode tag below.

`rf` (failure report format) and `ri` (requested aggregate report interval) are also removed. Almost nobody set them, and receivers mostly ignored them. Reports are now sent at intervals the receiver chooses — typically daily.

`t` — test mode. t=y asks receivers not to apply your policy in full. In the RFC's words, if the policy is quarantine and t=y, failing mail is treated as none; if the policy is reject and t=y, failing mail is quarantined. Reports keep flowing normally. It replaces the one behaviour of pct that receivers implemented consistently, pct=0.

v=DMARC1; p=reject; t=y; rua=mailto:dmarc@example.com

That record says "I intend to reject, but treat failures as quarantine while I check the reports". Remove t=y when you're ready.

`np` — policy for non-existent subdomains. Attackers often spoof subdomains that don't exist, like billing.example.com, hoping the policy for real subdomains is weaker. np=reject applies only to subdomains that don't exist in DNS, so you can lock those down even while a real subdomain is still on p=none. If np is absent, sp applies, then p.

`psd` is for operators of public suffix domains, such as a registry running .bank, to declare themselves as one. Ordinary domain owners never need it.

DMARC needs to know a domain's organizational domain — the registrable domain that owns it. For mail from news.mail.example.co.uk, that's example.co.uk. Alignment is checked against it, and if a subdomain has no DMARC record of its own, the organizational domain's record applies.

RFC 7489 worked this out using the Public Suffix List, a community-maintained file of domain endings like .co.uk and .github.io. That meant every receiver needed a copy of the list, copies went out of date, and DMARC's behaviour depended on a file outside the DNS.

RFC 9989 replaces it with a DNS tree walk: the receiver queries for _dmarc records at each level of the name, from the full domain upwards, and uses what it finds — including psd= flags — to determine the organizational domain. Everything needed is in the DNS.

For almost all domains the result is the same as before. The RFC notes that some unusual setups may get a different organizational domain, and that publishing explicit DMARC records on subdomains you send from, together with strict alignment (adkim=s; aspf=s), removes any ambiguity.

Look up your record with the Email Authentication Checker or with dig:

$ dig _dmarc.example.com TXT +short
"v=DMARC1; p=quarantine; pct=50; rua=mailto:dmarc@example.com"

Then:

1. `pct` below 100? Decide whether you want enforcement on all mail. If yes, remove pct. If you're still testing, replace it with t=y. The checker flags pct and shows whether test mode is on.
2. Still on `p=none` after months? This hasn't changed, but it's the most common gap: p=none only collects reports. The SPF, DKIM and DMARC guide has a step-by-step path to enforcement.
3. Consider `np=reject`. It's low risk — mail can't legitimately come from a subdomain that doesn't exist — and it closes a common spoofing route.
4. Leave `rf` and `ri` out of new records.

Mailbox provider requirements haven't changed with the new RFCs. Google, Yahoo and Microsoft still require a DMARC record from bulk senders, and p=none still satisfies the minimum. See why emails go to spam for the current sender requirements.