If you run a domain that sends email, you may have seen a headline this summer that "DMARC changed." It did. In May 2026 the IETF published DMARCbis, the long-promised revision of DMARC, as three new RFCs. Before anything else, here is the part that matters: your existing DMARC record still works. Nothing you published last year breaks today. Most of the change is in how receiving mail servers evaluate your domain, plus a cleanup of a few tags that were confusing or that almost nobody honored.
That said, the new spec closes a real spoofing hole and gives you cleaner tools for rolling out enforcement. It is worth twenty minutes to understand what moved, because a couple of the additions are worth adopting on purpose.
What actually shipped
For a decade, DMARC lived in a single document, RFC 7489, published in 2015. That document was classified Informational, which in IETF terms means it wrote down something the industry had already agreed to do rather than a formal standard. DMARCbis replaces it with three documents, and all of them are on the Standards Track:
RFC 9989 formally obsoletes RFC 7489, and it also folds in the older public-suffix experiment, RFC 9091. The move from Informational to Standards Track is not cosmetic. It is the first time DMARC has been a real internet standard, and it reflects how central the protocol became to inbox security over the last ten years. This was not rushed, either. The working group started the revision in late 2020 and went through 41 drafts before the RFCs came out, so the version you are reading about is heavily reviewed.
The biggest change: how receivers find your organizational domain
The single most significant update is invisible in your DNS record but changes how every receiver treats you. It is about finding your organizational domain, the boundary between "the part you own" and "the public registry above you."
Old DMARC solved this with the Public Suffix List, a community-maintained file that every validator had to download and trust to know where a domain truly begins. That worked, but different implementations shipped different copies of the list, refreshed on different schedules, so two receivers could disagree about your boundary.
DMARCbis replaces the list with an algorithm it calls the DNS tree walk (RFC 9989, section 4.10). A receiver starts at the domain in your From address, queries _dmarc there, then removes the leftmost label and asks again, climbing the tree until it finds the record that marks your boundary. To stop a hostile domain with hundreds of labels from turning one message into hundreds of lookups, the walk is capped at eight DNS queries. The practical upshot is that your boundary is now decided by DNS itself, which is more predictable, and a domain owner or registry can declare it directly with the new psd tag instead of waiting to be listed in an external file. For almost everyone reading this, the tree walk needs no action on your part.
The tag changes, in plain terms
Here is the quick reference, then the ones worth explaining.
| Tag | Status in DMARCbis | What it means |
|---|---|---|
pct |
Removed | The percentage rollout knob is gone |
t |
New | Test mode, the sanctioned way to stage enforcement |
np |
New | Policy for subdomains that do not exist |
psd |
New | Declares whether a name is a public-suffix domain |
sp |
Clarified | Meaningful only on the organizational-domain record |
rf, ri |
No longer exist | Report format and interval are no longer configurable |
p, rua, ruf, adkim, aspf, fo |
Unchanged | Same syntax and defaults as before |
pct is gone, and t takes its job
In theory, pct let you apply your policy to a fraction of your mail, so pct=50 meant "quarantine half of the failures." In practice the tag was widely ignored, and pct=100 was already the default, so its removal changes nothing for most senders. DMARCbis drops it and adds a cleaner boolean, t (test mode), whose default is n.
Set t=y and you are telling receivers not to enforce your stated policy as written, but to treat failing mail about one level below what your p value says. A record at p=quarantine; t=y behaves like none, and p=reject; t=y behaves like quarantine. That is exactly what you want while you are validating your sending sources, and it is the officially blessed way to stage the classic none to quarantine to reject progression without the guesswork of a percentage.
np closes a spoofing hole you probably have right now
This is the addition most worth adopting. The np tag sets a policy specifically for subdomains that do not exist in DNS at all. Attackers love this gap. They forge mail from a plausible name like billing.yourdomain.com that you never created, precisely because a name with no records of its own inherits no policy of its own.
With np=reject, you tell receivers to reject mail from any non-existent subdomain, and you do it without changing how your real subdomains are handled. The spec defines a clean fallback: np covers non-existent subdomains, sp covers subdomains that do exist, and if neither is present the receiver falls back to your top-level p. A minimal record that shuts the door looks like this:
yourdomain.com TXT "v=DMARC1; p=quarantine; np=reject; rua=mailto:dmarc@yourdomain.com"
psd is for registries, not for you
The psd tag is the counterpart to the tree walk. It lets a name declare its role: psd=y means the name is a public suffix (registries and TLD operators), psd=n means it is an organizational domain and the walk should stop there, and psd=u, the default, means unknown, so use the tree walk. Most senders will never touch it. It exists so the parties who operate suffixes can participate in DMARC directly instead of relying on an entry in an external list.
sp got a clarification
The subdomain policy tag, sp, is now explicitly meaningful only on your organizational-domain record, where it governs your existing subdomains. Publishing it on a subdomain's own record does nothing, which is the behavior most implementations already assumed but the old spec never nailed down.
Reporting moved out, and two knobs vanished
Aggregate and failure reporting were split into their own documents, RFC 9990 and RFC 9991. As part of that cleanup, two tags no longer exist. rf, the report-format selector, is gone because aggregate reports are now fixed as gzip-compressed XML (RFC 9990). ri, the report-interval request, is gone because receivers send on their own schedule. Your rua and ruf addresses work exactly as before, so if you already collect reports, nothing about that pipeline changes.
One security note worth flagging: do not lean on SPF alone
Buried in the security guidance of RFC 9989 is a line that deserves a callout. A domain that publishes p=reject must not rely on SPF alone to earn a DMARC pass, and must sign its mail with DKIM. The reasoning is practical: SPF breaks the moment a message is forwarded, while a DKIM signature survives forwarding. Worth noting, an early proposal to drop SPF from DMARC entirely did not make it into the standard, so SPF alignment is still here. The takeaway is to make sure DKIM is signing and aligned before you move to reject, not to treat SPF as your safety net.
What you should actually do
Short version, in order:
- Nothing is on fire. Your current record is still valid. There is no forced migration and no deadline.
- You can drop
pctif you have it. If it waspct=100, behavior is unchanged. If it was a fractional value you used to phase in enforcement, stop doing that withpctand uset=yto test instead, then raisep. - Add
np=rejectif you send mail. It kills spoofing from subdomains you never provisioned and does not touch your real ones. This is the highest-value change on the list. - Confirm DKIM is signing and aligned, especially before you go to
p=reject. Do not depend on SPF by itself. - Keep reading your
ruareports. The standard does not require them, but operationally they are still the single best way to see who is sending as you before you tighten enforcement. - Do not rush to reject. Monitor, confirm every legitimate source is authenticated and aligned, then enforce. The spec itself warns that
p=rejectcan break indirect flows like mailing lists, and that domains whose users post to lists should not publish reject.
One thing to keep separate in your head: the Google and Yahoo bulk-sender requirements from February 2024, the ones that pushed everyone sending more than roughly 5,000 messages a day to publish a DMARC record, referenced the old DMARC and predate these RFCs by two years. They are provider policy, not the IETF standard, and DMARCbis did not change them. They are why so many domains scrambled to publish p=none in the first place, but they are a different lever than the spec.
Check your own domain in about thirty seconds
The DNS + Email Auth Audit on this site now reads the DMARCbis record shape. It parses the new np, psd, t, and sp tags, flags a leftover pct so you can clean it up, warns when a t=y record is quietly not enforcing, and recommends np=reject on domains that send. Run your apex domain through it, and if you need to build a fresh record from scratch, the DNS Records Generator will assemble the syntax for you.
If email is part of how you launch or sell, and you want the wider picture of the infrastructure that keeps your mail out of the spam folder, my book The $97 Launch walks through the deliverability stack in the same plain terms as this post.
Related reading
- DNS + Email Auth, Why Broken DMARC Quietly Kills Newsletter Deliverability, the companion piece to the audit tool.
- Locking Down a Parked Domain So Nobody Can Spoof It, where
np=rejectandsp=rejectearn their keep. - Email Infrastructure for a Small Business, Without the Enterprise Bill, the SPF, DKIM, and DMARC baseline in full.
- BIMI and MTA-STS Across Two Hosts, the next two records to add once DMARC is at enforcement.
Fact-check notes and sources
- IETF, RFC 9989: Domain-based Message Authentication, Reporting, and Conformance (DMARC), Proposed Standard, May 2026. The core protocol: tree walk (section 4.10), the
t,np,psd, andsptag definitions (section 4.7), and the removal ofpct. - IETF, RFC 9990: DMARC Aggregate Reporting, May 2026. Aggregate reports fixed as gzip-compressed XML.
- IETF, RFC 9991: DMARC Failure Reporting, May 2026.
- IETF, RFC 7489: DMARC, Informational, March 2015, now obsoleted by RFCs 9989, 9990, and 9991.
- IETF, RFC 9091: Experimental DMARC Extension for PSDs, obsoleted by RFC 9989.
- IETF, DMARCbis draft history and milestones, showing the 2020 start, 41 revisions, and 2025 approval.
- Google, Email sender guidelines, the February 2024 bulk-sender requirements, provider policy separate from the IETF standard.
This post is informational, not legal or security-consulting advice. Mentions of third-party products and services are nominative fair use. No affiliation is implied.
