Why is DMARC failing for my subdomain, and how does the Public Suffix List affect DMARC alignment?
Updated on 4 Aug 2026: We updated this guide for RFC 9989's DNS Tree Walk and the transition away from PSL-based DMARC discovery.
DMARC is failing for your subdomain because the authenticated domain used by SPF or DKIM does not match the organizational domain of the visible From address under the receiver's calculation. In the common case, a subdomain such as m.example.com should match example.com under relaxed DMARC alignment. Current RFC 9989 receivers calculate that boundary with a DNS Tree Walk, while legacy RFC 7489 implementations can still let the Public Suffix List change the result.
That transition is the trap. A root DMARC record can still apply to subdomains for policy lookup, but that does not make every subdomain match the root domain for SPF or DKIM. Policy discovery and identifier matching are separate checks. Teams often mix those up when the DMARC record has aspf=r and adkim=r, then expect any branded subdomain to match the root From domain.
- Main cause: The receiver calculates different organizational domains for the Header From and the passing SPF or DKIM identifier.
- Legacy PSL effect: A parent on the PSL can make each child subdomain count as a separate registrable domain under RFC 7489 processing.
- Receiver variance: One receiver can use RFC 9989's DNS Tree Walk while another still uses a PSL snapshot, producing different results.
- Practical fix: Use exact-domain alignment where possible and publish explicit DMARC records for every active Author Domain.
The direct answer
DMARC passes only when SPF passes with an aligned MailFrom domain, or DKIM passes with an aligned signing domain. With relaxed alignment, the match is based on the organizational domain. For ordinary domains, m.example.com and example.com normally match because their organizational domain is example.com.
Under legacy PSL processing, the calculation changes if example.com is treated as a public suffix. The organizational domain of m.example.com becomes m.example.com, so it no longer matches the bare example.com value. SPF and DKIM can each pass authentication while DMARC fails alignment. An RFC 9989 receiver instead uses DMARC records found through a DNS Tree Walk to determine the organizational domain.
Legacy PSL result that can failtext
Authentication-Results: mx.example; dkim=pass header.i=@m.example.com header.s=smtp; spf=pass smtp.mailfrom=bounce@m.example.com; dmarc=fail header.from=example.com
The important distinction
A root DMARC policy can be found and applied to a subdomain, but that policy lookup does not prove SPF or DKIM has DMARC alignment. The message still needs one passing authentication method whose domain matches the Header From domain under the receiver's organizational-domain rules.
For a deeper refresher on how the relaxed mode comparison works, see relaxed alignment. That distinction matters before you start changing DNS records.
How the Public Suffix List changes the result
Flowchart showing how DMARC compares Header From, SPF, DKIM, and PSL lookup.
The Public Suffix List was built for web boundaries such as cookies and storage. RFC 7489 reused that boundary to decide the organizational domain for DMARC policy discovery and relaxed alignment. That approach worked for common public suffixes such as com and org, but private service domains on the list could create unexpected email boundaries.
If a domain hosts independent customer sites under subdomains, the web security reason for PSL inclusion is clear: customer-a.example.com should not be able to set cookies for customer-b.example.com. Under legacy DMARC processing, the same entry can make those child domains separate organizations for email alignment.
|
|
|
|
|
|---|---|---|---|---|
Normal parent | example.com | m.example.com | same org | pass |
PSL parent | example.com | m.example.com | different org | fail |
Same child | m.example.com | m.example.com | exact domain | pass |
Old snapshot | example.com | m.example.com | stale PSL | varies |
Legacy RFC 7489 interpretations of the same domains
This still explains some receiver disagreements. PSL data is not always fetched live. It can be copied into libraries, compiled into binaries, and updated on the receiver's schedule. A domain removed from the PSL can remain a public suffix to software using an older snapshot.
How RFC 9989 changed alignment discovery
RFC 9989 replaced RFC 7489 in May 2026 and removed the current standard's dependency on the Public Suffix List. A compliant receiver now performs a DNS Tree Walk for DMARC policy discovery and, when relaxed alignment requires it, for the Author Domain and each passing SPF or DKIM identifier.
The receiver queries DMARC records while moving up the DNS name, with no more than eight queries in one walk. The records found on that path determine the organizational domain. This makes the boundary visible in DNS instead of depending on a separately maintained PSL snapshot.
- psd=n: The domain containing this tag is treated as the organizational domain.
- psd=y: The domain is a Public Suffix Domain, so the organizational domain is one label below it.
- No psd tag: The valid DMARC record found at the name with the fewest labels sets the organizational domain.
- Transition risk: A Tree Walk receiver and a legacy PSL receiver can calculate different organizational domains for the same message.
The interoperable configuration
RFC 9989 says strict alignment plus explicit DMARC records for every Author Domain avoids this Tree Walk and PSL interoperability issue. Exact-domain alignment is the clearest option during the transition, even when relaxed alignment remains configured for other mail streams.
Policy inheritance is separate from matching
Subdomains can inherit the organizational domain's DMARC policy when they do not publish their own DMARC record. That is policy discovery. It tells the receiver what policy to apply after it evaluates SPF, DKIM, and DMARC alignment.
A separate subdomain DMARC record can override the inherited policy for that subdomain. The subdomain DMARC records question matters, but it does not solve a mismatch between the visible From domain and the authenticated identifier.
Policy lookup
- Purpose: Find the DMARC record that controls the domain in the Header From address.
- Fallback: Use the DNS Tree Walk when the exact Author Domain has no record.
- Output: A policy such as none, quarantine, or reject.
Identifier matching
- Purpose: Compare the Header From domain with the SPF MailFrom or DKIM signing domain.
- Method: Use exact matching in strict mode or organizational-domain matching in relaxed mode.
- Output: A DMARC pass or fail decision for that message.
Root DMARC policy with subdomain policydns
_dmarc.example.com. TXT "v=DMARC1; p=quarantine; sp=none;" "rua=mailto:dmarc@example.com; adkim=r; aspf=r"
That record can tell receivers what to do with mail using subdomains, but it does not make m.example.com and example.com align when the receiver calculates different organizational domains for them.
How to diagnose it
Start with the raw headers, not the DNS zone alone. The DNS records tell you what should happen, but the Authentication-Results header tells you what the receiver actually evaluated. Compare one failing message with one passing message.
For a quick outside check, run the domain through the Suped domain health checker, then inspect the specific DMARC TXT record with the DMARC checker. These checks catch record syntax issues before you investigate receiver-specific discovery behavior.
- Header From: Find the domain users see in the From address. DMARC starts there.
- SPF identity: Check the envelope sender in smtp.mailfrom and confirm SPF passed.
- DKIM identity: List every passing DKIM d= domain. One passing aligned signature is enough for DMARC.
- Discovery method: Determine whether the receiver used the RFC 9989 DNS Tree Walk or a legacy PSL snapshot.
- Report data: Compare results by receiver and inspect discovery_method when the RFC 9990 aggregate report includes it.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
Suped's product groups DMARC, SPF, DKIM, blocklist (blacklist) monitoring, and deliverability signals in one place. For this failure mode, use its automated issue detection and receiver-level patterns to separate authentication failure from alignment or discovery differences. DMARC monitoring reduces the time spent comparing XML reports by hand.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
How to fix the sending setup
The reliable fix is to make the visible From domain and at least one passing authenticated domain match exactly. That works under strict alignment, RFC 9989's DNS Tree Walk, and legacy PSL interpretations. Also publish an explicit DMARC record for each Author Domain used in active mail.
A practical pattern uses a dedicated mail subdomain for the visible From and DKIM signing domain. The bounce domain can use the same exact domain when the sending service supports it, although an exact DKIM match alone is enough for DMARC when that signature passes. If the brand requires a root-domain From address, sign with the root domain.
- Best path: Use mail.example.com in the From address and DKIM d= value, with a matching bounce domain where supported.
- Root path: If users must see example.com, sign with example.com instead of relying only on a child-domain identity.
- Policy path: Publish an explicit DMARC record for every Author Domain that sends mail.
- Hosted path: Use hosted DMARC when policy staging and DNS ownership are split across teams.
Exact-domain patterntext
Header From: alerts@mail.example.com DKIM d=: mail.example.com SPF MailFrom: bounce@mail.example.com DMARC: pass when SPF or DKIM passes
Suped workflow
Suped connects receiver trends and authenticated-source detection to hosted DMARC policy staging, alerts, and specific fix steps. Use that workflow to verify the aligned source, watch each receiver's results, and confirm the change before increasing enforcement.
Do not treat a short DKIM signature lifetime as the root cause unless the failing messages are delayed past the signature expiry. A two-hour expiry can make mail less robust during throttling or receiver outages, but it is a separate DKIM validation issue, not an organizational-domain alignment problem.
What to do if your domain was on the PSL
If your domain was ever on the Public Suffix List, removing it does not instantly fix every legacy receiver. Some software uses old embedded PSL data, while current RFC 9989 implementations use DNS Tree Walk. You control your DNS and sending identifiers, but you do not control every validator's implementation.
Mitigate the difference by avoiding a bare-domain From address when the stream authenticates only with a child subdomain. Match one authenticated identifier exactly to the visible From domain, then publish an explicit DMARC record at that Author Domain.
Avoid
- Mixed domains: Root From address with SPF or DKIM authenticated only at a child subdomain.
- PSL dependence: Waiting for every legacy receiver and library to refresh its public suffix data.
- Record guessing: Adding duplicate DMARC records without checking the actual authenticated domains.
Prefer
- Exact match: Match the From domain exactly with a passing DKIM or SPF identity.
- Explicit policy: Publish a valid DMARC record for every Author Domain used to send.
- Report proof: Confirm the fix by receiver in aggregate DMARC data before enforcing reject.
Platforms that host independent customer sites under subdomains still need to consider both methods before joining the PSL. The web isolation benefit can be real, but legacy DMARC software can set the email boundary at the same point. RFC 9989 removes the PSL dependency for updated receivers, yet exact-domain alignment remains safer during the transition.
Views from the trenches
Best practices
Compare Header From, SPF MailFrom, and DKIM d domains before editing any DNS records.
Check whether each receiver used a DNS Tree Walk or a legacy PSL snapshot for DMARC.
Publish explicit DMARC records for every Author Domain used by an active mail stream.
Keep DKIM signature expiry long enough to survive throttling and temporary MX delays.
Common pitfalls
Assuming a root DMARC policy proves every subdomain-authenticated message will pass.
Debugging only visible DNS records instead of checking the receiver's header result.
Expecting RFC 9989 adoption to replace every older PSL-based implementation at once.
Mixing a bare From domain with child-domain DKIM and SPF on sensitive mail streams.
Expert tips
Test one passing and one failing message, then compare every authenticated domain value.
Treat receiver disagreements as a clue to compare Tree Walk and PSL discovery methods.
Use exact-domain alignment so either current or legacy discovery gives the same result.
Move high-risk traffic before reject enforcement when domain discovery results differ.
Expert from Email Geeks says a child subdomain should normally pass relaxed DMARC matching, so an unexpected failure often points to DNS boundary handling or Public Suffix List data.
2025-02-04 - Email Geeks
Expert from Email Geeks says a domain that appears in an older Public Suffix List snapshot can make the child subdomain's organizational domain differ from the bare parent.
2025-02-05 - Email Geeks
The practical takeaway
DMARC is not failing because subdomains are forbidden. It is failing because the receiver does not see the Header From domain and a passing authenticated domain as aligned. Current RFC 9989 receivers use DNS Tree Walk, while older implementations can still use PSL data to make that decision.
Stop relying on a parent-child comparison when the domain has PSL history or receiver results differ. Match the visible From domain exactly with a passing DKIM d= value or SPF MailFrom domain, publish an explicit DMARC record for that Author Domain, and confirm the result before moving to quarantine or reject.
Suped's product turns receiver-level aggregate results into specific issues, alerts, and fix steps. Use those results when one provider fails mail that another accepts, because the cause is usually visible in the authenticated identifiers and discovery method rather than a single DNS lookup.
