DMARCbis is now official. In May 2026, the IETF published RFC 9989 as the new main DMARC specification, with RFC 9990 for aggregate reporting and RFC 9991 for failure reporting. Together, they replace RFC 7489 from 2015 and make DMARC an IETF Proposed Standard.
The direct answer is simple: there is no DMARC2, and your record still starts with v=DMARC1. Most domain owners do not need an emergency DNS change. The work now is to clean up old assumptions, check whether your tooling understands the new tags, and use reports to confirm that real mail keeps passing before you tighten policy.
Fast answer
No new version: DMARC records continue to use v=DMARC1.
New documents: RFC 9989 covers the protocol, RFC 9990 covers aggregate reports, and RFC 9991 covers failure reports.
Operational work: Audit record tags, reporting destinations, subdomain policy, and same-domain SPF or DKIM results.
Suped workflow: Suped's DMARC monitoring helps turn aggregate reports into sender inventory, issue detection, and policy staging decisions.
What changed in the RFC set
The biggest change is not a single new DNS trick. It is the split of the old DMARC material into clearer documents. The main RFC now has stronger definitions, more implementation guidance, better examples, and a conformance section that tells domain owners and receivers what full participation requires.
That matters because many DMARC failures come from mismatched mental models. A domain owner thinks a policy applies to one domain, a receiver calculates the Organizational Domain another way, and the reporting data becomes hard to reason about. The new documents make those steps more explicit.
Full participation is clearer now
The new conformance section is worth reading even if you are not implementing receiver-side DMARC code. It turns DMARC from a record-only checklist into an operating model: send authenticated mail, publish policy where it will be discovered, collect reports, analyze the reports, then remediate the senders that fail.
Domain owners: Publish SPF or DKIM in a way that produces a DMARC pass for the Author Domain.
Report handling: Operate a mailbox or reporting endpoint that can receive aggregate reports and keep enough history to compare changes.
Receivers: Evaluate the Author Domain, preserve authentication results, support mailto reporting, and avoid rejecting only because a sending domain says reject.
RFC
Scope
Practical effect
9989
Protocol
Policy records, discovery, same-domain checks, and conformance
9990
Aggregate
XML reports, delivery, duplicates, and report consumers
9991
Failure
Per-message failure reports and privacy considerations
The three RFCs now split DMARC into protocol, aggregate reporting, and failure reporting documents.
The old DMARC RFC split into protocol, aggregate reporting, and failure reporting RFCs.
What changed in DMARC records
The record format is still compatible with the old world. Unknown tags are ignored by conforming receivers, and the version string stays the same. Still, the tag set has changed enough that I would review every production DMARC record, especially records generated years ago and records maintained by separate business units.
The removed tags are pct, rf, and ri. The added tags are np, psd, and t. If you need a clean reference while checking records, keep a DMARC checker close by rather than reading raw TXT strings by eye.
Partial rollout: The old pct tag requested policy on only some messages.
Report format: The old rf tag requested a failure report format.
Report timing: The old ri tag requested aggregate report intervals.
RFC 9989 habits
Testing mode: Use t=y when testing a stricter stated policy.
Missing names: Use np for non-existent subdomain policy.
Public suffix: Use psd only when the domain role requires it.
For most teams, Hosted DMARC is the cleaner way to handle policy staging because the record can move through none, quarantine, and reject without asking a DNS owner for every small adjustment.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
Why the DNS tree walk matters
RFC 9989 replaces the old Public Suffix List dependency with a DNS Tree Walk for policy discovery and Organizational Domain calculation. That is one of the most technical changes in the update. It changes how receivers find the relevant DMARC record and how they compare domains for a DMARC pass.
The practical effect is better support for Public Suffix Domains. A PSD can now take part in DMARC using the psd flag, and ordinary organizational domains can publish psd=n if they need to prevent a higher-level PSD record from being interpreted incorrectly.
DNS Tree Walk flow for finding the DMARC policy domain.
Tree walk migration risk
Receiver variance: Receivers using older PSL logic can pick a different Organizational Domain than newer implementations.
Best control: Publish explicit DMARC records for Author Domains that send important mail.
Strict mode: Consider strict SPF and DKIM matching only after every sender has been verified.
Reporting and failure reports changed in practice
Aggregate reporting now has its own RFC, and the XML format was updated to reflect the current tag set and real reporting behavior. This is useful because aggregate reports are where domain owners see which sources are passing, which are failing, and which third parties still need SPF, DKIM, or sender configuration work.
The failure reporting RFC remains close to the older model, but it now states the privacy issue plainly. Failure reports can expose headers and sometimes message content, so I treat ruf as a narrow diagnostic option, not a default setting for every domain.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
In Suped, this is the workflow I want teams to use after the RFC update: keep collecting aggregate reports, look for unverified sources, fix the sender or DNS issue, then tighten policy only when the data shows that legitimate traffic passes. Suped also brings SPF, DKIM, blocklist monitoring, and deliverability signals into the same view, which reduces the guesswork during a policy change.
Policy staging after the RFC update
Use report evidence before moving to stronger DMARC policy.
Monitor
p=none
Start with reports and sender discovery.
Contain
p=quarantine
Move after common sources pass.
Reject
p=reject
Use only after mailing list and forwarding risk is understood.
What I would do now
I would not rush to edit every DMARC TXT record just because the RFC number changed. I would run a controlled review. The goal is to remove stale assumptions, confirm that the sending inventory is complete, and stop relying on tags or behaviors that the new documents have cleaned up.
Inventory first: List every domain and subdomain that sends mail, including support, billing, HR, product, and marketing systems.
Check tags: Find any use of pct, rf, or ri and replace the process behind them.
Review subdomains: Decide whether existing subdomains and non-existent subdomains need different handling through sp and np.
Protect reject: Do not rely only on SPF for a domain at p=reject; make sure DKIM passes for real sending paths.
Use reports: Compare aggregate report data for at least a month at p=none before stronger policy.
Regenerate cleanly: Use a record generator when you need a fresh TXT record instead of patching an old one by hand.
Do not miss the mailing list caveat
The indirect email flow issue remains unresolved. Forwarding, role aliases, and mailing lists can still break the SPF or DKIM domain match DMARC expects. RFC 9989 now discourages p=reject for domains whose users post to mailing lists, unless the organization has measured the risk and has controls in place.
The practical takeaway
DMARCbis becoming RFC 9989, RFC 9990, and RFC 9991 is a standards cleanup with real operational consequences. The main protocol is clearer, reports are better separated, PSD support is more coherent, and the old PSL dependency has been replaced by the DNS Tree Walk.
The safest operational response is measured and data-led: keep v=DMARC1, clean up removed tags, add newer tags only where they solve a real policy problem, and use aggregate reports before tightening enforcement. Suped's product is built around that workflow: monitor, detect the sender issue, fix it, verify the result, then stage the policy change with fewer DNS handoffs.
Frequently asked questions
0.0
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
