Why Your DMARC Is Failing: The Six Causes in Order of Likelihood
Six causes of DMARC failure, ordered by how often they occur, with the symptom in reports and the fix for each. Alignment accounts for most of them.
DMARC fails when neither SPF nor DKIM both passes and aligns with the From domain. The usual causes, in rough order of frequency, are third-party senders without aligned DKIM, SPF exceeding ten lookups, alignment mismatch, forwarding, unconfigured subdomains, and DKIM key or selector problems.
Key takeaways
- DMARC needs only one of SPF or DKIM to pass and align, so a failure means both failed, which narrows diagnosis considerably.
- Third-party senders without aligned DKIM are the most common cause, because SPF passes for the vendor's domain rather than yours.
- An SPF record over the ten-lookup limit returns permerror, which removes SPF from the equation entirely and often surprises people.
- Forwarding breaks SPF while DKIM usually survives, so it is rarely a reason to delay enforcement.
Reviewed and updated August 11, 2026
A handful of causes account for most of what you will find in a real aggregate report, and they do not occur at anything like equal rates. Working through them in rough order of likelihood turns a vague "our DMARC is failing" into a specific answer in about an hour, while working through them in the order they appear in the specification can take a week.
What follows is that order, with the symptom each one produces, the check that confirms it, and the fix. Three of the six are alignment problems wearing different clothes, which is why alignment gets explained first.
Alignment, because five of the six depend on it
DMARC passes when either SPF or DKIM passes and aligns with the domain in the visible From header. It does not need both. One aligned pass is enough.
Alignment is the part people skip, and skipping it is why so much time gets lost. A message can pass SPF completely legitimately and still fail DMARC, because SPF validates the envelope sender rather than the address your recipient sees. When a third-party platform sends on your behalf using its own return path, SPF passes for the platform's domain, which aligns with nothing you own.
- From header shows yourcompany.com
- Envelope sender is bounces.vendor-platform.com
- SPF passes for the vendor domain
- No DKIM signature carrying your domain
- Nothing aligns, so DMARC fails
- From header shows yourcompany.com
- Envelope sender is on a subdomain you control
- SPF passes for a domain you own
- DKIM signs with a selector on your domain
- At least one aligned pass, so DMARC passes
Two tags control how strict that comparison is. aspf= governs SPF alignment and adkim= governs DKIM alignment, and each takes r for relaxed or s for strict. Relaxed accepts an organisational domain match, so a subdomain can satisfy alignment for the parent. Strict demands an exact match. Both default to relaxed, and moving either to strict without checking your reports first is a reliable way to manufacture failures on mail that was fine yesterday.
Hold that idea while reading the list below, because the top three causes are all versions of it.
- Step 1Third-party senders
Find every platform sending as your domain and check each one signs with DKIM on your domain.
- Step 2SPF lookup count
Expand the record. Over ten DNS-consuming terms means permerror, and permerror is not a pass.
- Step 3Alignment
For sources that pass raw SPF but fail DMARC, compare the envelope domain against the From domain.
- Step 4Forwarding
Isolate the sources where SPF fails and DKIM passes. Usually mailing lists and auto-forwarders.
- Step 5Subdomains
Check whether the failing mail is on a subdomain with no records of its own.
- Step 6DKIM selectors and keys
Confirm the selector in the signature still publishes a key in DNS.
The 2026 specification deprecates pct, rf and ri, adds np for non-existent subdomains, and drops the HELO fallback for SPF. Captured 11 August 2026.
1. Third-party senders without aligned DKIM
By a wide margin the most common cause, and the one that produces the largest failure counts.
Symptom. A high-volume source in your reports that you recognise, showing DKIM failing and SPF either failing or passing for a domain belonging to the vendor. The message counts are large because these platforms send your newsletters, invoices, ticket notifications and calendar confirmations at scale.
How to confirm. Take the source and match it to the tool. Then look for the DKIM setup instructions in that vendor's admin panel. Nearly every serious platform offers domain authentication, generally as two or three CNAME records you publish and they verify. If the vendor's dashboard shows domain authentication as pending or not started, you have found it.
The fix. Publish the records. This is the highest-yield hour of work in the entire exercise, because a single platform is often most of your failing volume. Where a vendor offers no way to sign with your domain at all, you have a genuine decision to make about whether that vendor keeps sending as your domain before you move to enforcement.
2. SPF over the ten-lookup limit
Symptom. SPF fails on every source at once, including your own mail servers, which is the tell that separates this from everything else on the list. A per-source problem produces per-source failures. A broken record produces universal ones.
How to confirm. Expand your SPF record recursively and count the DNS-consuming terms. Over ten and the evaluation returns permerror, which is a failure to evaluate rather than a failure to match. The counting procedure and the reason cold email programmes hit it first are in SPF records for cold email.
The fix. Delete includes for services that do not send from that domain, then flatten or split across subdomains if you are still over. Until it is fixed, DMARC rests entirely on DKIM, so a DKIM problem that would normally be survivable becomes a total authentication failure.
3. Alignment mismatch where SPF genuinely passes
Symptom. The one that wastes the most time. A source shows SPF passing in the raw authentication results and failing in the DMARC evaluation, so the report appears to contradict itself. It does not. Those two fields answer different questions, and telling them apart is the core skill in reading a DMARC report.
How to confirm. Compare the domain SPF passed for against the domain in the From header. If SPF passed for a vendor hostname, or for a domain that is merely similar to yours, alignment failed and DMARC counted the SPF result as a failure.
The fix. Two routes. Get DKIM signing with your domain, which sidesteps SPF alignment entirely and is the more robust option because DKIM survives forwarding. Or configure the platform to use a custom return path on a subdomain you own, which many support and which brings the envelope domain into relaxed alignment with your From domain. Doing both is normal.
4. Forwarding
Symptom. Low-volume sources, often many of them, showing SPF failing and DKIM passing. Frequently mailing lists, university and association addresses, and personal accounts with a forwarding rule.
How to confirm. The signature is the giveaway. Forwarding preserves the message body and headers, so the DKIM signature validates at the destination, while the forwarding server's IP is not in your SPF record so SPF fails there.
The fix. There is nothing to fix on your side, and it is not a reason to delay enforcement. Because one aligned pass is sufficient, a forwarded message with intact DKIM still passes DMARC. Forwarding only becomes a real problem when DKIM is also broken, which puts you back at causes one, two or six. Learn to recognise the pattern so you stop investigating it.
5. Subdomains with no records of their own
Symptom. Failures concentrated on a name like mail.yourcompany.com or notifications.yourcompany.com while the parent domain looks healthy.
How to confirm. Check whether the subdomain publishes its own SPF and DKIM records. A common assumption is that records on the parent cover everything beneath it, and SPF does not work that way: the record is looked up at the exact domain in the envelope sender.
The fix. Publish SPF and DKIM at the subdomain. On the policy side, sp= sets a policy for subdomains and np= sets one for subdomains that do not exist, the latter being new in the 2026 specification and worth publishing because non-existent subdomains are a favourite spoofing surface. The policy tags themselves are covered in DMARC policy not enabled.
This one bites cold email teams specifically, because outbound belongs on separate sending domains, and a separate domain needs the full set of records in its own right. A sending domain with no DMARC record at all is a worse signal than one sitting at monitoring.
6. DKIM key rotation or a missing selector
Symptom. DKIM was passing and is now failing, with no change to SPF and no new senders. Often it starts on one platform and one date.
How to confirm. Read the selector out of the signature in a failing message and query DNS for that selector's key record. If nothing resolves, the key was rotated, expired, or was published in one environment and never in another. Platforms that manage rotation for you use CNAMEs pointing at their infrastructure, and those break when someone tidies up DNS or migrates providers.
The fix. Republish the key. Then decide who owns rotation, because this cause has a habit of returning annually.
- Yes: Every third-party platform sending as your domain has completed DKIM domain authentication
- Yes: The expanded SPF record sits at ten DNS-consuming terms or fewer
- Yes: For each failing source, the domain SPF passed for matches the From domain
- Yes: Sources with SPF failing and DKIM passing have been identified as forwarding and set aside
- Yes: Every subdomain that sends has its own SPF and DKIM records
- Yes: Each DKIM selector in use resolves to a published key
- No: aspf or adkim has been set to strict without checking reports first
Two things that look like failures and are not
Deprecated tags in your record. The 2026 specification retired pct=, rf= and ri=. Receivers ignore deprecated tags rather than rejecting the record, so an old record carrying pct= still functions. It is not the reason anything is failing, though it does mean percentage-based rollout is no longer a plan to build on.
A low pass rate on a brand new record. Aggregate reports are retrospective, arriving daily and covering the previous day. A record published yesterday will show yesterday's mail, including mail sent before your change propagated. Give it three or four days before concluding anything. Ongoing sender reputation is a separate signal, and Google Postmaster Tools is where that side is measured.
The short version
Check in this order: third-party senders without aligned DKIM, an SPF record over the ten-lookup limit returning permerror, alignment mismatches where SPF passes for a domain that is not yours, forwarding, subdomains missing their own records, and DKIM selectors that no longer resolve. The first three are the great majority of failures and all three come back to alignment, which is the requirement that whichever check passes must pass for the domain in the visible From header.
The diagnostic shortcut worth remembering: failures spread evenly across every source point at your SPF record, while failures concentrated on one source point at that sender's DKIM setup. Forwarding shows SPF failing with DKIM passing and needs no action, since one aligned pass is all DMARC requires.
Authentication is a continuous job rather than a setup task, and we run it as part of our outbound engagements alongside domains and sending infrastructure. You can see what a campaign would look like for your market.
DMARC behaviour described here follows RFC 9989, 9990 and 9991, published 20 May 2026, which obsolete RFC 7489. Verify against the current specification before making DNS changes.
Sources: IETF publishes updated DMARC specification, dmarc.org, RFC 7208 section 4.6.4, SPF DNS lookup limits
Frequently asked questions.
Frequently asked questions- Why is my DMARC failing when SPF passes?
- Because DMARC requires alignment, not just a pass. If SPF passes for the domain in the envelope sender but that domain differs from the one in the visible From header, the result does not align and DMARC does not count it. Aligned DKIM signing is the usual fix.
- What is DMARC alignment?
- Alignment means the domain that passed SPF or signed with DKIM matches the domain in the message's visible From header. DMARC checks both authentication and alignment, and passes only when at least one mechanism achieves both. The adkim and aspf tags control whether matching is relaxed or strict.
- Does email forwarding break DMARC?
- It breaks SPF, because the forwarding server is not authorised by your record. DKIM signatures usually survive forwarding intact, and since DMARC passes on either aligned mechanism, correctly aligned DKIM means forwarded mail still passes. This is one reason DKIM matters more than SPF for DMARC.
- Why do my subdomains fail DMARC?
- A policy on the parent domain does not give subdomains their own SPF and DKIM records. Any subdomain that sends mail needs its own authentication configured. The sp tag sets the policy applied to subdomains, and the newer np tag covers subdomains that do not exist at all.
About the author.
Tim Carden is CMO / CTO at RevenueFlow, which builds and operates outbound revenue engines for B2B companies. Studied at McGill University.
Tim Carden · CMO / CTO
Connect on LinkedIn →Explore more.
Ready to scale your outreach?
We build GTM engines that book real meetings. See the receipts.
Related articles.
SPF, DKIM, and DMARC for Cold Email: The Setup That Keeps You Out of Spam
Copy-paste SPF, DKIM, and DMARC records for Google Workspace and Microsoft 365, what each one verifies, and the alignment failures that break cold email.
Smartlead Review: Unlimited Mailboxes, Rotation, and What the Plans Cap
Smartlead includes unlimited mailboxes on every plan and bundles verification on the upper tiers. What rotation does, what it cannot do, and where the ceilings bite.