RFC 9989: The New DMARC Standard, Explained

DMARC Just Became a Real Standard

For eleven years, DMARC ran the internet’s email authentication on an Informational RFC.

RFC 7489, published in March 2015, was never the product of an IETF working group. It was submitted by an industry consortium and classified as Informational — useful, widely adopted, but not an official Internet Standard.

That changed in May 2026.

RFC 9989 is an Internet Standards Track document. It obsoletes both RFC 7489 and the experimental RFC 9091 (PSD DMARC). Alongside two companion documents — RFC 9990 (aggregate reporting) and RFC 9991 (failure reporting) — it replaces the single 2015 specification with a modern, modular standard.

This isn’t a cosmetic change. RFC 9989 alters how DMARC policy is discovered, removes a widely-used tag, adds new ones, and clarifies behavior that mail receivers had been implementing inconsistently for a decade.

If you manage DMARC for a domain, here’s what actually changed.

The Big One: The DNS Tree Walk Replaces the Public Suffix List

This is the most significant change in RFC 9989.

To understand why it matters, you need to understand the problem DMARC has always had with the Organizational Domain.

When mail arrives, a receiver needs to find the DMARC policy for the sending domain. If the exact domain — say, news.marketing.example.com — has no DMARC record, the receiver needs to “climb the tree” to find one. It also needs to determine the Organizational Domain to evaluate whether SPF and DKIM are aligned with the sender.

Under RFC 7489, that climb relied on the Public Suffix List (PSL) — a community-maintained list of domain suffixes like .com, .co.uk, and .org. The receiver consulted the list to know where the “registrable” domain boundary was.

The PSL worked, but it had real problems. RFC 7489 never mandated which PSL to use. It didn’t specify how often receivers should refresh it. Two receivers using different versions of the list could reach different conclusions about the same domain. RFC 7489 itself acknowledged this and openly invited a better method.

RFC 9989 delivers that method: the DNS Tree Walk.

Instead of consulting a static list, a mail receiver now performs a series of live DNS queries, walking up the domain hierarchy and looking for DMARC records at each level.

Here’s the process in plain terms. Starting from the sending domain, the receiver queries _dmarc at each parent domain, moving up one label at a time. It collects the DMARC records it finds. The Organizational Domain is determined from where those records appear and what psd tags they contain.

To prevent abuse — an attacker could otherwise send mail from a domain with hundreds of labels to force hundreds of DNS lookups — the Tree Walk is capped at 8 queries. Domains with more than eight labels get shortcut handling.

For a domain like a.mail.example.com, the walk queries:

_dmarc.a.mail.example.com
_dmarc.mail.example.com
_dmarc.example.com
_dmarc.com

The practical result: Organizational Domain determination is now dynamic, consistent, and doesn’t depend on every mail receiver in the world agreeing on the same external list.

One consequence worth noting: because the Tree Walk and the PSL can occasionally disagree, organizations that want certainty should publish explicit DMARC records for every domain they send from and consider strict alignment. That removes the guesswork entirely.

The pct Tag Is Gone

If you’ve ever rolled out DMARC enforcement gradually, you’ve used the pct tag.

pct let you apply your policy to a percentage of failing messages. p=quarantine; pct=25 meant “quarantine 25% of failures.” It was the standard tool for cautious, staged rollouts.

RFC 9989 removes it.

The reason is bluntly operational. Mail receivers implemented pct inconsistently. RFC 9989 states that the tag “was usually not accurately applied, unless the value specified was either 0 or 100.” Partial percentages behaved differently across providers. Only the extremes — 0 and 100 — worked reliably.

In its place, RFC 9989 introduces the t tag — short for “testing.”

t has two values:

• t=y — testing mode. The receiver is asked not to apply the stated policy, but instead to apply special handling (such as From: header rewriting). A p=reject; t=y record behaves roughly like p=quarantine. A p=quarantine; t=y record behaves roughly like p=none.
• t=n — the default. Apply the policy as stated.

Think of t=y as the new pct=0 and t=n as the new pct=100. The middle ground is gone.

What does this mean for staged rollouts? The progression is now policy-level rather than percentage-level. You move p=none → p=quarantine; t=y → p=quarantine → p=reject; t=y → p=reject, monitoring aggregate reports at each step. You no longer dial a percentage; you step through policy levels with a testing buffer at each one.

Existing records that still contain pct aren’t rejected — the tag is simply ignored. But it should be considered deprecated. The IANA registry now lists pct as “historic.”

Two New Tags: np and psd

RFC 9989 adds two tags, both related to handling domains beyond your main sending domain.

np — policy for non-existent subdomains

The np tag sets the Domain Owner Assessment Policy for non-existent subdomains of your organizational domain.

