DMARCbis is now published as RFC 9989, 9990, 9991
News
Published 1 Jun 2026
Updated 10 Aug 2026
9 min read
Summarize with
Updated on 10 Aug 2026: We updated this guide with external report authorization, RFC 9990 schema changes, failure-report rate limits, and corrected full-participation requirements.
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. The set replaces RFC 7489, while RFC 9989 also obsoletes RFC 9091, and puts DMARC on the IETF Standards Track at Proposed Standard maturity.
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 SPF and DKIM alignment results.
- Suped workflow: Suped's DMARC monitoring turns aggregate reports into sender inventory, issue detection, and evidence for policy staging.
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 mail with aligned identifiers, publish policy where it will be discovered, collect reports, analyze the reports, then remediate the senders that fail.
- Domain owners: Send mail with both an SPF-authenticated identifier and a DKIM signing domain aligned with the Author Domain.
- Policy publishing: Publish a DMARC record for the Author Domain and for its Organizational Domain when those domains differ.
- Report handling: Operate a mailbox or reporting endpoint that can receive aggregate reports, then collect and analyze them.
- Receivers: Evaluate the Author Domain, preserve authentication results, support mailto reporting, and avoid rejecting only because a sending domain says reject.
|
|
|
|---|---|---|
9989 | Protocol | Policy records, discovery, identifier alignment, and conformance |
9990 | Aggregate | XML reports, report authorization, delivery, and duplicates |
9991 | Failure | Per-message failure reports, rate limiting, and privacy |
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 remains compatible with existing deployments. Unknown tags are ignored by conforming receivers, and the version string stays the same. Still, the tag set has changed enough to justify reviewing every production DMARC record, especially records generated years ago and records maintained by separate business units.
The tags pct, rf, and ri now have historic status. Relative to RFC 7489, the active additions 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.
Example DMARC record using newer tagsdns
_dmarc.example.com. 3600 IN TXT ( "v=DMARC1; p=quarantine; sp=reject; np=reject; t=y; " "rua=mailto:dmarc-reports@example.com" )
Old record habits
- 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 to request policy one level below the stated policy while reports continue.
- Missing names: Use np to set policy for non-existent subdomains.
- Public suffix: Use psd only when the domain's role in the DNS hierarchy requires it.
For teams that want to stage policy without repeated DNS handoffs, Suped's Hosted DMARC lets the record 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 algorithm caps a full walk at eight DNS queries to limit abuse from domains with many labels.
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 when they need to declare that boundary explicitly.
DNS Tree Walk flow for finding the DMARC policy domain.
Tree walk migration risk
- Receiver variance: Receivers using older PSL logic can select 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 alignment 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 show which sources are passing, which are failing, and which third parties still need SPF, DKIM, or sender configuration work.
RFC 9990 adds optional data for the schema version, report generator, envelope sender, policy discovery method, and testing state. A report can label discovery as psl or treewalk, while the policy_test_mode override reason records when testing mode changed message handling. Report parsers should accept these fields without losing older report data.
The failure reporting RFC remains close to the older model, but it states the privacy issue plainly and requires report generators to rate-limit outgoing reports. Failure reports can expose headers and sometimes message content, so 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, the practical workflow after the RFC update is to keep collecting aggregate reports, find unverified sources, fix the sender or DNS issue, and tighten policy only when the data shows that legitimate traffic passes. Suped connects source identification with SPF and DKIM diagnostics so each policy change has report evidence behind it.
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.
Verify external report destinations
When a rua or ruf address uses a different Organizational Domain, the report generator must verify that the destination has authorized the relationship. The destination publishes a TXT record whose name combines the DMARC Policy Domain, _report._dmarc, and the destination host. Without a valid record, the receiver must ignore that reporting URI.
Cross-domain aggregate reporting authorizationdns
_dmarc.example.com. 3600 IN TXT ( "v=DMARC1; p=none; rua=mailto:dmarc@reports.example.net" ) example.com._report._dmarc.reports.example.net. 3600 IN TXT "v=DMARC1"
The reporting destination owns the authorization record. A destination willing to accept reports for any policy domain can publish a wildcard at *._report._dmarc.reports.example.net, but per-domain authorization keeps the scope narrower. Check both the TXT record and the receiving mailbox when reports stop after a reporting address change.
What to do now
Do not rush to edit every DMARC TXT record just because the RFC number changed. 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.
- Verify destinations: Confirm every external reporting domain publishes the required authorization TXT record and can receive the reports.
- Protect reject: Do not rely only on SPF for a domain at p=reject; make sure aligned 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, mailing lists, and other indirect paths can still break the SPF or DKIM alignment 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 historic tags, add newer tags only where they solve a real policy problem, verify external report authorization, and use aggregate reports before tightening enforcement. In Suped, that workflow maps to aggregate report monitoring, sender issue diagnosis, result verification, and staged policy changes with fewer DNS handoffs.
