DMARC’s 2026 DNS Tree Walk: why RFC 9989 no longer relies on a public-suffix list to find policy

What is authoritative in this case

RFC 9989 replaces reliance on a Public Suffix List with a DNS Tree Walk for DMARC policy discovery and organizational-domain determination, and folds public-suffix-domain policy discovery into that algorithm.

RFC 9989 changes a piece of DMARC policy discovery that many older explainers tied to a Public Suffix List. The current specification defines a DNS Tree Walk for finding an organizational domain and applicable DMARC policy. That matters for unusual domain structures and for implementers who previously embedded a separately updated PSL into DMARC logic. A sender does not need to “enable” the tree walk in DNS, but operators should understand it when diagnosing why a receiver discovered a parent policy. When documentation still says DMARC fundamentally depends on PSL lookup, check whether it is describing RFC 7489-era behavior rather than the May 2026 specification.

The assumption most likely to age badly

The organizational domain is not simply “the last two labels” and is no longer something a current implementation should derive only from a locally updated PSL. DNS structure and explicit DMARC records participate in discovery.

The migration mistake is to rewrite working DMARC records just because the discovery algorithm changed. The record still lives at `_dmarc.<domain>` and policy tags still have their defined meanings; the major change is how a receiver walks upward when needed. Another mistake is assuming a parent record automatically governs every descendant in the same way. Policy discovery interacts with the exact From domain and DMARC’s subdomain/non-existent-domain semantics. Diagnose the specific From domain a receiver evaluated, then trace the current discovery procedure instead of using a generic “root domain” label from a third-party checker.

How to verify with independent evidence

Start with the RFC5322.From domain, query the expected _dmarc name, then walk according to RFC 9989 while recording each DNS answer, the selected policy domain, and whether a PSD-related condition changes the result.

For a concrete test, choose a From domain with multiple labels and query `_dmarc` at the exact domain first. If no applicable record is found, follow the RFC 9989 tree-walk rules and record each candidate queried. Compare the discovered policy with Authentication-Results or a DMARC evaluator on a real message. If your organization uses delegated subdomains or hosted customer domains, include those structures in testing because they expose assumptions that a simple `example.com` case will not. Keep raw DNS answers and TTLs so cached older data is not mistaken for a policy-discovery bug.

A repair that remains maintainable

Publish explicit DMARC records on important author domains when ambiguity would be costly, and update validators or internal code that still bakes in RFC 7489-era PSL behavior as the only algorithm.

The operational fix is documentation and test coverage rather than aggressive DNS churn. Update internal runbooks and code comments that still say “use the PSL to find the organizational domain,” and ensure any in-house DMARC parser follows the current RFC. For sender-side DNS, keep policies explicit where business boundaries require them, and validate parent/subdomain behavior before moving from monitoring to enforcement. Because receivers may update implementations on different schedules, examine real aggregate/authentication evidence during transition. The goal is to publish an unambiguous policy while avoiding assumptions based on an obsolete discovery model.

How the issue appears in day-to-day outbound

A delegated multi-label suffix can expose differences between a stale PSL and the current tree-walk method. Explicit policy at the author domain avoids depending on two implementations reaching the same inherited answer.

For content and tooling, version labels matter. A guide can be technically accurate about RFC 7489 and still be outdated in 2026 if it presents PSL-based organizational-domain discovery as the current rule. Tag internal documentation with the RFC version it follows and link directly to RFC 9989 when explaining the tree walk. If you maintain a parser, build test vectors for multi-label domains, exact-domain policy, parent policy discovery, and cases where the walk should stop. Keep those tests independent of any local PSL package so an old dependency cannot silently define DMARC behavior. Sender-side operators do not need to implement receiver logic, but understanding the new discovery model helps them interpret aggregate results and avoid unnecessary DNS edits when a receiver applies a policy found higher in the domain tree.

What belongs beside the raw artifact

Store the author domain, every _dmarc query, returned record, tree-walk stopping point, and final organizational domain. This is far more useful than a dashboard that only says “DMARC found.”

Avoid solving a local problem with a global change

Do not rewrite DNS solely to satisfy one checker. First identify which DMARC specification and discovery algorithm that checker implements, then compare its answer with the current RFC.

Field checklist

• Capture the raw evidence for DMARC RFC 9989 DNS tree walk organizational domain public suffix before editing DNS, queue state, or mailbox metadata.
• Confirm the cited mechanism using dmarc-rfc rather than a generic deliverability score.
• Keep a known-good control case so the failing layer can be compared without changing several variables at once.
• Apply the narrow repair described for DMARC’s 2026 DNS Tree Walk: why RFC 9989 no longer relies on a public-suffix list to find policy and preserve a rollback or retry path.
• Repeat the original failing test after the change; do not substitute a different checker as proof of recovery.
• Store timestamp, affected identity, raw result, action taken, and the post-change result in the operator log.