Back to Learning Center

What is DMARCbis? DMARC's new RFC 9989 standard

By Samuel ChenardJuly 4, 20267 min read
What is DMARCbis? DMARC's new RFC 9989 standard

DMARCbis is the long-awaited revision of DMARC, and it is no longer a draft. In May 2026 the IETF published it as three documents — RFC 9989 (the core protocol), RFC 9990 (aggregate reporting), and RFC 9991 (failure reporting) — which together obsolete the original RFC 7489 from 2015. The headline: your existing DMARC records still work unchanged, but there are new tags worth adopting and one long-standing spoofing gap that is finally closed.

Quick Takeaways

  • DMARCbis is published as RFC 9989, 9990, and 9991 (May 2026); together they obsolete RFC 7489 and RFC 9091.
  • DMARC is now a Proposed Standard on the IETF Standards Track — RFC 7489 was only Informational.
  • Every record still starts with v=DMARC1. There is no "DMARC2" and nothing you must re-do today.
  • New np tag sets a policy for non-existent subdomains, closing a common spoofing route.
  • The pct, rf, and ri tags were retired; a simpler t test flag replaces pct.
  • A DNS "Tree Walk" now finds your organizational domain instead of the Public Suffix List.

What actually changed when DMARCbis became a standard?

The biggest change is status, not syntax. For a decade DMARC lived in RFC 7489, an Informational document — a widely used reference that was never formally standardized. RFC 9989 moves DMARC onto the IETF Standards Track as a Proposed Standard, per the RFC 9989 record on the IETF datatracker. Practically, that means one agreed specification that mailbox providers, auditors, and regulators can all point to.

The specification was also split into three parts so each can evolve on its own: the core policy-and-authentication logic in RFC 9989, aggregate ("rua") reporting in RFC 9990, and failure ("ruf") reporting in RFC 9991. If you already understand how a DMARC record protects your domain, none of the core mechanics — SPF or DKIM must pass and align with the From domain — have changed.

Do I need to change my DMARC record right now?

No. DMARCbis is deliberately backward compatible. Records still begin with v=DMARC1, and the familiar tags — p, sp, rua, ruf, adkim, aspf, and fo — keep their RFC 7489 meaning. A receiver running the old rules can safely ignore the new tags, and a DMARCbis-aware receiver reads your old record without complaint.

So there is no fire drill. The upgrade is an opportunity, not an emergency: adopt the new np tag when you are ready, and drop the retired tags the next time you touch your record. If you want to confirm your current record still parses cleanly, run it through the DMARC checker before and after any edit.

What is the new np tag and why does it matter?

The np tag sets the policy for non-existent subdomains — subdomains that return NXDOMAIN in DNS because they were never created. RFC 9989 defines it in Section 4.7 as the domain owner's handling preference for mail claiming to come from a subdomain that does not exist.

This closes a real gap. Attackers love inventing subdomains like billing.yourdomain.com or payroll.yourdomain.com that you never set up, because those made-up names can slip past a policy tuned only for your real subdomains. With np=reject, mail from any non-existent subdomain is rejected outright, no matter what your subdomain policy says. The fallback order is clear: if np is absent, receivers use sp; if sp is absent too, they fall back to p. A modern, locked-down record looks like this:

`` v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:dmarc@yourdomain.com `

Because lookalike and made-up subdomains are a favorite phishing trick, pairing np=reject with an enforced policy is one of the highest-value edits you can make. It complements — but does not replace — watching your aggregate DMARC reports for sources you did not expect.

Which tags were removed or replaced?

Three RFC 7489 tags are gone in DMARCbis, and one new testing flag takes their place:

  • pct (removed): the "apply policy to X% of mail" tag was implemented inconsistently across receivers, so it was retired.
  • t (new, replaces pct): a plain test flag. t=y means the policy is in test mode and should not be enforced; t=n (the default) means full enforcement. It expresses intent far more clearly than pct=0 ever did.
  • rf and ri (removed): the failure-report format and aggregate-report interval tags were dropped from the core spec.
  • psd (new): flags a Public Suffix Domain operator (think registries like .bank). Values are y, n, or u (unknown), and u is the default.
If your record still carries pct=100, it is harmless but obsolete — receivers now assume full enforcement unless you set t=y. When you next revise the record, drop pct and, if you are still rolling out, use t=y instead. You can sanity-check the syntax any time with the DMARC record checker and confirm the underlying DKIM and SPF records still pass.

How does the DNS "Tree Walk" replace the Public Suffix List?

Old DMARC leaned on the Public Suffix List (PSL) — a community-maintained file — to work out where a domain "organizationally" ends (for example, that mail.gov.uk belongs to gov.uk, not uk). The PSL was awkward: it was external, could lag reality, and did not always match how domains are really structured.

DMARCbis replaces that with a DNS Tree Walk: receivers query DNS upward from the sending name to discover the organizational domain and its DMARC policy directly. It removes a fragile external dependency and handles complex or deeply nested domain trees more predictably. For most senders this is invisible — it simply makes policy discovery more reliable, especially for organizations with layered subdomains.

Common issues when adopting DMARCbis tags

My record has both pct and t — is that a problem?

It won't break anything, but it is redundant. pct is retired, so DMARCbis receivers ignore it while legacy receivers still read it. Keeping both sends mixed signals. The clean fix: remove pct entirely and express rollout state with t=y (testing) or nothing at all (enforcing). Re-check the record with the DMARC checker after editing.

I added np=reject and legitimate mail started failing

That usually means the mail was coming from a subdomain you do use but never declared in DNS. np only applies to subdomains that return NXDOMAIN — so if a real sending subdomain has no DNS records of its own, receivers may treat it as non-existent. Create at least a minimal DNS presence for any subdomain you actually send from, then confirm it resolves with a DNS lookup.

Do older receivers understand np and t?

Not all of them yet. Adoption of DMARCbis-aware parsing is rolling out across mailbox providers. Because the tags are additive, a receiver that doesn't recognize np or t simply ignores it and falls back to p/sp — so adding them is safe even before every provider is on board.

My reports look different after the split — did something break?

The reporting formats moved to RFC 9990 (aggregate) and RFC 9991 (failure), but the XML aggregate report your tools ingest is still the same shape. If a report parser complains, it is almost always a tooling version issue, not a change in what your domain is publishing.

Frequently asked questions

Is DMARCbis the same as "DMARC 2.0"? No. "DMARC2" is not a real thing — records still start with v=DMARC1, and DMARCbis is explicitly backward compatible. The "2.0" framing is marketing, not spec.

Does DMARCbis change how SPF and DKIM work? No. SPF and DKIM are unchanged. DMARCbis only revises how DMARC evaluates and reports on their results. Your existing DKIM setup and SPF record carry over as-is.

Should MSPs update client records now? There is no forced deadline, but adding np=reject to already-enforced domains and retiring pct` are low-risk, high-value cleanups worth scheduling into normal maintenance.

Where can I read the official text? The primary sources are RFC 9989, RFC 9990, and RFC 9991 on the IETF datatracker — always preferable to a summary for exact wording.

Keeping every client domain aligned with the current standard — enforced policies, the right new tags, and reports that someone actually reads — is exactly the busywork that adds up across a portfolio. Palisade automates that DMARC lifecycle so records stay correct as the spec evolves, and you can baseline any domain in seconds with the Email Security Score tool.

Share this article