The DNS Tree Walk in DMARCbis, and what it means for your subdomains
DMARCbis swaps the Public Suffix List for a DNS Tree Walk to find your policy, capped at eight queries. What that changes, and why your subdomains need their own records.
DMARCbis changed how a receiving mail server works out which DMARC policy applies to a given message. The old method leaned on a big public list of domain suffixes. The new method, called the DNS Tree Walk, asks DNS directly and stops after eight queries. The practical takeaway: if a subdomain sends mail you care about, give it its own DMARC record, so receivers land on the policy you intend rather than one they had to guess at. This is a follow-up to our overview of what RFC 9989 changes.
Why receivers have to look further than one record
When a message arrives claiming to be from news.yourbusiness.com, the receiver first looks for a DMARC record at that exact name. If it finds one, that record wins and the search is over. Simple enough.
The interesting case is when there is no record there. A business might send from news.yourbusiness.com without ever publishing a DMARC record on that subdomain. The receiver still needs a policy to apply, so it climbs upward looking for one on a parent domain, for example the DMARC record on yourbusiness.com. That climb is the part DMARCbis rewrote.
The old way: the Public Suffix List
To climb sensibly, a receiver has to know where your organization’s domain actually stops. It must not climb past yourbusiness.com into com.au, because com.au is a public boundary shared by thousands of unrelated businesses, not something any one company controls.
The old standard answered this with the Public Suffix List, a large community-maintained file naming every public boundary like com.au, co.uk and so on. Software downloaded and consulted that list to know when to stop climbing. It worked, but it had real drawbacks: the list had to be bundled into every mail system, kept up to date, and it lived outside DNS entirely. A domain owner had no direct say in it.
The new way: the DNS Tree Walk
DMARCbis drops the list and asks DNS itself. The receiver walks up the domain name one label at a time, checking for a DMARC record and for signals about where the organisational boundary lies, using the live DNS data your domain already publishes.
To keep this from spiraling into an unbounded number of lookups on deeply nested names, the tree walk is capped at eight DNS queries. If it has not resolved a policy within that budget, it stops. Eight is comfortably enough for normal domain structures, but it is a real limit, and it is one more reason not to bury important mail under many layers of subdomain.
The win is that the answer now comes from DNS, the same place everything else about your domain lives, rather than from a separate file that every vendor had to ship and refresh.
What this means for you in practice
The headline advice is short: publish an explicit DMARC record on any subdomain or author domain that sends mail that matters.
Here is why it matters. If news.yourbusiness.com has no record of its own, its policy is decided by whatever the tree walk finds on a parent domain, filtered through the sp (subdomain policy) tag if you set one. That may well be the policy you want. But relying on the climb means you are trusting the receiver to resolve the right answer within eight queries, across DNS setups you do not control, for every provider your customers use. When you publish a record directly on the subdomain, there is no climbing and no guessing. The receiver finds your policy immediately and applies exactly what you wrote.
This is doubly true for anything in enforce territory. A subdomain you use for invoices, password resets or customer notifications is exactly the kind of name a scammer wants to forge. An explicit record on it, at p=reject once its mail is authenticating, removes any ambiguity about what receivers should do with a forgery.
A worked example
Say you send:
- Your normal business mail from
yourbusiness.com. - Marketing from
news.yourbusiness.com. - Nothing at all from
internal.yourbusiness.com.
The clean setup is a record on the organisational domain, for example v=DMARC1; p=reject; sp=reject; rua=mailto:reports@yourbusiness.com, plus a dedicated record on _dmarc.news.yourbusiness.com tuned to how your marketing platform authenticates. The internal subdomain, which sends no mail, is covered by your sp policy and by the non-existent-subdomain protections we cover in DMARC for subdomains and parked domains. Nothing is left to a guess.
What has not changed
The tree walk decides which record applies. It does not change what a DMARC record means, how alignment works, or what your policy values do. p=none still only monitors, p=quarantine still sends failures to spam, and p=reject still refuses them. Your records still start with v=DMARC1. If your domain is a single name with no meaningful subdomain mail, you may never notice the tree walk exists, and that is fine.
Where to start
If you are not certain which of your subdomains send mail, or what policy a receiver would actually resolve for them today, run the free DMARC checker against the names you use. It analyzes what is live and tells you where the gaps are. The rule of thumb is easy to hold onto: every subdomain that sends mail worth protecting deserves its own record, so the answer never depends on how far a receiver is willing to climb.