DMARC RFC 9989: What Changed From RFC 7489 (2026)

DMARC changed in May 2026. RFC 9989 replaced RFC 7489, the 2015 document that nearly every DMARC guide still describes, and DMARC moved from Informational to a Proposed Standard on the IETF standards track.

What changed in DMARC RFC 9989, in one line: the pct tag is gone, the Public Suffix List is no longer how a receiver works out your organizational domain, and three tags joined the record format.

And the part you came for: your existing DMARC record still works. The version string is still v=DMARC1. There is no DMARC2. If you have not touched your record in years, it keeps doing what it did.

Do I need to update my DMARC record for RFC 9989?#

For most publishers, no, and not urgently. RFC 9989 kept the record syntax stable on purpose: the version tag is unchanged, and the record-format rules state that unknown tags MUST be ignored. A record written against RFC 7489 parses cleanly under RFC 9989.

The one thing worth checking today is whether your record contains pct. It is no longer part of the standard, so receivers following RFC 9989 ignore it. Ignored is not the same as harmless.

Everything else is housekeeping. Remove pct the next time you edit the record, and decide whether the new tags are useful. They are all optional.

• Running p=reject; pct=0, or any pct below 100 as a deliberate throttle: act now, before receivers take the policy literally.
• Using rf= or ri=: neither appears in the RFC 9989 record format. Treat them as inert.
• Operating a public suffix, such as a registry or a host handing out customer subdomains: the new psd tag is for you.
• Everyone else: no action required. Tidy up on your next edit.

What is RFC 9989, and what did it replace?#

RFC 9989 is titled Domain-based Message Authentication, Reporting, and Conformance (DMARC). Published in May 2026 as a Proposed Standard, it obsoletes RFC 7489, the original 2015 specification, and RFC 9091, the experimental extension that let public suffix operators publish DMARC policy.

It did not arrive alone. The working group split DMARC into three documents, which matters when you go looking for a detail and cannot find it in the base spec.

• RFC 9989: the core protocol. The record, the tags, alignment, policy discovery.
• RFC 9990: aggregate reporting, the daily XML you receive via rua.
• RFC 9991: failure reporting, the per-message samples via ruf. It also updates RFC 6591.

RFC 7489 vs RFC 9989: the changes at a glance#

Read the table as the summary and the rest of the post as the detail. The left column is what most published guidance still describes.

The pct tag is removed, and pct=0 is the trap#

pct let you apply your policy to only a fraction of failing mail: pct=25 meant quarantine a quarter of the failures. It was how most people ramped into enforcement.

It is not in RFC 9989. The core record format defines eleven tags: v, p, sp, np, psd, adkim, aspf, fo, rua, ruf and t. pct is not among them, and the RFC devotes an appendix, A.6, to the removal.

Because unknown tags must be ignored, a pct still sitting in a live record does nothing rather than invalidating it. If yours says pct=100, that is a no-op: 100 was always the default.

pct=0 is a different story. v=DMARC1; p=reject; pct=0 was a widely used trick: publish an enforcement policy, apply it to nothing, keep the reports flowing. Under RFC 9989 the pct is ignored and what remains is p=reject.

What replaces pct is not a like-for-like swap. The new t tag is a yes/no test-mode flag: t=y asks the receiver not to apply the policy declared in p, sp or np, and to apply its own special handling instead. The default is n.

There is no percentage dial any more. The ladder is coarser: monitor at p=none, publish your intended policy with t=y, then drop the t tag when the reports are clean.

The Public Suffix List is out, a bounded DNS tree walk is in#

To evaluate DMARC, a receiver has to work out your organizational domain, the registered name a subdomain inherits policy from. Under RFC 7489 that meant consulting the Public Suffix List, a community-maintained file of every suffix under which people can register names.

The PSL worked, but it is a list: someone has to add your suffix, ship it, and wait for implementations to pick it up. RFC 9989 replaces it with what the document itself calls the DNS Tree Walk.

The walk starts at the domain in question and climbs toward the root, querying for a DMARC record at each level and discarding anything that does not begin with a valid version tag.

