The New DMARC Standard (RFC 9989): What Actually Changed
DMARC was rewritten. In May 2026 the IETF published RFC 9989, 9990 and 9991, replacing RFC 7489 which had defined the protocol since 2015. Nothing you have published breaks — but three tags are dead, three are new, and one long-standing piece of plumbing was replaced. Here is what matters and what does not.
Why it was split into three documents
RFC 7489 was one large Informational document. The replacement is three: RFC 9989 for the core protocol — policy evaluation, alignment, record processing — RFC 9990 for aggregate reporting, and RFC 9991 for failure reporting. The protocol also moved from Informational status onto the IETF standards track, which matters mainly to auditors: there is now a formal Internet Standard to cite rather than an informational note.
pct is gone, and it deserved to be
pct was DMARC's only built-in mechanism for staged rollout — apply the policy to 10% of failing mail, then 50%, then all of it. In principle it was the safe path from monitoring to enforcement.
In practice receivers implemented it inconsistently enough that only pct=0 and pct=100 behaved predictably, and everything in between varied by provider. Worse, it produced a specific failure mode I have seen repeatedly on audits: a domain publishes p=reject; pct=10, the dashboard reports a reject policy, and one message in ten is actually enforced. It reads as finished. It is not.
If a domain of yours still carries pct below 100, that is not a configuration — it is a rollout somebody walked away from. Decide: enforce fully and drop the tag, or publish t=y and be honest that the policy is provisional.
t: the honest replacement
t is a binary testing flag. t=n is the default and enforces the published policy; t=y tells receivers the policy is provisional and should not be applied, roughly equivalent to the old pct=0.
It is a smaller tool than pct pretended to be, and that is the point — it says something receivers can implement identically. What it does not give you is a graduated ramp, so the question of how to cross from monitoring to enforcement without breaking legitimate mail is still answered the same way it always was: read your aggregate reports until nothing legitimate is failing, then move.
np: the one worth acting on
This is the addition with real value. sp has always set the policy for subdomains — but only for subdomains that exist. Mail claiming to come from a subdomain that was never created sat in a gap.
That gap is exactly what makes accounts.yourdomain.com or billing.yourdomain.com attractive to a spoofer: the name looks plausible to a human and there is no DNS record behind it. np closes it. If unset it falls back to sp, then to p.
No legitimate mail can originate from a subdomain that does not exist, so np=reject costs you nothing on a normal domain. It is the rare authentication change that is both low-risk and genuinely protective. The one caveat: some authoritative nameservers do not correctly return NXDOMAIN for a name with no records, so behaviour depends a little on your DNS provider.
The Public Suffix List is out
To work out where your organizational domain boundary sits — whether mail.yourdomain.co.uk aligns with yourdomain.co.uk — DMARC used to consult the Public Suffix List, an externally maintained file. RFC 9989 replaces that with a DNS tree walk: the receiver queries up the hierarchy directly, bounded to a small number of lookups.
This is a receiver-side change and most senders will never notice it. If you operate a large subdomain estate, the practical guidance is unchanged and worth repeating: publish an explicit DMARC record on every domain and subdomain you actually send from, rather than relying on organizational-domain fallback to do it for you.
psd, and why you can ignore it
psd marks a record as belonging to a public suffix domain — a registry operator publishing policy for everything beneath it. Unless you run a TLD or a public suffix, leave it unset. It exists for a small number of operators and does nothing useful on a normal business domain.
What to actually do
pct, rf and ri. If pct=100, deleting it changes nothing. If it is lower, that is a decision to make rather than a tag to delete quietly.np=reject. Low risk on any domain with a normal DNS setup, and it closes a real spoofing route.psd alone unless you operate a public suffix.pct, with np and t available.What has not changed
Worth stating plainly, because the volume of commentary around this release makes it sound larger than it is. Alignment rules are identical. SPF and DKIM are evaluated exactly as before. The version tag is still v=DMARC1. Bulk sender requirements from Google, Yahoo and Microsoft are unaffected — they still ask for a record at p=none or stricter — see Google's sender guidelines FAQ and Yahoo's sender best practices. And if DMARC is failing while SPF and DKIM pass, the cause is still alignment, exactly as it was.
Receiver adoption of the new tags will be gradual — the large providers have not published implementation timelines — so treat np and t as additions rather than substitutes for a correct p and sp. If a new tag does not behave as expected, the likely explanation is that the receiver has not implemented it yet.
Sources
- RFC 9989 — Domain-based Message Authentication, Reporting and Conformance (DMARC), IETF
- RFC 9990 — DMARC Aggregate Reporting, IETF
- RFC 9991 — DMARC Failure Reporting, IETF
- RFC 7489 — the 2015 specification these replace
- IETF Datatracker: RFC 9989 — document history and status
Tools for this
DMARC checkerSee whether your policy enforces anything.DMARC generatorBuild a valid record tag by tag.Frequently asked questions
What is RFC 9989?
RFC 9989 is the core document of the updated DMARC specification, published in May 2026 alongside RFC 9990 (aggregate reporting) and RFC 9991 (failure reporting). Together they replace RFC 7489 from 2015 and move DMARC from Informational status onto the IETF standards track. It was known during development as DMARCbis.
Do I need to change my DMARC record for RFC 9989?
Nothing breaks if you do not. Existing records remain valid and still begin with v=DMARC1. The worthwhile cleanup is removing the deprecated pct, rf and ri tags, and adding np=reject to close the non-existent-subdomain gap.
Why was the pct tag removed?
Because receivers implemented it inconsistently — in practice only pct=0 and pct=100 behaved predictably, and values in between varied widely between providers. It also created a false sense of completion: a record reading p=reject; pct=10 looks enforced but acts on one message in ten. The binary t flag replaces it.
What does the np tag do?
np sets the DMARC policy for subdomains that do not exist in DNS at all, closing a gap that p and sp left open. Spoofers exploited it by using plausible-looking subdomains that were never registered. Since no legitimate mail can come from a subdomain that does not exist, np=reject is low-risk on most domains.
Is there a DMARC2?
No. The specification was rewritten but not versioned — records still start with v=DMARC1, and receivers implementing the new RFCs accept records written under the old one. There is no migration deadline and no forced change.
Does RFC 9989 change the bulk sender requirements?
No. Google, Yahoo and Microsoft set their own requirements independently of the RFC, and those are unchanged: a published DMARC record at a minimum of p=none, with SPF and DKIM configured and at least one aligned. The standards-track promotion gives auditors a formal document to cite but creates no new obligations.