DMARCbis Is Published: RFC 9989, 9990, and 9991 Replace RFC 7489
DMARC is now a Standards-Track Internet protocol.
DMARCbis is the IETF revision of DMARC, published in May 2026 as three separate documents: RFC 9989 (the new core protocol), RFC 9990 (aggregate reporting), and RFC 9991 (failure reporting). Together they obsolete RFC 7489 and promote DMARC from Informational to Proposed Standard (Standards Track) for the first time. This is the new DMARC RFC set for 2026 — the canonical DMARC specification going forward.
RFC 7489 was originally published in 2015 as an Informational document. After eleven years of operational deployment and one revision attempt (RFC 9091, which added the psd= tag), the IETF DMARC Working Group split the protocol into three Standards-Track documents. The core authentication-and-policy work is now in RFC 9989; aggregate reporting moved to RFC 9990; failure reporting moved to RFC 9991.
This post is the day-one breakdown of what changed, why it matters, and what to do this week.
What Changed — at a Glance
One sentence — this is the DMARC RFC 2026 update at a glance: RFC 7489 (Informational, 2015) is replaced by three Standards-Track RFCs published — RFC 9989 (core protocol), RFC 9990 (aggregate reporting), and RFC 9991 (failure reporting). DMARCbis is also marketed by some vendors as DMARC 2.0, but the RFC numbers are the canonical reference going forward.
The mapping:
| RFC 7489 (Informational, 2015) | Replacement (Standards Track, 2026) |
|---|---|
| RFC 7489 §1–§6 (core protocol) | RFC 9989 Domain-based Message Authentication, Reporting, and Conformance |
| RFC 7489 §7 (aggregate reports) | RFC 9990 DMARC Aggregate Reporting |
| RFC 7489 §8 (failure reports) | RFC 9991 DMARC Failure Reporting |
RFC 9091 ( | Merged into RFC 9989 |
| Public Suffix List (PSL) lookup | DNS Tree Walk (8-level limit) |
| Removed |
| (no equivalent) | New tags: |
| Removed; |
If you operate a DMARC record: most of your record stays valid. The v=, p=, sp=, rua=, ruf=, adkim=, aspf=, and fo= tags all keep their RFC 7489 meaning. pct=, rf=, and ri= are deprecated — remove them at your next DNS edit. Optionally adopt the three new tags described below.
If you process DMARC reports: the XML schema for aggregate reports (RFC 9990) gains optional fields including discovery_method, policy_test_mode, generator, and an optional envelope_from. Existing parsers keep working — unknown fields are ignored per XML rules — but updated parsers can use the new data to reduce source-identification ambiguity.
If you build DMARC tooling: Standards-Track status changes the IETF errata process and the cadence for future revisions. Any future change goes through formal IETF review, not the Informational-RFC working-group consensus that governed RFC 7489.
Why This Matters: DMARC Is Now Standards Track
RFC 7489 was published in 2015 as an Informational RFC. The Informational status meant DMARC was a public reference document but not a formally standardized protocol — implementations couldn’t claim “Standards Track” compliance, and the IETF errata process treated it as a community spec rather than a real standard.
RFC 9989 promotes DMARC to Proposed Standard (Standards Track) for the first time. The promotion is the work of the IETF DMARC Working Group, with document editors Todd Herr (Valimail) and John Levine (Standcore LLC) shepherding the draft through more than five years of revisions; further contributors are listed in RFC 9989 Appendix D.
It took eleven years because Standards-Track promotion requires operational deployment data and demonstrated interoperability across independent implementations. DMARC had to be deployed at scale before the IETF would ratify the spec as a real Internet Standard.
What changes for vendors and auditors: implementations can now declare compliance with a Standards-Track RFC rather than an Informational one. PCI DSS, NIS2, BOD 18-01, and other compliance frameworks can reference RFC 9989 directly as the canonical DMARC specification. The DMARC specification is now a standard, not a community document.
That distinction is operational, not aesthetic. It changes how disputes get resolved, how revisions get cut, and how tooling claims correctness.
RFC 9989 — The New Core DMARC Protocol
RFC 9989 is the new core DMARC document. It carries the same scope as RFC 7489 §1–§6 (authentication, alignment, policy, record format, organizational domain discovery) and absorbs RFC 9091 (the psd= tag draft). Read the full spec at rfc-editor.org/rfc/rfc9989.html.
The four substantive changes — terminology, tree walk, removed tags, and new tags — are as follows.
New Terminology You’ll See in Tooling
RFC 9989 §3.2 formalizes four terms that competing articles still write informally. Tooling, auditors, and future IETF errata will use these:
- Domain Owner Assessment Policy
The formal new name for “DMARC policy” — the
p=tag value (none,quarantine,reject). RFC 9989 §3.2.- Report Consumer
Replaces “report receiver” — the entity that receives aggregate or failure reports at the address in the
rua=orruf=tag. RFC 9989 §3.2.- Monitoring Mode
The formal name for
p=none. Signals: collect data, take no enforcement action. RFC 9989 §3.2.- Enforcement
The formal name for
p=quarantineandp=rejectcollectively. Signals: act on failing mail. RFC 9989 §3.2.
The vocabulary change isn’t cosmetic. Auditors, RFC errata, and the next generation of DMARC documentation will use these terms going forward — worth adopting in internal runbooks and ticket titles so your team and your auditors are speaking the same language.
How DNS Tree Walk Replaces the Public Suffix List
RFC 7489 relied on the Public Suffix List (PSL) — a community-maintained list of public suffixes (.com, .co.uk, .github.io) — to determine the Organizational Domain for a given mail-sending domain. The PSL had two known problems: it lived outside the protocol (a Mozilla-hosted file with no formal update cadence), and changes propagated asynchronously across implementations.
RFC 9989 §4.10 (with the worked example in Appendix B.4) replaces the PSL with a DNS Tree Walk: a deterministic algorithm that walks parent domains via DNS lookups until it finds a DMARC record or hits a defined limit. The discovery is in-protocol and works without an external dependency.
The walk terminates at 8 DNS queries. That number is explicit in the spec. Operationally, no real-world domain hierarchy needs more than five levels, so the eight-query cap bounds lookup cost without breaking valid deployments.
For example, the tree walk for mail.product.example.co.uk queries:
_dmarc.mail.product.example.co.uk- then
_dmarc.product.example.co.uk - then
_dmarc.example.co.uk - then
_dmarc.co.uk.
The first label with a DMARC record is the Organizational Domain for policy purposes.
The new psd= tag (y / n / u, default u for unknown) lets Public Suffix Operators declare their domain is itself a public suffix — important during the transition while some receivers still consult the PSL.
If your domain hierarchy spans more than a single label (most do), the tree walk discovers a parent-domain DMARC record when the leaf has none — so publish at your Organizational Domain to cover all subdomains in one record.
Removed Tags — pct, rf, ri (and the Testing-Mode Replacement)
RFC 9989 removes three tags from RFC 7489. Each had operational problems that showed up across eleven years of deployment:
pct=(gradual enforcement percentage) — receivers implemented this inconsistently, producing unpredictable results across mailbox providers. RFC 9989 Appendix A.6 and Appendix C.5.2 document the removal and direct operators to the newt=ytesting-mode tag.rf=(report format) — only one value (afrf) was ever defined or used. The tag was redundant.ri=(report interval) — receivers ignored it in practice. Aggregate reports landed at the receiver’s preferred cadence regardless of what operators requested.
In the 5.5M domains we scanned for our 2026 State of Email Authentication research, 2.3% of DMARC records (38,749 of 1,670,975) carry an explicit non-default pct= value — the long tail of partial rollouts that never finished. The top values are pct=10 (7,513 records), pct=50 (7,346), pct=25 (4,594), and pct=5 (4,108). If your record is one of them, you have two options under RFC 9989: switch to t=y (testing mode — all-or-nothing signal that the policy is provisional), or commit to enforcement and drop the percentage entirely. The percentage-based rollout model is gone.
New Tags — np, psd, t (With Value Tables)
RFC 9989 adds three tags. Most domains can leave all three unset (defaults are safe), but each solves a specific operational problem.
np= (Non-existent subdomain Policy). RFC 9989 §4.7. Values:
| Value | Meaning |
|---|---|
none | No enforcement on mail claiming a non-existent subdomain |
quarantine | Quarantine mail claiming a non-existent subdomain |
reject | Reject mail claiming a non-existent subdomain |
If unset, np= defaults to whatever sp= is set to. Use it when you want stricter handling for non-existent subdomains than for legitimate ones (e.g., p=quarantine, sp=quarantine, np=reject).
psd= (Public Suffix Domain). RFC 9989 §4.7. Values:
| Value | Meaning |
|---|---|
y | This domain is a public suffix (mostly ccTLDs and managed-DNS providers) |
n | This domain is not a public suffix |
u | Unknown (default — receivers fall back to other discovery mechanisms) |
Almost no operator needs to set psd=. It exists for Public Suffix Operators (PSOs) who want to declare their domain is itself a public suffix during the transition away from PSL dependency.
t= (testing mode). RFC 9989 §4.7. Values:
| Value | Meaning |
|---|---|
y | Policy is provisional; receivers should treat enforcement as testing |
n | Policy is operational (default) |
Use t=y during enforcement rollout to signal to receivers that you are testing the policy. Drop it once you commit to enforcement.
RFC 9990 — Aggregate Reports Get Their Own RFC
Aggregate reporting was §7 of RFC 7489. It is now an independent Standards-Track RFC at rfc-editor.org/rfc/rfc9990.html. The separation lets aggregate reporting evolve on its own schedule without re-publishing the core authentication protocol every time the XML schema changes.
XML Schema Changes — discovery_method, policy_test_mode, generator
RFC 9990 §3.1.1 (specifically §3.1.1.3 “Report Generator Metadata” and §3.1.1.5 “policy_published”) expands the aggregate report XML schema. Existing parsers keep working — unknown fields are ignored per standard XML rules — but updated parsers can use the new data to disambiguate source identification.
If your DMARC vendor handles raw report XML for you, skim the field list below and skip to the next section; this depth matters when you build your own parser or audit a third-party one.
<discovery_method>(valuespslortreewalk) — signals whether the report-generator used the legacy Public Suffix List or the new DNS Tree Walk to determine the Organizational Domain.policy_test_mode— a new enum value of<reason>/<type>(per RFC 9990 §3.1.6) that replaces the removedforwardedandsampled_outoverride reasons. Signals that the receiver applied a policy in testing mode (paired with the newt=ytag).<generator>— identifies the reporting software (for example, “Google DMARC 2.0” or “Microsoft 2026”). Lets report consumers attribute schema differences to specific generators.<version>(optional) — schema version.<envelope_from>(optional) — adds the SMTP envelope sender alongside the existing header-from field for forensic correlation.<spf scope="mfrom"/>attribute — formalizes the MAIL FROM identifier scope for SPF results. RFC 9990 §3.1.1.13 fixes this to a single valid value (mfrom); the legacy unscoped<spf>element is gone.langattribute on<human_result>— internationalization for human-readable strings.
DMARCguard’s aggregate-report parser already reads the RFC 9990 fields that generators emit today — <generator>, <envelope_from>, <spf scope>, <version>, and the policy-record additions <np>, <psd>, <t>. The two newer fields, <discovery_method> and the policy_test_mode reason value, will land once receivers begin populating them — most reports in flight today still rely on implicit PSL discovery, so the operational signal arrives gradually as generators upgrade.
If you’ve never parsed an aggregate report by hand, our walkthrough of how to read a DMARC aggregate report covers the legacy XML and is being updated for the new RFC 9990 fields as receivers emit them.
External-Destination Verification Is Now Mandatory
RFC 7489 §7.1 said external-destination verification SHOULD be performed. RFC 9990 §4 (“Verifying External Destinations”) promotes this to MUST.
The mechanic: if your rua= or ruf= mailbox is at a different domain than the DMARC policy record (for example, rua=mailto:[email protected] on a policy record at _dmarc.example.com), the report-generator must verify a _report._dmarc.example.com TXT record at the destination domain before sending. The verification proves the destination domain consents to receive reports for the policy domain.
What this means operationally: confirm your reporting endpoint hosts the external-destination verification TXT record. Without it, RFC 9990–compliant receivers will stop sending you reports. Existing setups that worked under the old SHOULD may quietly stop working as receivers upgrade.
RFC 9991 — Failure Reports Get Their Own RFC
Failure reports (also called forensic reports or ARF reports) were §8 of RFC 7489. They are now an independent Standards-Track RFC at rfc-editor.org/rfc/rfc9991.html. Failure reports carry message content, so they are privacy-sensitive — a separate spec lets the privacy and rate-limiting requirements evolve independently.
The New Rate-Limit MUST for Report Generators
RFC 9991 §2 (“DMARC Failure Reports”) promotes rate-limiting from SHOULD (in RFC 7489) to MUST. The exact text: failure-report generators MUST implement a rate-limiting mechanism to bound the volume of reports they emit.
The reasoning is in §2 and §7 (Privacy Considerations): failure reports carry message content, which means unbounded generation creates both privacy exposure (the more reports, the more PII leaked) and DoS-amplification risk (an attacker who can trigger DMARC failures can fan them out to your ruf= endpoint).
What operators should expect: receivers may generate fewer failure reports than they used to during unusual load patterns. If you depended on every failure producing a report, your monitoring assumptions need updating.
Privacy Considerations (PII in Failure Reports)
RFC 9991 §7 adds expanded privacy guidance for what failure reports SHOULD and SHOULD NOT include. The guidance is non-binding (SHOULD, not MUST) but formalizes practices the operational community has converged on.
For senders who receive failure reports for someone else’s domain — usually the result of a forwarding misconfiguration — RFC 9991 gives you a clearer basis to discard rather than archive the content. The data was never yours to retain.
For a deeper treatment of how failure reports work end-to-end, see our Authentication Failure Reporting Format (ARF) guide.
Mailing Lists and p=reject — What RFC 9989 §7.4 Says
The longstanding tension between DMARC p=reject and mailing lists is now Standards-Track text. RFC 7489 §10.5 sketched the problem in two paragraphs of Informational language. RFC 9989 §7.4 expands that into a normative interoperability statement with six MUST/SHOULD requirements.
The problem: mailing lists rewrite or wrap the From: header to keep their own DMARC alignment, which breaks alignment for the original author. When the author’s domain publishes p=reject, receivers following DMARC strictly will drop legitimate list mail.
What §7.4 now requires of senders:
- Domains publishing
p=rejectMUST NOT rely solely on SPF and MUST apply valid DKIM signatures — DKIM is the only authentication that survives forwarding. - Domains whose users post to mailing lists SHOULD NOT publish
p=reject. - Staged rollout is SHOULD:
p=nonefor at least one month, thenp=quarantinefor at least one month, comparing aggregate report disposition results before considering reject. - Domains that do publish
p=rejectSHOULD tell their users that participation in mailing lists may be hindered.
What §7.4 now requires of receivers — the genuinely new normative force:
- Receivers MUST NOT reject messages solely on the basis of a
p=rejectpolicy. - In the absence of other knowledge and analysis, receivers MUST treat such failing mail as if the policy were
p=quarantine.
That second MUST formalises what Gmail, Microsoft 365, and Yahoo already do operationally — receivers downgrade p=reject to p=quarantine for indirect flows when nothing else corroborates a spoofing signal. RFC 9989 turns that ad-hoc practice into a spec.
On ARC specifically: RFC 9989 §7.4 names the Authenticated Received Chain (RFC 8617) as “a prominent example” of technical attempts to preserve authentication across forwarders, but the RFC explicitly observes that “none of the methods have become widely used” as of publication. Operationally, ARC is still the best chain-of-custody tool available for forwarders that modify mail, and our deep-dive on why DMARC fails on forwarded emails and how ARC fixes it walks through the deployment. But it would misread the RFC to call ARC the “recommended” fix — RFC 9989 reserves that framing for the MUST/SHOULD list above. For where ARC sits in the broader IETF roadmap — and why DKIM2 is being drafted as its eventual successor — see our ARC → DKIM2 transition guide.
15 RFC 7489 Errata Addressed in RFC 9989
RFC 9989 Appendix C.9 resolves 15 known errata from RFC 7489 — see the full erratum list at rfc-editor.org for IDs. The three with operational impact for most teams:
- Errata 5365 and 5495: clarified ambiguity in how the SPF and DKIM identifiers map to DMARC alignment, particularly when multiple DKIM signatures are present on a message.
- Errata 6485: corrected the formal grammar for the
pct=tag value range. (pct=is now removed entirely in RFC 9989 — the errata is resolved by removal rather than correction.) - Errata 7099 and 7100: documented edge cases in the policy override reporting fields that RFC 9990 then formalized via
policy_test_mode.
The remaining twelve cover smaller clarifications and editorial corrections — useful for implementers, mostly invisible to operators.
What To Do This Week
Most operators can finish the audit in under an hour. The four steps below are the most important ones.
1. Audit Your DMARC Record
Look up your current DMARC record with dig +short TXT _dmarc.example.com (replace example.com with your domain). Identify whether pct=, rf=, or ri= are present in the response. Note your rua= and ruf= destinations.
If your record fails the audit, our DMARC fail troubleshooting guide walks the seven most common causes — start there before touching DNS.
2. Remove pct, rf, ri If Present
Edit your DNS TXT record to drop any deprecated tags. If your record was, for example:
v=DMARC1; p=quarantine; pct=50; rua=mailto:[email protected]; rf=afrf; ri=3600
The RFC 9989–clean equivalent is:
v=DMARC1; p=quarantine; rua=mailto:[email protected]
If you used pct= for gradual rollout, switch to the new t=y testing-mode tag or commit to enforcement and drop the percentage entirely. The percentage-based rollout model is gone.
3. Decide on np, psd, t (Most Domains: Leave Defaults)
Most operators do not need to set any of the new tags. The defaults are safe and backward-compatible:
- Set
np=if you currently usep=noneorp=quarantineand want stricter handling for non-existent subdomains. Common configuration:np=reject. If you’re still working through enforcement, see how to fix “DMARC quarantine/reject policy not enabled”. - Set
psd=yonly if you operate a Public Suffix Domain (ccTLDs, managed-DNS providers likegithub.io, hosting providers offering customer subdomains). If you’re not sure, you’re not one. - Set
t=yduring enforcement rollout to signal to receivers that the policy is provisional. Drop it once you commit to enforcement.
4. Confirm Your Reporting Endpoint
Two checks:
- Your
rua=mailbox accepts mail. Test with adig MXon the destination domain, then send a test message and confirm delivery. - Your reporting endpoint hosts the external-destination verification TXT record. Now MUST per RFC 9990 §4 — if missing, compliant receivers stop sending reports.
Frequently Asked Questions
What is DMARCbis?
DMARCbis is the IETF revision of DMARC, published in May 2026 as three Standards-Track RFCs: RFC 9989 (core protocol), RFC 9990 (aggregate reporting), and RFC 9991 (failure reporting). Together they obsolete RFC 7489 and promote DMARC from Informational to Proposed Standard for the first time.
What replaced RFC 7489?
RFC 7489 is obsoleted by three new RFCs published in May 2026: RFC 9989 (Domain-based Message Authentication, Reporting, and Conformance), RFC 9990 (Aggregate Reporting), and RFC 9991 (Failure Reporting). Existing v=DMARC1 records remain valid; the deprecated pct, rf, and ri tags should be removed during your next DNS update.
Is DMARC Required Now?
DMARC has always been required by specific mandates (Google and Yahoo for bulk senders at 5,000 messages per day, PCI DSS 4.0, NIS2 in the EU). RFC 9989’s Standards-Track promotion does not create new requirements, but it gives auditors a formal Internet Standard to cite instead of an Informational document. Practical adoption pressure still comes from receivers, not from the RFC itself.
How Do I Update My DMARC Record for DMARCbis?
For most domains: remove pct, rf, and ri if present; leave np, psd, and t unset unless you specifically need them; confirm your reporting endpoint has the external-destination verification TXT record. Existing v=DMARC1 records are backward-compatible with the new RFCs.
When Were RFC 9989, 9990, and 9991 Published?
All three were published in May 2026 by the IETF DMARC Working Group after more than five years of drafting and review. RFC 9989 obsoletes RFC 7489 (the 2015 Informational DMARC spec) and RFC 9091 (the PSD tag draft). RFC 9990 and 9991 carve out aggregate and failure reporting into their own Standards-Track documents so each can revise independently.
Are Existing DMARC Records Still Valid?
Yes. v=DMARC1 records remain valid under RFC 9989 — the version tag is unchanged. The p, sp, rua, ruf, adkim, aspf, and fo tags all carry the same meaning. Only pct, rf, and ri are deprecated; receivers ignore them rather than reject the record, so your published record keeps working through the transition.
Conclusion
DMARC is now a Standards-Track Internet protocol. The eleven-year Informational era is over.
Three RFCs replace one: RFC 9989 for the core protocol, RFC 9990 for aggregate reporting, and RFC 9991 for failure reporting. Most operators only need to remove pct, rf, and ri from their DNS record — the rest is backward-compatible.
The DMARCbis publication is the rare news event in this space that changes how every DMARC vendor, auditor, and tooling author cites the specification. Verify your record against the new spec with our DMARC checker, then move on with your week.