TL;DR
- DMARCbis is now official as RFC 9989, 9990, and 9991, published May 2026.
- Your existing v=DMARC1 record keeps working. No rebuild is required.
- Clean up the deprecated tags in your record: pct, rf, and ri.
- The new tags (np, psd, t) are optional and safe to add when you need them.
In May 2026 the IETF published RFC 9989, 9990, and 9991, the first substantive update to the DMARC specification since the original landed in 2015. DMARC is finally a Standards Track protocol instead of an informational one.
If you run cold outreach or manage deliverability for a growing domain, you have probably seen a dozen vendor posts calling this a milestone without saying what to do about it. The compliance-heavy coverage buries the one question that matters to senders.
That question is simple: does your current DMARC record still work, or do you need to rebuild it? Here is the plain-English answer, plus the tags worth cleaning up before your next DNS change.
What just happened with DMARC
The IETF published three documents that together replace the original DMARC specification from 2015. RFC 9989 is the core protocol. RFC 9990 covers aggregate reporting, the daily XML data you get back from mailbox providers. RFC 9991 covers failure reporting. The old single spec, RFC 7489, is now obsolete, along with RFC 9091, the earlier experimental extension for public suffix domains.
The headline change is status. The 2015 DMARC spec was an Informational document published outside the IETF standards process. RFC 9989 is a Proposed Standard on the IETF Standards Track. For the first time, DMARC has formal IETF endorsement, which gives auditors and procurement teams a real standard to cite.
From one informational spec to three standards-track RFCs
Splitting the protocol into three documents was a deliberate design choice. Under RFC 7489, any fix to reporting meant reopening the entire specification. Now the protocol and its two reporting formats can each evolve on their own timeline without touching the others.
Why DMARCbis is really just the new DMARC
There is no “DMARC2.” The record version tag stays as v=DMARC1, and it is still the only valid value. Your published records did not become invalid the day RFC 9989 landed. If you understand DMARC today, you already understand most of what has changed.
There is no DMARC2. Records still begin with v=DMARC1, and every deployment already in the wild keeps working.
Why this matters if you send cold email
DMARC is already part of your deliverability baseline if you run outbound at any volume. Google and Yahoo have required it for bulk senders above 5,000 messages a day since early 2024, and frameworks like PCI DSS 4.0 and NIS2 in the EU reference it directly. A spec update to something this load-bearing is worth ten minutes of your attention even when nothing breaks.
What auditors and mailbox providers can now point to
The move to Standards Track carries real weight in a regulated environment. An “Informational RFC” raised questions in enterprise and government procurement, where teams want to cite a recognized standard. A Proposed Standard removes that friction and gives your compliance reviewers a cleaner reference.
Where old ambiguities cost inbox placement
Plenty of DMARC problems trace back to mismatched assumptions. A domain owner expects a policy to apply to one domain, while a receiver calculates the organizational domain a different way, and the reporting data becomes hard to read. RFC 9989 tightens the definitions and adds explicit examples and a conformance section, which shrinks the gray areas that quietly work against your placement.
What actually changed at the protocol level
Most of the update is clarification rather than new mechanics. A few changes are worth understanding in detail, because they affect how receivers read your record and which tags you should keep.
The DNS Tree Walk replaces the Public Suffix List
The old spec relied on the Public Suffix List, a third-party file, to figure out the organizational domain. RFC 9989 replaces that with a DNS Tree Walk. The receiver starts at the sending domain and walks up the DNS tree looking for a _dmarc record at each level, capped at eight lookups to prevent abuse. For most senders this changes nothing you can feel. For organizations with deep subdomain trees, a receiver on the new spec can sometimes resolve a different organizational domain than one still running RFC 7489.
If you run a complex subdomain hierarchy, publish an explicit DMARC record at every domain you actually send from. That removes the ambiguity between old and new receivers.
Tags removed: pct, rf, and ri
pct (percentage), rf (report format), and ri (report interval) are deprecated and no longer belong in a current record. They were rarely used well, and leaving them in adds noise. Plan to remove them on your next DNS edit.
Tags added: np, psd, and t
RFC 9989 introduces three new tags, all optional:
- np sets a policy for non-existent subdomains, the ones that return NXDOMAIN. It closes a subdomain-spoofing gap that sp did not cover, since sp only applies to subdomains that actually exist.
- psd flags a domain as a Public Suffix Domain, such as a country-code or sector registry. Most sending domains never touch this.
- t signals test mode explicitly. It takes over the staging role that people used to approximate with pct=0, so “this policy is being staged” is now unambiguous.
An example record using the new tags looks like this:
v=DMARC1; p=reject; np=quarantine; psd=n; t=y; rua=mailto:reports@yourdomain.com
New guidance on p=reject for mailbox domains
One behavioral shift matters for anyone whose users post to mailing lists. RFC 9989 discourages p=reject for domains that host general user mailboxes, unless you have measured the risk and have controls in place. Forwarding and mailing lists still break the SPF or DKIM alignment DMARC expects, and an aggressive reject policy can bounce legitimate mail before it ever reaches the inbox.
Do you need to redo your DMARC setup?
The one-line answer
No. Your current record still works, and the new tags are additive. The work here is a short cleanup of what you already have.
A five-point record audit you can run in ten minutes
Pull your current record and check it against the new spec:
- Confirm the record still starts with v=DMARC1. It should, and nothing else is valid.
- Remove pct, rf, and ri if any of them are present.
- If you manage subdomains, evaluate np, and start with np=quarantine rather than np=reject so you do not block undocumented but legitimate hosts.
- Publish an explicit DMARC record at every subdomain you send from, so the DNS Tree Walk resolves the same policy for every receiver.
- Review your rua and ruf reporting addresses, and confirm your monitoring tool can parse the RFC 9990 and 9991 report formats.
Mistakes senders are making with the new spec
Chasing tags you don’t need
The new tags help in specific situations. They are not universal upgrades. Adding psd to an ordinary sending domain does nothing for you, and jumping straight to np=reject can block real mail from hostnames nobody documented. Adopt a tag when you can name the exact problem it solves for your domain.
Reading Standards Track as a new mandate
The promotion to Proposed Standard does not create new sending requirements on its own. Google and Yahoo’s thresholds did not move because of it. Treat RFC 9989 as a prompt to tidy your record and confirm your tooling is current, not as a deadline to scramble against.
Get your record standards-ready
The spec reads more clearly now, and mailbox providers are already evaluating mail against it. A ten-minute audit keeps your outbound aligned with how receivers discover your policy and score your sends.
Generate a compliant DMARC record in minutes
Manually assembling a DMARC record means getting the syntax, tag order, and reporting addresses right on the first try. Warmy’s free DMARC generator walks you through each field, including the reporting and policy tags covered above, and outputs a record you can paste straight into your DNS. It’s a fast way to confirm your setup lines up with the current spec before you make any changes.
Further reading
For the full technical detail behind the changes discussed here, the primary sources are worth bookmarking: RFC 9989 defines the current DMARC protocol, and RFC 7489 is the original 2015 specification it replaces.
