DMARCbis Replaces the PSL with DNS Tree Walk: What's the Difference?

Freddie Leeman -

A central concept in DMARC is the Organizational Domain. It plays two key roles:

  1. It defines the fallback domain used to look up a DMARC policy when no DMARC record is found at the exact domain from the "From" header.
  2. It provides the domain against which relaxed alignment is evaluated for SPF and DKIM authentication.

Correctly identifying the Organizational Domain is therefore critical for both policy discovery and determining whether an email passes DMARC alignment checks. The new DMARCbis update introduces a significant improvement in how this domain is determined—replacing the outdated and externally maintained Public Suffix List (PSL) approach with a more robust and DNS-native mechanism: the DNS Tree Walk. Here’s a quick breakdown of the change.

DMARC and the Public Suffix List (RFC 7489)

Under the current DMARC standard, record discovery works like this:

  1. First, check the domain in the “From” header — for example, user@sub.mail.example.com. This means querying the DNS for a DMARC record at _dmarc.sub.mail.example.com.
  2. If no valid DMARC record is found there, check the organizational domain, which is determined using the Public Suffix List (e.g., example.com if .com is the public suffix).

Importantly:
No intermediate subdomains like mail.example.com or sub.mail.example.com are checked unless they are the exact domain or the organizational domain.

This approach depends on the PSL, which is:

  • Maintained outside the DNS infrastructure
  • Complex and occasionally inconsistent
  • A barrier for minimal or embedded implementations

Enter: DNS Tree Walk in DMARCbis

In DMARCbis, the PSL is replaced by a DNS Tree Walk, a DNS-native mechanism that checks for DMARC records up the domain hierarchy, one label at a time. The walk is subject to a label limit: if the domain has fewer than 8 labels, the walk proceeds one label at a time from left to right; if the domain has 8 or more labels, it removes left-most labels until only 7 remain before continuing. This method determines the Organizational Domain based on where valid DMARC records are found.

Using the example user@a.mail.example.com, the lookup process checks:

  1. _dmarc.a.mail.example.com
  2. _dmarc.mail.example.com
  3. _dmarc.example.com
  4. _dmarc.com

At each step, it looks for valid DMARC policy records. The Organizational Domain is determined using the following rules (in order):

  1. If a DMARC record has psd=n, that domain is the Organizational Domain.
  2. If a DMARC record higher up has psd=y, then the Organizational Domain is the domain one level below that in the DNS hierarchy.
  3. Otherwise, the domain with the fewest labels (highest in the hierarchy) where a DMARC record is found becomes the Organizational Domain.

Examples from the draft:

  • If _dmarc.mail.example.com has psd=n, then mail.example.com is the Organizational Domain.
  • If only _dmarc.example.com has a valid record and psd=y, then the Organizational Domain is mail.example.com.
  • If the only valid record is at _dmarc.com with psd=y, the Organizational Domain is example.com.

Why This Matters

  • Better consistency: The DNS is the source of truth—no need for external lists.
  • Simpler implementation: No PSL to parse or update.
  • More flexible: Subdomains can now define their own DMARC boundaries.
  • Clearer debugging: You can see exactly what DNS lookups are made.

Do Domain Owners Need to Change Anything?

For most domain owners, the shift to DNS Tree Walk does not require any immediate changes to existing DMARC setups—especially if a valid DMARC record is already published at the base domain (e.g., example.com).

However, domain owners should:

  • Review current DMARC records: Ensure that your organizational domain has a valid DMARC policy in place. This is now more important than ever, as subdomains will inherit policy based on DNS hierarchy, not a predefined suffix list.
  • Audit subdomain configurations: If you rely on subdomain-level policies or have complex structures (e.g., mail.example.com, auth.mail.example.com), double-check that your intended fallback and inheritance behavior is still met under the DNS Tree Walk logic.
  • Consider using the psd tag: If you want to explicitly control how your domain is treated during the tree walk (e.g., to define a PSD boundary or block policy inheritance), you may want to explore the use of psd=n or psd=y in your DMARC record.

In short, if your current setup is simple and your base domain is protected with a DMARC policy, you're likely already covered. But the Tree Walk model does give you more flexibility and control—if you're ready to take advantage of it.