DMARC Tree Walk explained — how DMARCbis finds the organizational domain without the PSL

You've read that DMARCbis drops the Public Suffix List in favor of something called a “DNS Tree Walk” — and want to know what a mail receiver is actually doing differently.

Check your domain first — 10 seconds, free, no signup.
See your DMARC policy, SPF lookup count and every issue explained in plain English.
Run the free check →

What this means

Classic DMARC (RFC 7489 §3.2) finds a message's Organizational Domain by comparing it against Mozilla's Public Suffix List — an externally maintained list. RFC 9989 replaces that dependency with the DNS Tree Walk: the receiver queries a DMARC TXT record starting at the full author domain, then repeatedly strips the left-most label and re-queries until it finds a valid record or runs out of labels. To stop this being abused as a denial-of-service vector against artificially deep domains, RFC 9989 caps it at 8 DNS queries — author domains with more than 8 labels are truncated to a 7-label starting point before the walk begins, so no domain name can force more than 8 lookups. Source: RFC 9989 §4.10 “DNS Tree Walk” · verified 2026-07-17.

What to do about it

Step 1. No DNS change needed on your side: the Tree Walk changes how receivers discover your record, not where you publish it — a single _dmarc.yourdomain.com TXT record still works.
Step 2. If you publish DMARC only at your root domain, the Tree Walk finds it the same way the PSL-based method did — the difference mainly shows up for deep subdomains or PSD scenarios.
Step 3. If you operate a public-suffix-style domain (a registry TLD, or a SaaS platform issuing customer subdomains), see the PSD DMARC page below — the Tree Walk is what makes np= policies for non-existent subdomains work.
Step 4. Run a free check on your domain below to confirm your current record resolves cleanly regardless of which discovery method a receiver uses.

Frequently asked

Do I need to change my DMARC record because of DMARCbis?

No, not immediately. RFC 9989 keeps the same v=DMARC1 tag syntax your current record uses — it mainly changes how receivers discover the record (the DNS Tree Walk) and adds optional new tags like t= and np=. Nothing about your existing record becomes invalid.

Is DMARCbis a completely different standard from DMARC?

No — RFC 9989 explicitly obsoletes RFC 7489 as a refinement of the same DMARC standard, based on years of implementation experience. Aggregate and failure reporting moved into their own documents, RFC 9990 and RFC 9991, all published May 2026.

Where can I read the actual standard instead of a summary?

RFC 9989 (core), RFC 9990 (aggregate reports) and RFC 9991 (failure reports) are all published free at rfc-editor.org, no registration required.

Don't want to babysit DNS records?
DMARCKeeper monitors your reports, names every sender, and walks you to full p=reject protection.
Start free monitoring →