Why DMARC no longer relies on a static public-suffix boundary
Earlier DMARC implementations commonly derived an Organizational Domain by combining the author domain with Public Suffix List data. RFC 9989, published in 2026, replaces that dependency for DMARC with a DNS Tree Walk. The change matters because organizations can publish valid DMARC policy records at more than one level in a namespace, and those records can explicitly mark organizational or public-suffix boundaries. A receiver evaluating relaxed alignment therefore needs evidence from the DMARC DNS hierarchy, not only a registrable-domain calculation.
The walk is intentionally bounded
The algorithm starts with a DMARC TXT lookup at a domain determined by the evaluation being performed and then moves upward through parent names. To prevent an attacker from forcing an excessive number of DNS requests by using a very deep domain name, the standard limits the walk to eight lookups. For very long names, the second lookup can skip several labels so that only seven remain, after which the walk continues upward one label at a time. A diagnostic tool should expose this exact path so the result can be audited.
Only one valid DMARC policy at a target counts
At each target, records that do not begin with the current DMARC version tag are ignored. If more than one valid DMARC policy record exists at the same target, that target is not treated as a valid single policy result. This is an important diagnostic condition: seeing multiple v=DMARC1 strings in a DNS viewer is not evidence of stronger protection. It is configuration ambiguity that can prevent the policy from being used as intended.
psd=n and psd=y define explicit boundaries
A valid record with psd=n identifies that domain as the Organizational Domain and stops the selection process. A record with psd=y marks a Public Suffix Domain; for a walk that encounters such a record above its starting point, the Organizational Domain is the child immediately below that PSD in the DNS hierarchy. These tags allow DMARC to describe boundaries that a generic suffix database could not reliably infer, which is especially relevant to delegated or complex naming structures.
Policy discovery and alignment are related but not identical
The policy applied to a message is sought first at the visible From domain, then at the relevant Organizational Domain, and finally at a Public Suffix Domain when applicable. Relaxed identifier alignment may require separate Tree Walks for the visible From domain and for each passing SPF or DKIM authenticated identifier. Strict alignment avoids that work because it is an exact string comparison. This distinction explains why a policy can be discovered at one point while the Organizational Domain used for relaxed alignment is determined from a broader set of DNS evidence.
How to investigate a real alignment failure
Start with the domains stamped into the delivered or rejected message: visible From, envelope sender and each passing DKIM signing domain. Trace the DMARC Tree Walk for each domain rather than substituting a suffix guess. Record the selected Organizational Domain and the published aspf/adkim modes, then compare only authenticated identifiers that actually passed. Mailybox’s DMARC Alignment Lab performs this live path and the Tree Walk Explorer exposes each queried _dmarc name so the conclusion is reproducible.
Verify the evidence
Use the live analysis that matches this workflow instead of relying on a generic status check.