RFC 9989 Explained: The DMARC Changes Security Leaders Should Know
Knowledge
RFC 9989 became the new Standards Track specification for DMARC in May 2026, replacing RFC 7489 and RFC 9091. The change that matters most to security leaders is DNS-based policy discovery: receivers can now walk up the DNS hierarchy to find the applicable DMARC record and organizational boundary. The update also adds active tags for non-existent subdomains, public suffix boundaries, and testing, while retiring several tags that produced inconsistent behavior.
The revision was widely called "DMARCbis" while the IETF developed it. I do not call the finished standard "DMARC 2.0" because the published record version remains v=DMARC1. Existing SPF, DKIM, and DMARC programs still apply, but DNS ownership, vendor compatibility, reporting pipelines, and change control now need a deliberate review.
What RFC 9989 changes
The RFC Editor record classifies RFC 9989 as a Proposed Standard on the Internet Standards Track. That status matters because RFC 7489 was Informational. RFC 9989 now carries the IETF consensus definition of DMARC validation, policy discovery, record syntax, receiver behavior, and security considerations.
One update, three RFCs
RFC 9989 defines the core protocol. RFC 9990 defines aggregate reporting. RFC 9991 defines message-specific failure reporting. Together they obsolete the DMARC material in RFC 7489, while RFC 9989 also obsoletes RFC 9091.
|
|
|
|---|---|---|
9989 | Core DMARC | Policy discovery and tags |
9990 | Aggregate XML | Parser and schema support |
9991 | Failure reports | Privacy and data handling |
The May 2026 DMARC standards set
The split lets protocol rules and report formats change independently. RFC 9990 retains XML aggregate reporting but clarifies its schema, report identifiers, one-policy-domain report structure, extensions, tree-walk discovery metadata, and the required DKIM selector field. RFC 9991 covers per-message failure reports, which can expose headers or message content. I treat failure reporting as a privacy-controlled diagnostic capability, not a default telemetry feed.
The companion RFC names and publication details appear in the normative references of the IETF HTML text. A concise DMARCbis publication summary can help non-technical stakeholders understand why three documents arrived together.
How DNS tree-walk policy discovery works
A receiver first queries the exact Author Domain by prepending _dmarc. If no valid record exists there, the receiver walks upward through parent labels. It looks for the organizational domain and, where applicable, a Public Suffix Domain policy. The applicable record preference is the Author Domain, then its organizational domain, then its public suffix.
RFC 9989 DNS tree walk from author domain to applied policy
The walk is bounded. Even an Author Domain with many labels triggers no more than eight DMARC DNS queries in a full walk. For deep names, the algorithm skips labels so the search reaches useful parent levels within that limit. A valid record containing psd=y or psd=n stops the walk and helps define the boundary. Multiple DMARC records at one lookup name are discarded, as before.
- Policy search. The tree walk finds the record that governs a message when the exact Author Domain has none.
- Boundary search. It determines organizational domains used for relaxed SPF or DKIM identifier alignment.
- Delegated control. A large organization can mark a delegated DNS subtree as its own organizational boundary with psd=n.
- Migration risk. Legacy PSL-based receivers and RFC 9989 receivers can reach different conclusions during adoption.
Deep subdomains need explicit review
If an Author Domain has more than eight labels and needs a specific policy, publish an explicit record at that Author Domain. Do not assume every receiver will discover an intended policy deep in the tree.
The tag changes that affect operations
RFC 9989 adds np, psd, and t to the active registry. It marks pct, rf, and ri as historic. Receivers following the new standard ignore unknown tags, so mixed adoption should not invalidate an otherwise sound record. Historic tags still need removal because teams may otherwise believe they control behavior that RFC 9989 no longer defines.
|
|
|
|---|---|---|
np | Active | Policy for non-existent subdomains |
psd | Active | Public suffix or organization boundary |
t | Active | Policy test mode |
pct | Historic | Percentage sampling removed |
rf | Historic | Failure format request removed |
ri | Historic | Requested report interval removed |
Active additions and historic tags
The np tag accepts none, quarantine, or reject. It applies only when the Author Domain is an NXDOMAIN beneath the governing organizational domain. If np is absent, the receiver uses sp when present, otherwise p. A NODATA response does not make the domain non-existent.
Illustrative RFC 9989 zone-file recordDNS
_dmarc.example.com. IN TXT ( "v=DMARC1; p=reject; sp=quarantine; np=reject; t=n; " "rua=mailto:dmarc-reports@example.com" )
The t=y setting is not percentage rollout. It asks validators to treat a failing message one policy level below the published choice: reject becomes quarantine, and quarantine becomes none. The default t=n requests the stated policy. Because receivers still retain local discretion, governance should measure observed disposition rather than assume every receiver follows the request identically.
What did not change
RFC 9989 refines DMARC rather than replacing its security model. A message still passes DMARC when SPF or DKIM passes and the authenticated domain has the required identifier alignment with the RFC5322.From domain. The receiving system still makes the final handling decision. A published policy is a requested disposition, not a guaranteed delivery action.
Protocol constants
The DNS TXT location still begins with _dmarc. The version is still v=DMARC1 and must appear first. Policies remain none, quarantine, or reject. Relaxed and strict identifier alignment remain available.
Security limits
DMARC still targets unauthorized use of the exact Author Domain. It does not stop lookalike domains, display-name impersonation, malicious content, or every forwarding-related authentication failure. A DMARC pass does not prove a message is safe.
The active tags adkim, aspf, fo, p, rua, ruf, and sp remain. Aggregate reports remain the main way to inventory authorized sources and find authentication gaps. The operating sequence also remains familiar: monitor, classify sources, repair legitimate failures, test interoperability, then move policy under controlled change.
Why governance matters more now
Tree-walk discovery turns DNS hierarchy into part of the email security control plane. A delegated subdomain, forgotten record, or poorly reviewed psd=n value can change which policy and organizational boundary a conforming receiver selects. I place DMARC records under the same ownership model as certificates, identity domains, and public DNS zones, with a named owner and an auditable approval path.
Start by inventorying every Author Domain, its parent chain, explicit DMARC records, delegated DNS administrators, and active sending services. Validate each record with a focused DMARC checker, then test actual messages because valid syntax does not prove SPF or DKIM identifier alignment.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
During mixed receiver adoption, compare aggregate report behavior across major traffic destinations. Unexpected changes in the reported policy domain, discovery method, or failure distribution need investigation before enforcement changes. Keep a temporary exception register for forwarders and mailing lists, with an owner and expiry date for each exception.
For a managed workflow, Suped's DMARC monitoring brings DMARC, SPF, DKIM, blocklist, and deliverability signals into one operational view, with issue detection and fix steps. That is useful when a security team needs evidence and alerts across many domains. The protocol decisions, DNS approvals, privacy review, and vendor accountability should still stay with the organization.
A concrete 90-day plan
The goal is not to add every new tag. It is to know which policy each receiver should discover, remove reliance on historic controls, verify report processing, and make enforcement changes only with evidence. I use four work periods so DNS, messaging, privacy, and vendor owners have clear handoffs.
- Days 0-15. Name the executive sponsor and technical owner. Inventory Author Domains, DNS delegations, DMARC records, report destinations, senders, and vendors. Freeze unreviewed policy changes.
- Days 16-30. Model tree-walk results for every domain. Flag deep names, conflicting records, public suffix assumptions, historic tags, and external reporting destinations. Confirm privacy controls for failure reports.
- Days 31-60. Repair SPF and DKIM identifier alignment, publish explicit records where discovery is ambiguous, update parsers for RFC 9990 fields, and test vendor handling of t, np, psd, plus historic tags.
- Days 61-90. Remove unsupported assumptions, approve policy changes in controlled batches, monitor legitimate failure rates, document receiver differences, and present residual risks to leadership.
Do not replace pct with t mechanically. Use smaller domain batches, controlled policy stages, aggregate report evidence, and rollback criteria. The DMARC policy guide explains the handling difference among none, quarantine, and reject.
Leadership metrics that show control
A board does not need raw XML counts. It needs evidence that known mail is authenticated, unauthorized use is constrained, changes are controlled, and exceptions are shrinking. Report both coverage and quality because a high enforcement percentage can hide unmonitored domains or broken legitimate traffic.
|
|
|
|---|---|---|
Domain coverage | Inventoried vs monitored | Up |
Aligned volume | Legitimate pass rate | Up |
Enforcement | Protected mail volume | Up |
Exceptions | Open and overdue | Down |
Change failures | Incidents per release | Down |
Vendor readiness | Verified RFC support | Up |
Suggested monthly DMARC control metrics
Define each denominator. "Domain coverage" should include parked domains, delegated business-unit domains, and domains used only by third parties. "Aligned volume" should exclude confirmed unauthorized traffic. Pair every metric with an owner, data source, review date, and threshold for escalation.
Questions to ask email vendors
Ask for observed behavior and test evidence, not a generic statement of support. A sender, receiver, gateway, report processor, or DNS automation vendor touches a different part of the control. The contract and support plan should identify which part each vendor owns.
- Discovery. Do you implement RFC 9989 tree-walk policy discovery and its eight-query limit?
- Boundaries. How do you process psd=y, psd=n, and the default psd=u value?
- Tags. What exact behavior occurs for np and t, and how are pct, rf, and ri handled?
- Reporting. Can your pipeline parse RFC 9990 fields, extensions, and both PSL and tree-walk discovery values?
- Privacy. What data from RFC 9991 failure reports is collected, redacted, encrypted, retained, and accessed?
- Evidence. Which conformance tests, rollout dates, known exceptions, and customer-visible logs can you provide?
Also ask how the vendor reports local policy overrides. DMARC permits receivers to make their own delivery decisions, so a vendor must distinguish the published policy, evaluated authentication result, and actual disposition. Without that distinction, an executive dashboard can overstate enforcement or misclassify legitimate failures.
For broad pre-change validation, a domain health check can expose related SPF and DKIM issues that a DMARC syntax review misses. Keep the test output with the change ticket so later report shifts can be traced to an approved baseline.
The decision security leaders should make
Treat RFC 9989 as a control-plane and governance update, not a reason to redesign email authentication. Preserve working SPF, DKIM, and DMARC controls. Review DNS hierarchy assumptions, remove historic tag dependencies, verify RFC 9990 ingestion, constrain RFC 9991 data, and require vendors to show their implementation behavior.
The strongest outcome after 90 days is a defensible map of every protected domain, the policy each receiver should discover, the legitimate sources that pass through SPF or DKIM identifier alignment, and the exceptions leadership has accepted. That evidence supports safer enforcement decisions throughout the new DMARC standard's adoption period.