This matters for a common attack. Spoofers love to invent subdomains — accounts-secure.yourbank.com, login.yourbank.com — that you never registered. Those subdomains don’t exist in your DNS, but without an explicit policy, their handling fell back to your main policy.

np=reject lets you say: any mail from a subdomain that doesn’t exist should be rejected outright. It’s a clean way to shut down a whole category of spoofing. The np tag was originally introduced in the experimental RFC 9091; RFC 9989 brings it into the core standard.

psd — declaring a Public Suffix Domain

The psd tag flags whether a domain is a Public Suffix Domain — a domain like .com, .bank, or .gov.uk that hosts independently owned subdomains.

It has three values:

• psd=y — this domain is a Public Suffix Domain. Public Suffix Operators publish this.
• psd=n — this domain is not a PSD; it is the Organizational Domain for itself and its subdomains.
• psd=u — the default (“unknown”). Use the Tree Walk to figure it out.

Most domain owners never touch psd. It matters mainly for registries and for large, decentralized organizations that want a specific node in their namespace treated as an Organizational Domain.

Terminology Got Cleaned Up

RFC 9989 introduces precise terms for concepts the community had been describing loosely:

Domain Owner Assessment Policy — the formal name for what your p, sp, and np tags express.

Enforcement — a defined state: any policy other than p=none.

Monitoring Mode — the defined state of being at p=none while receiving aggregate reports.

Public Suffix Domain (PSD) and Public Suffix Operator (PSO) — formal definitions for registry-level domains and their operators.

“Report Receiver” was also renamed to Report Consumer, to better describe systems and organizations that ingest DMARC reports.

These aren’t just editorial. Having precise, standardized terms makes compliance frameworks, vendor documentation, and audits less ambiguous.

Reporting Moved Into Its Own Documents

RFC 7489 packed the protocol and the reporting formats into one document. RFC 9989 splits them:

• RFC 9989 — the core DMARC protocol (this document)
• RFC 9990 — DMARC aggregate reporting
• RFC 9991 — DMARC failure reporting

The modular structure means the reporting formats can evolve independently of the core protocol. The aggregate report XML schema, for example, picked up an extensions framework in RFC 9990 without requiring a new version of the core spec.

One small reporting change worth flagging: the ability to specify a maximum report size in the DMARC reporting URI has been removed.

Mail Receivers Must Not Reject on p=reject Alone

This is a clarification rather than a new rule, but RFC 9989 states it far more forcefully than RFC 7489 did.

A mail receiver MUST NOT reject a message solely because the sending domain publishes p=reject.

Why? Indirect mail flows. When mail passes through a mailing list or an “alumni forwarder,” SPF usually breaks and DKIM signatures sometimes break. A message that’s perfectly legitimate can fail DMARC because of how it was relayed, not because it’s fraudulent.

If receivers blindly rejected on p=reject, mailing lists across the internet would break — and recipients would get auto-unsubscribed when the list software interpreted the rejections as dead addresses.

RFC 9989’s instruction: receivers must apply additional analysis — sending patterns, content filtering, reputation. In the absence of other knowledge, mail failing a p=reject policy should be treated as if the policy were p=quarantine.

There’s a flip side for domain owners. RFC 9989 is explicit that domains with general users who post to mailing lists SHOULD NOT publish p=reject. And any domain moving to p=reject MUST NOT rely solely on SPF — it must apply valid DKIM signatures, because DKIM survives relaying while SPF does not.

What This Means for You

If you manage DMARC for a domain, here’s the short version.

Your existing record still works. The core format is unchanged. You don’t need to scramble.

Stop using pct. It’s deprecated. Plan your next enforcement rollout around policy levels and the t tag instead of percentages.

Consider adding np. If you’ve fully inventoried your sending sources, np=reject closes off non-existent-subdomain spoofing cheaply.

Publish explicit records for every sending domain. The Tree Walk is consistent, but explicit records at each Author Domain remove all ambiguity about which policy and Organizational Domain apply.

If you send from a domain whose users post to mailing lists, think carefully before p=reject. RFC 9989 actively discourages it for general-purpose mail.

If you’re at p=reject, make sure DKIM is solid. SPF alone is not enough — relaying breaks it.

DMARC becoming a full Internet Standard is a milestone. It signals that email authentication is now permanent infrastructure, not an experiment. The changes in RFC 9989 mostly make a decade-old protocol more consistent and more honest about how it actually behaves in the wild.

Stay Ahead of the Standard

Verkh tracks email authentication standards so you don’t have to. The platform handles policy discovery, Organizational Domain determination, and enforcement progression — and stays current as the specifications evolve.

Start monitoring your domain free at verkh.io. See where your DMARC configuration stands against the current standard, and get a guided path to enforcement.