RFC 9989 Explained: The Core of the New DMARC Standard

Introduction

RFC 9989, published by the IETF in May 2026, is the core of the new DMARC standard. It is one of three documents — alongside RFC 9990 for aggregate reporting and RFC 9991 for failure reporting — that together replace the original 2015 specification, RFC 7489, and move DMARC onto the IETF Standards Track. If RFC 9990 and RFC 9991 describe what receivers report back, RFC 9989 describes the thing being reported on: how a receiver reads a policy and decides what to do with a message.

For MSPs, this is the document your platform, your parsers and your advice ultimately depend on. This article walks through what RFC 9989 keeps, what it clarifies and what it changes — technical but readable, aimed at the person who has to make the rollout work rather than the person editing the specification. For the bigger-picture summary of all three RFCs, start with the pillar: DMARC has changed.

The core mechanic has not changed

The most important sentence in this article is also the most reassuring one: DMARC still passes when an aligned SPF check or an aligned DKIM check passes. One aligned pass is sufficient. Alignment still means the domain that authenticated matches the domain in the visible From header, in either relaxed or strict mode. Everything you know about designing a rollout around SPF alignment, DKIM alignment and the From header carries forward intact.

That continuity is deliberate. DMARCbis is a refinement of a widely deployed protocol, not a redesign. The authors' priority was to describe existing behavior precisely enough that independent implementations agree, and to remove ambiguity that led receivers to behave differently from one another. So if you were worried that the new standard would invalidate a decade of rollout practice, it does not.

Clearer domain discovery and policy handling

Where RFC 9989 earns its keep is precision. The original specification left room for interpretation in how a receiver discovers the organizational domain for a given From address and how it selects the applicable policy — including how subdomain policy inheritance works. Different receivers filled those gaps differently, which is one reason two providers could reach different conclusions about the same message.

RFC 9989 describes organizational-domain discovery and policy selection more rigorously. For an MSP this is quietly valuable: the more precisely the standard is written, the more consistent the behavior you will see across Google, Microsoft, Yahoo and the long tail of smaller receivers, and the fewer "why did only this one provider quarantine us" mysteries you will have to explain to a client.

Public Suffix Domain handling moves into the core

Under the old arrangement, handling of Public Suffix Domains — the registry-level names that sit above ordinary organizational domains — lived in a separate experimental document, RFC 9091. DMARCbis obsoletes that document and folds PSD handling directly into the core standard. It also introduces a psd tag so a record can explicitly declare whether the domain is a Public Suffix Domain.

For most commercial MSP clients this is a background detail rather than a daily concern, because most clients operate ordinary organizational domains. It matters when you work with clients who sit at or near a public suffix boundary, and it matters that the behavior is now standardized rather than experimental. The organizational-domain discovery model and PSD mechanics are covered in depth in DMARCbis, Public Suffix Domains and organizational-domain discovery.

A modernized tag set

RFC 9989 modernizes the DMARC tag vocabulary. Three tags are removed and three are added.

• pct is removed. The percentage tag that let a record apply a policy to only a fraction of mail is gone. Enforcement is now effectively all-or-nothing, with the new t tag expressing test intent rather than a percentage. This is significant enough for staging strategy that it has its own article: pct is going away.
• rf and ri are removed. The report-format and report-interval tags were rarely implemented and widely ignored by receivers, so the standard drops them.
• np is added. It sets policy specifically for non-existent subdomains, closing a spoofing gap around subdomains that were never meant to send mail.
• psd is added. It flags whether a domain is a Public Suffix Domain.
• t is added. It signals test or transitional mode; t=y tells receivers the record is being tested.

The new tags deserve their own read — see the new DMARC tags np, psd and t explained — and the np tag in particular is covered in non-existent subdomains and the DMARC np tag.

A quick worked example

Take a record an MSP might have published years ago: v=DMARC1; p=quarantine; pct=50; rua=mailto:[email protected]; ruf=mailto:[email protected]; rf=afrf; ri=86400. Under DMARCbis, three of those tags are now dead weight. The pct=50 no longer holds the domain at half-enforcement — receivers ignore it, so the record behaves as full p=quarantine, and if that is not what you intended the fix is to choose the policy you actually want. The rf=afrf and ri=86400 tags are simply obsolete and ignored.

A cleaned-up equivalent is shorter and clearer: v=DMARC1; p=quarantine; rua=mailto:[email protected]. If the domain has subdomains that never send mail, this is also the moment to add np=reject, and if you are staging a change you can add t=y to signal that the record is being tested. The record parses under both the old rules and the new ones — you are removing ambiguity, not introducing risk, which is exactly the kind of low-stakes cleanup an MSP can run across a whole fleet in one pass.

What this means for your DMARC tooling

Because RFC 9989 defines record processing, the tooling behind your DMARC service has to keep up with it. A platform or parser that predates DMARCbis may not recognize np, psd or t, and may still present pct as a meaningful control when receivers now ignore it. At minimum, confirm three things: that your platform parses and displays the new tags, that your record generator produces records using the current vocabulary rather than deprecated tags, and that your checker does not flag valid DMARCbis records as errors or silently drop the new tags. A quick DNS lookup on a sample of managed domains will tell you what is actually published today.

Client impact: nothing breaks overnight

Here is the line to keep in front of clients and staff alike. For most clients, nothing breaks overnight — a valid existing record remains valid, and there is no forced migration. But MSPs should make sure their DMARC platform, parsers and advice are aligned with the new standard, because the details that changed — an ignored pct, three new tags, PSD handling in the core, and the enforcement work that still demands care even after the standard matured — are exactly the details a managed service is supposed to get right.

The enforcement nuance in particular is worth its own read. Reaching p=reject safely still requires the same discipline it always did: name every legitimate sender, confirm each has an aligned SPF or DKIM pass, and only then advance the policy. The standard maturing did not remove that care, as covered in DMARC enforcement after RFC 9989: p=reject still requires care.

Related articles

• DMARC has changed: RFC 9989, 9990 and 9991 for MSPs
• The new DMARC tags: np, psd and t explained
• DMARCbis, Public Suffix Domains and organizational-domain discovery
• DMARC enforcement after RFC 9989: p=reject still requires care
• pct is going away: rethinking partial DMARC enforcement

Tools mentioned

• DMARC checker — verify a record parses cleanly under the new standard.
• DMARC record generator — build records with np, psd and t where appropriate.
• DNS lookup — read the published TXT record for any domain.
• SPF analyzer and DKIM validator — confirm the aligned SPF or DKIM pass that DMARC still depends on.

Author: DMARC AI editorial team Last updated: August 2026