DMARCbis's DNS Tree Walk: the end of the Public Suffix List

How the DNS Tree Walk works

DMARCbis replaces the PSL with a native approach: query DNS directly, level by level. That's the DNS Tree Walk.

The principle, simplified: to find a name's organizational domain, the resolver climbs the label tree looking for the DMARC record (_dmarc) at each level, up to eight queries maximum. The first level that carries a relevant DMARC policy defines the organizational domain. The eight-query limit is an anti-abuse guard (to stop an overly long name from triggering a flood of queries), exactly in the spirit of SPF's ten-lookup limit.

The result: determining the organizational domain becomes deterministic and self-contained. No external list, no freshness divergence — only DNS, which everyone queries the same way.

What it changes in practice

Good news, as so often with DMARCbis: on the publishing side, almost nothing. There's no tag to add to "enable" the Tree Walk: it's a change in how receivers evaluate a domain, not in what gets published. Two practical implications all the same:

• More predictable attribution, especially for organizations with complex trees (cascading subdomains, multiple brands). Fewer surprises where a subdomain is mis-attributed.
• The interaction with np. The Tree Walk is also what lets a receiver judge that a subdomain is "non-existent" (it resolves at no level), and therefore apply the np tag. The two new features complement each other.

And the psd tag in all this?

DMARCbis also introduces psd, a marker for public suffix domains themselves (registry operators, for example a .gov.uk). It helps the Tree Walk know where to stop in special cases — typically, marking that a level is a public suffix and not an organizational domain. For the overwhelming majority of organizations, psd isn't a direct concern: it mainly matters to TLD and public-domain administrators. What matters on the publishing side is that this marker makes the Tree Walk reliable all the way to the top of the tree.

A detail that matters for compliance

Replacing a hand-maintained list with native DNS resolution isn't just technical elegance: it's also an auditability argument. An alignment decision based on public DNS is reproducible and explainable — anyone can replay the Tree Walk and get the same result. For organizations that must document their controls (see banks), that's a healthier basis than a dependency on a third-party file.

A Tree Walk, step by step

Let's make the mechanism tangible with a concrete example. A message arrives with From: alert@notifications.payments.my-bank.com. The receiver wants to find the organizational domain. Here, simplified, is how it goes:

1. It looks for a _dmarc.notifications.payments.my-bank.com record — nothing.
2. It climbs one level: _dmarc.payments.my-bank.com — nothing.
3. It climbs again: _dmarc.my-bank.com — found: v=DMARC1; p=reject; np=reject; ….

The organizational domain is therefore my-bank.com, and its policy applies. All in three queries, well under the eight-query cap. If, climbing up, no record had been found all the way to the public suffix (.com), the receiver would have concluded the domain isn't DMARC-protected. And if notifications.payments.my-bank.com had resolved at no level, the organizational domain's np tag would have applied.

PSL vs Tree Walk: the comparison

	Public Suffix List	DNS Tree Walk
Source	Hand-maintained external file	DNS itself
Freshness	Depends on each implementation's update	Always current (live resolution)
Consistency	Can vary between receivers	Deterministic, identical for all
Cost	Embed and keep a list updated	Up to 8 DNS queries (cached)
Auditability	Opaque (depends on a list version)	Reproducible by anyone

The Tree Walk has a cost — a few extra DNS queries — but they're cached and capped at eight. In exchange, attribution becomes reliable and identical everywhere, no longer dependent on a third-party file.

What it means for the wider ecosystem

There's a side effect worth noting: the Tree Walk lowers the barrier to implementing DMARC correctly. Under the PSL model, every mail receiver — not just the giants — had to ship a copy of the list, track its updates, and rebuild whenever it changed. Smaller operators often skipped that maintenance, which is exactly how divergent alignment decisions crept into the ecosystem. With the Tree Walk, a correct implementation only needs what a mail server already has: a DNS resolver. Fewer moving parts means more receivers evaluating a domain the same way, including the long tail of modest servers that nobody audits. For publishers, that consistency is the real prize — a policy means the same thing everywhere it's read.

Frequently asked questions about the Tree Walk

Does the Tree Walk need to be "enabled"? No. It's a receiver-side change, in how a domain gets evaluated. There's no tag to publish for it, and nothing to do.

Does the Tree Walk slow down email reception? In practice, no. The eight queries maximum are cached by resolvers, and most cases resolve in two or three queries. The impact is negligible against the rest of message processing.

What about single-level domains (example.com)? The Tree Walk finds the DMARC record at the first or second level. The flatter the tree, the faster — most domains are in this case.

What if two levels each have a DMARC record? The Tree Walk stops at the first one it meets climbing up, which becomes the reference organizational domain. That's why a subdomain can have its own policy while sitting under its parent's.

Edge cases and best practices

A few situations deserve a word. Very deep trees (four or five subdomain levels) stay covered: the Tree Walk climbs up to eight levels, well beyond real-world needs. Multi-brand domains (a group running brand-a.com, brand-b.com) each keep their own organizational domain — the Tree Walk treats them independently, as it should. Redirects and CNAMEs change nothing: what matters is the presence of a _dmarc record at a level, not the nature of the other records.

Best practice: publishing the DMARC policy at the organizational domain level, not just on an isolated subdomain. That's the level the Tree Walk will find for all the subdomains beneath it, and it carries the "default" protection for the whole namespace. A subdomain can then have its own more specific policy if needed, but the foundation sits at the organizational root.

Finally, the Tree Walk is invisible from the publishing side: it never gets "configured." The only lever is the record itself. To check how a domain is interpreted, an analyzer shows the effective policy as seen from the receiving side.

There's also a quiet reliability benefit worth appreciating. Because the Tree Walk reads live DNS rather than a cached list, the day a subdomain is published or removed, receivers see the change as fast as DNS propagates — no waiting for a third-party list to catch up. DNS becomes the single, authoritative source of truth for how a domain tree is evaluated, which is exactly where that decision belongs.

In short

The DNS Tree Walk replaces the Public Suffix List for determining a name's organizational domain: DMARCbis queries DNS step by step (eight queries maximum) instead of depending on an external list. The result: deterministic attribution, identical for all, auditable, and always current. Nothing needs publishing for it — it's a receiver-side change.

Thomas handles the protocol details

Organizational domain, Tree Walk, psd: these are DMARCbis's internal gears, the ones nobody should have to operate by hand. Thomas, the virtual CISO, reasons about a domain's real tree, generates the coherent policy at each level (root, real subdomains, non-existent ones), and names exactly what to publish.

Free domain analysis or creating an account. For the full context, see this new standard explained simply and the np tag.