DMARCbis (RFC 9989): what changed and what to do

DMARCbis is the standards-track rewrite of DMARC, published as RFC 9989 to replace the original informational spec, RFC 7489. For most domain owners it changes very little day to day — your existing v=DMARC1; p=... record keeps working unchanged. It adds four things: an np tag for non-existent subdomains, a t= testing mode that replaces pct, a DNS tree walk in place of the Public Suffix List, and separate documents for reporting (RFC 9990 aggregate, RFC 9991 failure).

If you already publish a DMARC record and it reaches an enforcing policy (p=quarantine or p=reject), DMARCbis does not require you to change anything. Read on for the cases where it does.

What DMARCbis is

DMARC — Domain-based Message Authentication, Reporting, and Conformance — lets a domain owner tell receiving mail servers what to do with a message that fails SPF and DKIM alignment: monitor it (p=none), quarantine it, or reject it. The original 2015 specification, RFC 7489, was Informational — widely deployed but never a formal internet standard.

DMARCbis (RFC 9989) is the Standards Track successor. It folds in a decade of operational experience, closes a subdomain spoofing gap, retires a tag that never worked the way people expected (pct), and changes how receivers locate the organizational domain. The tag names and record format are deliberately close to RFC 7489, so migration is mostly a matter of understanding a few additions.

What changed from RFC 7489

Three things matter to a domain owner: the new tags, the deprecated tag, and the organizational-domain lookup.

New tags: np, psd, t

• np — policy for non-existent subdomains: names that do not exist in DNS at all — the query returns NXDOMAIN, per RFC 8020. RFC 7489 had only sp, which covers subdomains that do exist. Attackers exploited the gap by forging mail from invented subdomains like billing.marketing.example.com. np=reject shuts that down without touching your real subdomains. Values are the same as p: none, quarantine, or reject.
• psd — declares that the domain is a public suffix domain (a registry-level name such as a country-code or generic TLD operator). Values are y, n, or u (unknown). This is for registry and registrar operators publishing policy at the suffix level; ordinary domains leave it out.
• t — testing mode, t=y or t=n. t=y asks receivers to apply your policy one level below the one you declared — p=reject is treated as quarantine, p=quarantine as none — giving you a clean way to stage a rollout. It replaces pct as the gradual-deployment mechanism.

Removed: pct

pct (percentage) told receivers to apply your policy to only a fraction of mail — pct=25 meant "quarantine or reject 25% of failing messages." In practice it was inconsistently implemented and easy to misread. DMARCbis removes pct: receivers will apply your policy to all mail regardless of the value. If you relied on pct to ease into enforcement, switch to t=y (test without enforcing) instead. A record that still carries pct is not invalid — the tag is simply ignored.

The tag table at a glance

Tag	Status in DMARCbis	Meaning
p	unchanged	Policy for the domain: none, quarantine, reject
sp	unchanged	Policy for existing subdomains
np	new	Policy for non-existent subdomains
psd	new	Declares a public suffix domain (y/n/u)
t	new	Testing mode (y/n) — replaces pct
pct	removed	Ignored; policy now applies to all mail
adkim / aspf	unchanged	DKIM / SPF alignment mode (r relaxed, s strict)
rua	unchanged	Where to send aggregate reports
ruf	unchanged	Where to send failure reports (rarely honored)
fo	unchanged	Failure-report options
rf / ri	removed	Failure-report format and interval — dropped by RFC 9989

This table matches the parser behind our DMARC record checker — paste your record in to see these tags validated.

From Public Suffix List to a tree walk

To decide whether two addresses are "aligned," a receiver has to find the organizational domain — the registrable name under which subdomains sit. RFC 7489 did this by consulting the Public Suffix List (PSL), a hand-maintained file. DMARCbis replaces that with a DNS tree walk: the receiver queries for a DMARC record starting at the domain and walking up label by label until it finds one (bounded at 8 DNS queries). For you: policy at your organizational domain now reaches subdomains through DNS itself. The psd tag lets suffix operators participate in the walk correctly.

What most domains need to do

For most domains: nothing urgent. Your RFC 7489 record is still valid under DMARCbis. When you next revise it, consider two small improvements:

1. Add np. If your policy is p=reject, add np=reject so forged mail from non-existent subdomains is rejected too. This is the single highest-value DMARCbis addition for a typical domain.
2. Retire pct for t. If you are still ramping up and using pct, drop it. To stage enforcement, publish your target policy with t=y — receivers apply the policy one level below it while you watch aggregate reports — then remove t (or set t=n) to go live.

A modern DMARCbis record for a domain that has finished its rollout looks like this:

v=DMARC1; p=reject; np=reject; adkim=s; aspf=s; rua=mailto:[email protected]

Do not jump straight to p=reject without evidence that your legitimate mail is aligned — a premature reject silently drops real messages. Reach an enforcing policy only after aggregate reports confirm every sending source passes SPF or DKIM alignment. That alignment check is exactly what a full domain scan measures.

The reporting split (RFC 9990 and RFC 9991)

DMARCbis keeps the protocol and the report formats in separate documents — three RFCs in total, published together in May 2026. RFC 9989 defines the DMARC mechanism and the record tags; RFC 9990 defines the aggregate reporting format — the XML reports that land at your rua address; RFC 9991 defines the failure reporting format sent to ruf. Splitting them lets the reporting formats evolve without reopening the core protocol. Nothing in your record changes because of the split: you still publish rua=mailto:... to receive aggregate reports, and those reports are the ground truth for whether you are ready to move up the enforcement ladder.

Common questions

Does DMARCbis break my current DMARC record? No. RFC 7489 records remain valid. The only tag whose behavior changed is pct, which is now ignored rather than applied.

Do I have to add np? No. Add it once you reach an enforcing policy — it closes a real spoofing gap at no risk to existing subdomains.

Is pct an error now? No. A record with pct still parses; receivers just apply your policy to all mail instead of a fraction.

What about SPF's 10-lookup limit? DMARCbis does not touch SPF. If your SPF record is near or over the limit, use the SPF lookup counter — an over-limit SPF record fails alignment and undermines DMARC.