Why is DMARC failing for my subdomain, and how does the Public Suffix List affect DMARC alignment?
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 domain calculation. In the common case, a subdomain such as m.example.com should match example.com under relaxed DMARC alignment. The Public Suffix List changes that calculation when a parent domain is treated like a public suffix.
That last part 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. I see teams 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, SPF MailFrom, or DKIM d= domain.
- PSL effect: A parent domain on the Public Suffix List makes each child subdomain act like its own registrable domain.
- Receiver variance: Mailbox providers and testing libraries use different PSL snapshots, so one receiver can pass the same message that another fails.
- Practical fix: Use one stable domain for the visible From, DKIM signing domain, and bounce domain wherever the mail stream allows it.
The direct answer
DMARC passes only when SPF passes with a matching MailFrom domain, or DKIM passes with a matching signing domain. With relaxed alignment, the match is normally based on the organizational domain. For ordinary domains, that means m.example.com and example.com match because their organizational domain is example.com.
If example.com is treated as a public suffix by the receiver, the calculation changes. The organizational domain of m.example.com becomes m.example.com. The bare example.com value does not give the receiver the same parent domain to compare against. The result is a DMARC failure even though SPF and DKIM individually pass.
Header pattern 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. DMARC uses the same kind of boundary to decide the organizational domain for email authentication. That reuse works well for normal public suffixes such as com and org, but it gets uncomfortable when a private service domain gets added to the list.
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. Email authentication has a different need. It often wants a parent domain and its controlled mail subdomains to count as the same organization.
|
|
|
|
|
|---|---|---|---|---|
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 | same host | pass |
Old snapshot | example.com | m.example.com | stale PSL | varies |
How the same domains can be interpreted differently
This explains the confusing pattern where one receiver passes the message and another fails it. PSL data is not always fetched live. It is copied into libraries, compiled into binaries, and updated on the receiver's schedule. A domain that was on the PSL between January 8, 2021 and May 2, 2024 can still be treated as a public suffix by software using an older snapshot.
Policy inheritance is separate from matching
Subdomains can inherit the root 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 root 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 organizational domain record when the exact subdomain 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.
- Fallback: Use relaxed organizational-domain matching unless strict mode is configured.
- 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 match when the receiver's PSL logic says they have different organizational domains.
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. I usually trace one failing message and one passing message side by side.
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. The checker helps catch record syntax issues before you move on to receiver-specific PSL 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 matching signature is enough for DMARC.
- PSL snapshot: Check whether the receiver appears to treat the parent as a public suffix.
- Report data: Use aggregate reports to see which receivers fail the same source and which pass it.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
Suped's product is useful after that first check because it groups DMARC, SPF, DKIM, blocklist (blacklist) monitoring, and deliverability signals in one place. For this specific failure mode, I want automated issue detection, receiver-level failure patterns, and clear steps to fix. That is where DMARC monitoring saves time compared with reading 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 authenticated domain match under both old and new PSL interpretations. If a parent domain has PSL history, do not depend on a child subdomain matching that bare parent across all receivers.
The cleanest pattern is a dedicated mail subdomain where the visible From, DKIM signing domain, and bounce domain all use the same branch. If the brand needs a root-domain From address, sign with the root domain and use a matching SPF MailFrom where your provider supports it. If that root has PSL history, move the mail stream to a clean sibling or alternate domain.
- Best path: Use mail.example.com in the From address, DKIM d=, and bounce domain for that mail stream.
- Root path: If users must see example.com, sign with example.com and avoid a child-domain-only authenticated identity.
- Risky path: Do not rely on old receivers updating their PSL snapshots on your schedule.
- Hosted path: Use hosted DMARC when policy staging and DNS ownership are split across teams.
More stable subdomain 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
For most teams, Suped is the best overall DMARC platform because the product connects this diagnosis to action: receiver trends, authenticated source detection, hosted DMARC policy staging, hosted SPF, SPF flattening, real-time alerts, and tailored fix steps.
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 the PSL 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 receiver. Some software uses old embedded PSL data. You control your DNS and sending identifiers, but you do not control every validator's library version.
The practical move is mitigation. Stop using the affected bare domain as the visible From domain for streams that authenticate with child subdomains. Use the exact child domain everywhere, or move email to another domain that has no PSL history.
Avoid
- Mixed domains: Root From address with SPF or DKIM authenticated only at a child subdomain.
- PSL dependence: Waiting for every receiver and library to refresh its public suffix data.
- Record guessing: Adding duplicate DMARC records without checking the actual authenticated domains.
Prefer
- Single branch: Use the same mail subdomain for From, DKIM, and SPF MailFrom.
- Clean domain: Move email to a domain that receivers treat consistently.
- Report proof: Confirm the fix by receiver in aggregate DMARC data before enforcing reject.
This is also why platforms that host customer sites under subdomains need to think carefully before joining the PSL. The web isolation benefit can be real, but email identity gets stricter at the same boundary. Once old snapshots exist in mail software, the safest email design assumes those snapshots will remain in use for years.
Views from the trenches
Best practices
Compare Header From, SPF MailFrom, and DKIM d domains before editing any DNS records.
Check receiver-level DMARC reports because PSL snapshots can differ by mailbox provider.
Use one mail subdomain consistently when a parent domain has any public suffix history.
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 the visible DNS records instead of checking the receiver's header result.
Expecting removal from the Public Suffix List to fix old embedded PSL snapshots quickly.
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 testing-tool disagreements as a clue that separate PSL libraries are being used.
Publish clear records, but design the identifiers so stale PSL data still gives a pass.
Move high-risk traffic before reject enforcement when PSL history affects the domain.
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's organizational-domain calculation does not see the Header From domain and the authenticated domain as the same organization. The Public Suffix List is the piece that can change that result in surprising ways.
The fix is to stop relying on a parent-child comparison that old PSL data can break. Make the visible From, DKIM d=, and SPF MailFrom domains share the same stable branch, then confirm the result in DMARC reports before moving to quarantine or reject.
Suped's product helps here by turning those receiver-by-receiver results into specific issues, alerts, and fix steps. That matters most when one provider fails mail that another provider accepts, because the answer is usually in the headers and aggregate reports, not in a single DNS lookup.
