Why is DMARC failing for my subdomain, and how does the Public Suffix List affect DMARC alignment?
Updated on 11 Oct 2026: We updated this guide to clarify subdomain alignment, DNS Tree Walk behavior, and forwarding failures.
DMARC can fail for your subdomain even when SPF and DKIM pass because neither passing authenticated domain meets the alignment rules for the visible From address. In the common case, a subdomain such as m.example.com should match example.com under relaxed DMARC alignment. Receivers implementing RFC 9989 calculate that boundary with a DNS Tree Walk, while legacy RFC 7489 implementations can still let the Public Suffix List change the result.
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.
- Boundary mismatch: 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: A DNS Tree Walk and a legacy PSL snapshot can produce different results; check the receiver's reported method before attributing a failure to either.
- Practical fix: Use exact-domain alignment where possible and publish explicit DMARC records for every active Author Domain.
Why SPF and DKIM pass but DMARC fails
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. The Author Domain is the domain in the visible From header (RFC5322.From); SPF uses the envelope sender (RFC5321.MailFrom), commonly shown in Return-Path.
The aspf tag controls SPF alignment and adkim controls DKIM alignment. Each defaults to r (relaxed); s (strict) requires an exact domain match. A child domain therefore fails strict alignment with its parent even when the PSL is not involved.
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 shares an organizational boundary with the bare parent. 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.
Hypothetical legacy PSL failure when example.com is listedtext
Authentication-Results: mx.example; dkim=pass header.d=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 configured alignment mode and 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
Legacy DMARC alignment flowchart comparing Header From with SPF and DKIM domains through a PSL lookup.
The Public Suffix List was built for web boundaries such as cookies. 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. For mail.example.co.uk, the suffix co.uk makes example.co.uk the organizational domain, rather than co.uk. The legacy calculation is defined in RFC 7489.
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.
The following examples assume relaxed alignment, a valid applicable DMARC policy, and a passing SPF or DKIM check for the authenticated domain. The PSL-parent rows are hypothetical, not claims that example.com is listed.
|
|
|
|
|
|---|---|---|---|---|
Normal parent | example.com | m.example.com | Same organizational domain | Pass |
PSL parent | example.com | m.example.com | Child is a separate organizational domain | Fail |
Same child | m.example.com | m.example.com | Exact domain match | Pass |
Old snapshot | example.com | m.example.com | Depends on cached PSL entries | Varies |
Legacy RFC 7489 results under relaxed alignment
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. A valid record with psd=n or psd=y stops the walk; a record without either marker does not necessarily stop it.
- psd=n: The domain containing this tag is treated as the organizational domain.
- psd=y: When found above the starting domain, this marks a Public Suffix Domain, so the organizational domain is one label below it.
- No boundary marker: Without a decisive psd=n or psd=y marker, the valid DMARC record found at the name with the fewest labels sets the organizational domain. If no record determines that boundary, the starting domain is used.
- 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 by itself correct the sending identities. Under DNS Tree Walk, a record can also affect the organizational boundary; confirm both effects before changing it.
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 under RFC 9989; legacy receivers check the PSL-derived organizational domain.
- 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. IN TXT ( "v=DMARC1; p=quarantine; sp=none; " "rua=mailto:dmarc@example.com; adkim=r; aspf=r" )
In this single TXT record, p=quarantine applies to example.com, while sp=none applies to existing subdomains that inherit it. The quoted strings are concatenated. If sp is absent, p is used; RFC 9989 also supports np for non-existent subdomains. These policy tags do not change alignment or turn a failure into a pass.
How to diagnose subdomain DMARC failures
Start with the raw headers, not the DNS zone alone. The DNS records tell you what should happen, but the Authentication-Results header added by the receiving system tells you what it actually evaluated. Compare one failing message with one passing message. Trust the receiver's own result rather than an arbitrary upstream header, as explained in RFC 8601.
For a DNS configuration check, run the domain through Suped's domain health checker, then inspect the specific DMARC TXT record with the DMARC checker. These checks catch record syntax issues; message headers and aggregate reports are still needed to 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 for that identity, not just HELO.
- DKIM identity: List every passing DKIM d= domain. One passing aligned signature is enough for DMARC. The selector s= and identity i= do not set the DMARC signing domain.
- Alignment mode: Read aspf and adkim in the policy the receiver applied, including any subdomain override. Strict mode requires exact matching independently for each method.
- Discovery method: Check policy_published/discovery_method for psl or treewalk when an RFC 9990 report includes it. This optional field describes policy discovery; its absence does not identify the receiver's method.
- Report data: Compare results by receiver and distinguish auth_results (raw SPF and DKIM authentication) from policy_evaluated (DMARC alignment results). A raw pass and a DMARC fail are consistent when domains do not match.
The reporting fields are defined in RFC 9990. A report's disposition records the action taken, not proof of authentication or inbox placement. If discovery_method is missing, use receiver documentation or support alongside the message headers rather than guessing from the provider name.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
Suped's DMARC monitoring product groups aggregate reports by sending source and receiver. Use the reported SPF and DKIM domains to identify mismatched identities, compare affected receivers, and check new reports after a sending configuration change.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Rule out third-party sender and forwarding failures
A third-party sender can authenticate its own domain while using your subdomain in the visible From address. If neither its Return-Path domain nor a passing DKIM d= domain matches your From domain under the configured mode, DMARC fails without any PSL issue. Configure custom DKIM signing and a custom Return-Path where supported.
Forwarding changes the delivery path and needs a different diagnosis. RFC 7960 explains how indirect delivery breaks authentication even when the original sender is configured correctly.
- If direct mail passes but forwarded mail fails, check whether the forwarding server's IP caused SPF failure. Do not authorize unrelated forwarding servers in your SPF record.
- A surviving DKIM signature with DMARC alignment can still produce a pass. A mailing list footer or changes to signed headers can invalidate that signature.
- Sender Rewriting Scheme (SRS) can restore SPF authentication for a rewritten envelope sender, but a forwarder's unrelated domain still lacks DMARC alignment with the original From domain.
- Authenticated Received Chain (ARC) can help a receiver evaluate earlier authentication results through a trusted intermediary. It does not change a DMARC fail into a DMARC pass.
ARC processing and receiver trust are described in RFC 8617. Compare direct and forwarded samples before changing a domain boundary or increasing enforcement.
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.
- Exact-domain 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: Suped's hosted DMARC product supports policy changes when DNS ownership and email operations 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 Policy name: _dmarc.mail.example.com
SPF records do not inherit the parent domain's record. Publish the sender's required SPF configuration at the actual MailFrom domain. Adding a provider's SPF include authorizes infrastructure; it does not change the Return-Path or DKIM signing domain. SPF processing is defined in RFC 7208.
Suped workflow
In Suped's DMARC reporting product, identify the legitimate source and its reported authentication domains, correct the sender configuration, then compare subsequent results by receiver. Use the issue's fix steps and alerts to check that the intended mail stream passes before changing its policy.
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 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 evidence: Confirm the fix by receiver in aggregate DMARC data before increasing enforcement.
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 avoids this boundary difference during the transition.
Verify the fix before changing enforcement
Confirm that legitimate direct mail passes DMARC at each affected receiver after the sender and DNS changes take effect. Use the receiver's authentication results and subsequent aggregate reports to verify the intended From, MailFrom, and DKIM d= domains. A DMARC pass does not guarantee inbox placement.
Keep alignment mode and enforcement policy separate: strict alignment requires exact matching, while p controls the requested handling of failures. Test forwarding and mailing list delivery before tightening enforcement. RFC 9989 advises against p=reject for general-purpose email domains because legitimate indirect mail can fail DMARC; assess dedicated transactional streams separately.