Bounded is the load-bearing word. Walking an arbitrarily long name would invite denial-of-service, so the RFC caps it: an author domain with more than eight labels does not produce more than eight DNS queries.

For an ordinary domain like mail.example.com, nothing you can observe changes. It matters for deep subdomain trees, for public suffix operators, and for anyone whose suffix the PSL never listed.

What the psd and np tags do#

psd declares whether a domain is a public suffix domain, a name under which other organizations register their own. y says it is a PSD, n says it is not a PSD but is the organizational domain for itself and its subdomains, and u is the default, asserting neither.

If you run an ordinary company domain, leave psd alone. The default is correct, and setting it incorrectly interferes with the tree walk.

np sets policy for subdomains that do not exist. Attackers like those precisely because nobody watches them: billing.yourcompany.com reads as plausible in a From line whether or not the zone exists.

It is the one new tag most domains should consider deliberately. Where every real subdomain already authenticates and aligns, np=reject is low-risk and closes a genuine gap. sp still governs the subdomains that do exist.

Why almost every DMARC article you find is out of date#

RFC 7489 stood for a decade. Ten years of blog posts, vendor documentation, DNS-host help articles and record generators were written against it, and they still rank.

Microsoft Learn's own DMARC documentation still describes the pct tag and cites RFC 7489 (checked July 2026). If Microsoft has not updated, assume your DNS provider's help page and your favorite DMARC checker have not either.

None of that makes the older material useless. Alignment, the three policies and the rollout discipline survive intact, and our explainer on what DMARC is and how it ties SPF and DKIM together still holds. It makes them incomplete.

What to do now#

None of this needs an emergency change window. The only urgent item is pct=0, and only because receivers update on their own timetable rather than a shared date.

1. 1

   Read your current record

   Look up the TXT record at _dmarc.yourdomain.com and read it as plain text. You are scanning for three tags the core spec no longer defines: pct, rf and ri.

2. 2

   Deal with pct first

   pct=100 and no pct behave identically, so that is a clean-up. Any other value was doing real work that is about to stop, and pct=0 flips from no enforcement to full enforcement.

3. 3

   Use t=y if you need a not-yet-enforcing signal

   Publishing your target policy with t=y asks receivers not to apply it yet. It is the closest thing RFC 9989 offers to a ramp.

4. 4

   Consider np

   If every real subdomain that sends mail authenticates and aligns, np=reject costs you nothing and closes the non-existent-subdomain gap.

5. 5

   Leave psd alone unless you are a PSD

   The u default is right for ordinary domains. Set psd only if you operate a suffix that other people register names under.

6. 6

   Re-check your tooling

   Generators, validators and monitoring platforms adopt new specifications at different speeds. A checker that still flags a missing pct tag is telling you about the tool, not your record.

What RFC 9989 did not change#

The mechanism you already understand still works the way you understand it.

• Alignment is unchanged: SPF or DKIM must pass, and the authenticated domain must match the From domain, relaxed or strict via aspf and adkim.
• The three policies are unchanged: none, quarantine and reject mean what they meant.
• rua and ruf still point reports where you want them. The formats moved to RFC 9990 and RFC 9991, they did not disappear.
• The rollout discipline is unchanged: monitor, inventory your senders, fix the legitimate ones, then enforce.
• The version string is still v=DMARC1, and a record whose first tag is not v=DMARC1 is ignored entirely.

Where an email client fits into this#

DMARC is a sending-side control. You publish it on your domain and receivers act on it, so nothing in this post is something an email client configures for you. AI Emaily is not a DMARC monitoring service; if you want aggregate reports turned into dashboards, use a tool built for that.

What a client owns is the receiving side, where authentication results are one signal among several about how much to trust a message. AI Emaily treats incoming mail as untrusted input by design: it triages and drafts, you approve before anything sends, and every action is undoable and audited.

The bottom line#

RFC 9989 is a real change to the specification and a small change to most people's DNS. The standard grew up from Informational to Proposed Standard, shed a tag that never worked as advertised, and swapped a hand-maintained list for a bounded DNS lookup.

Your record almost certainly still works. Remove pct, look seriously at np, ignore psd unless you run a public suffix, and be skeptical of any DMARC guidance that does not mention RFC 9989 at all.