Why DMARC Fails When SPF and DKIM Pass: The Alignment Trap

29 May 2026 · 13 min read

You publish an SPF record. You publish DKIM. You run a test through a mailbox provider and both come back green: SPF pass, DKIM pass. Then your first DMARC aggregate report lands, and a chunk of your legitimate mail is recorded as dmarc=fail. Nothing is broken in the way you expected. SPF authenticated. DKIM verified. DMARC still failed.

This is the single most common point of confusion in email authentication, and almost every time it comes down to one word: alignment. DMARC does not just ask whether SPF and DKIM passed. It asks whether the domain they passed for matches the domain your recipients actually see in the From header. When the answer is no, you get a passing SPF check, a passing DKIM signature, and a failing DMARC verdict, all on the same message.

This article explains exactly why that happens, how to read a report to find which identifier is misaligned, and how to fix each cause. It is written for the specific symptom in the title, not as a general DMARC primer. If you want the broader concept first, DMARC alignment explained covers the theory; here we stay on the failure mode.

What DMARC actually checks (and why "pass" is not enough)

SPF and DKIM are two independent authentication mechanisms, and each one validates a different identifier in the message. Neither of them, on its own, knows or cares about the From address your recipient reads.

SPF validates the Return-Path domain, also called the envelope sender or MAIL FROM. This is the address bounces go back to. It is set during the SMTP conversation and is usually invisible to the recipient. SPF checks whether the connecting IP address is authorised to send for that domain.
DKIM validates the d= domain in the DKIM-Signature header. The signing server picks the d= value and signs the message with a key published under that domain. DKIM proves the message was signed by whoever controls the key for d=, and that the signed parts were not altered.

Both of these can pass for a domain that is not yours. A marketing platform can pass SPF for its own bounce domain and pass DKIM for its own signing domain. The message is authenticated, just not as you.

DMARC sits on top and adds the rule that ties authentication to the visible brand:

A message passes DMARC if at least one of SPF or DKIM both passes and aligns with the domain in the From: header.

Alignment is the join. It is the comparison between the From domain (what the human sees) and the authenticated domain (what SPF or DKIM proved). If SPF passes for mail.sendgrid.net but your From is you@yourdomain.com, SPF is aligned? No. Different organisational domains. If DKIM signs with d=mailchimpapp.net but your From is yourdomain.com, that signature is not aligned either.

So the precise reason DMARC fails while SPF and DKIM pass is almost always: both checks passed for a domain other than the one in your From header. You authenticated, but as somebody else.

You can confirm a message's three verdicts and their domains with the DMARC checker for the published policy, and by reading the Authentication-Results header, which we cover below.

Identifier alignment versus organisational alignment

Alignment has two modes, and the mode in force changes whether a near miss passes or fails.

Relaxed alignment (the default for both SPF and DKIM) requires the two domains to share the same organisational domain, also called the registered or registrable domain. Under relaxed mode, mail.yourdomain.com aligns with yourdomain.com because both reduce to yourdomain.com. Subdomains of the same registrable domain are treated as aligned.
Strict alignment requires an exact match of the full domain. Under strict DKIM alignment, d=mail.yourdomain.com would not align with a From of yourdomain.com, even though they share an organisational domain.

You set the mode in your DMARC record with the aspf and adkim tags:

v=DMARC1; p=reject; rua=mailto:reports@yourdomain.com; aspf=r; adkim=r

aspf=r is relaxed SPF alignment, aspf=s is strict. adkim=r is relaxed DKIM, adkim=s is strict. If you do not specify them, both default to relaxed, which is what you want in almost all cases.

Here is a trap worth flagging now: if you copied a DMARC record from somewhere and it contains adkim=s or aspf=s, you have quietly opted into strict matching, and a perfectly good signature from a subdomain selector can start failing alignment. Most "SPF and DKIM pass but DMARC fails" tickets on a self-built record trace back to an unnecessary strict tag. Check yours; relaxed is the sane default.

A second subtlety: the organisational domain is computed using the Public Suffix List, not by counting dots. yourdomain.co.uk is the organisational domain, and news.yourdomain.co.uk aligns with it under relaxed mode, because co.uk is a public suffix and the registrable domain is everything one label above it. You do not need to manage that list yourself, but it explains why some country-code domains behave differently from what dot-counting would suggest.

Why SPF passes but does not align: the Return-Path problem

This is the number one cause, and it is structural, not a misconfiguration on your side.

When you send through almost any third-party platform (an email service provider, a CRM, a helpdesk, a transactional API), that platform sets the Return-Path to its own bounce domain so that bounces flow back into its own suppression and feedback systems. A typical Return-Path from a sending platform looks like:

Return-Path: bounces+12345-abcd=yourdomain.com@bounce.theprovider.net

SPF then checks the sending IP against the SPF record of bounce.theprovider.net. That record lists the provider's IPs, so SPF passes. But the domain SPF passed for is theprovider.net, and your From is yourdomain.com. Different organisational domains, so SPF does not align. DMARC's SPF leg fails even though the SPF result is, technically, "pass".

You will see this in a report as SPF result pass with an SPF domain that is not yours, and a DMARC SPF disposition of fail for alignment. The mechanism worked perfectly. It just authenticated the provider, not you.

There are only two ways to make SPF align:

Configure a custom Return-Path (custom bounce domain) at the provider. Most platforms let you point a subdomain of yours, for example bounce.yourdomain.com, at their bounce infrastructure via CNAME or by hosting their SPF include. Now the Return-Path becomes ...@bounce.yourdomain.com, SPF checks your subdomain's SPF record, passes, and aligns under relaxed mode because bounce.yourdomain.com shares the organisational domain yourdomain.com.
Send from your own infrastructure, where the Return-Path is naturally on your domain.

For most people, the better answer is not to chase SPF alignment at all, but to rely on DKIM alignment instead, which is usually far easier to achieve through a third party. DMARC needs only one aligned, passing mechanism. If DKIM aligns, you can stop worrying about SPF alignment entirely. Which one aligns, SPF or DKIM walks through choosing.

You can inspect what SPF currently authorises, and for which domain, with the SPF checker.

Why DKIM passes but does not align: the wrong d= domain

DKIM has its own version of the same trap. Many providers sign every outgoing message with their domain by default, so you see a valid DKIM-Signature and a DKIM result of pass, but the d= value belongs to the provider.

A message from a platform that has not been domain-authenticated often carries a signature like:

DKIM-Signature: v=1; a=rsa-sha256; d=theprovider.net; s=s1; bh=...; b=...

That verifies cleanly. DKIM passes. But d=theprovider.net does not align with a From of yourdomain.com, so the DKIM leg of DMARC fails.

The fix is to complete the provider's domain authentication (sometimes called "branded sending", "authenticated domain", "verified domain" or "DKIM setup"). When you do, the provider publishes a DKIM key under your domain, usually via CNAME records on <selector>._domainkey.yourdomain.com, and then signs your mail with d=yourdomain.com. Many providers add a second signature so the message ends up signed by both theprovider.net and yourdomain.com. DMARC only needs the one that aligns.

After you set it up, confirm the selector resolves and the key is published with the DKIM checker, entering the selector the provider gave you and your domain. If the lookup fails, the CNAME is wrong or has not propagated, and DKIM will fall back to the provider's own signature, which does not align.

A few specific DKIM alignment failures worth knowing:

CNAME typo or doubled domain. Some DNS panels auto-append the zone, so typing selector._domainkey.yourdomain.com produces selector._domainkey.yourdomain.com.yourdomain.com. The selector then does not resolve, the provider falls back to its own d=, and alignment fails. See DKIM selectors explained.
Strict DKIM alignment against a subdomain selector. If your DMARC has adkim=s and the provider signs with d=mail.yourdomain.com, the exact-match requirement fails even though everything is "yours". Relaxed mode would pass it.
Body modification in transit can break the signature itself (a DKIM fail, not just misalignment). That is a different problem, common with forwarding, covered below.

How forwarding produces this exact symptom

Forwarding is the scenario that confuses people most, because the same message can pass at the original recipient and fail at the forwarded destination.

When a mailing list, an alias, or a "forward all my mail" rule relays your message:

SPF breaks completely. The forwarding server connects from its IP, not the original sender's. SPF for your Return-Path now fails because that IP is not in your SPF record. Forwarding rewrites the path, not the SPF record. (Some forwarders use SRS to rewrite the Return-Path to their own domain, which makes SPF pass for the forwarder, but that still does not align with your From.)
DKIM usually survives, because the signature covers message content, not the connection. This is precisely why DKIM is the mechanism you want carrying your DMARC alignment. As long as the forwarder does not modify the signed headers or body, d=yourdomain.com still verifies and still aligns.

So after forwarding you frequently see SPF fail, DKIM pass and align, and DMARC pass overall, which is the system working as designed. The dangerous variant is when a forwarder does alter the message (appends a footer, rewrites links, changes the subject), which breaks the DKIM body hash. Now DKIM fails too, both mechanisms are gone, and DMARC fails on a genuinely legitimate message. DKIM, alignment and forwarding and forwarding and DMARC go deeper. The practical defence is to make sure your direct mail has solid DKIM alignment so that forwarding-induced SPF failures do not matter, and to read your reports so you can tell genuine forwarding from spoofing.

The subdomain and From-rewrite cases

Two more causes produce the same "pass but fail" signature.

Sending from a subdomain you did not set up. If your application sends from notifications.yourdomain.com but you only published SPF and DKIM and a DMARC record on yourdomain.com, the subdomain may inherit the policy (via the sp tag or the organisational record) but not the authentication. The mail can pass SPF or DKIM for the provider while the From is your subdomain, and alignment fails. The fix is to authenticate the subdomain itself. See the subdomain DMARC record and the subdomain policy (sp) tag.

Friendly-From rewriting and "on behalf of". Some platforms send with a From of you@yourdomain.com but a Sender or d= of the platform, and some put the real domain only in a Reply-To. If the visible From is yours but nothing authenticated is yours, DMARC fails despite green SPF and DKIM. The cure is the same: get an aligned identifier on your own domain, normally via DKIM domain authentication.

How to find which identifier is misaligned

You do not have to guess. Two sources tell you exactly which leg failed.

Read the Authentication-Results header on a single message

Open a message in the receiving mailbox, view the original or raw source, and find the Authentication-Results header the receiver stamped on. It looks like this:

Authentication-Results: mx.google.com;
  dkim=pass header.i=@theprovider.net header.s=s1;
  spf=pass (google.com: domain of bounces@bounce.theprovider.net
    designates 198.51.100.7 as permitted sender)
    smtp.mailfrom=bounce.theprovider.net;
  dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=yourdomain.com

Read it as three lines:

dkim=pass header.i=@theprovider.net tells you DKIM passed for theprovider.net. Compare that against header.from=yourdomain.com. Different domain, so DKIM is misaligned.
spf=pass ... smtp.mailfrom=bounce.theprovider.net tells you SPF passed for the provider's bounce domain. Again not your From, so SPF is misaligned.
dmarc=fail ... header.from=yourdomain.com is the verdict, and it confirms that neither passing mechanism aligned with your From.

If instead you saw dkim=pass header.i=@yourdomain.com, that signature is aligned and DMARC would pass on the DKIM leg. The domain printed next to each pass is the whole story. Whichever one matches your header.from, that is your aligned identifier. If neither matches, that is your failure.

For a quick raw-header breakdown without squinting, paste the source into the email header analyzer.

Read your DMARC aggregate reports across all sources

A single message tells you about one path. Aggregate reports (the XML the world emails to your rua address) tell you about every sending source, which is what you need to fix the whole estate rather than one test.

Each record in an aggregate report carries, per sending IP and per source:

the From domain (header_from),
the SPF result and the domain SPF evaluated (the envelope/Return-Path domain),
the DKIM result and the d= domain the signature used,
the resulting DMARC SPF alignment and DKIM alignment (pass or fail),
the count of messages.

The diagnostic move is simple: for any source showing DMARC fail, look at the SPF domain and the DKIM d= domain in that record. If both differ from header_from, you have found a source that authenticates as somebody else. Now you know which provider to go and domain-authenticate.

Raw aggregate XML is unreadable at volume. The DMARC report analyzer parses it and shows, per source, exactly which identifier aligned and which did not, so you can see at a glance that, say, your transactional provider has DKIM aligned but your newsletter tool does not. Reading your first DMARC report is a guided walk-through.

A worked decision: same passes, different fixes

Suppose your analyzer shows two sources both failing DMARC, both with SPF pass and DKIM pass.

Source A, your transactional API:

header_from: yourdomain.com
SPF: pass for bounce.theprovider.net  -> not aligned
DKIM: pass for d=theprovider.net      -> not aligned
DMARC: fail

Both authenticated as the provider. The fix is to complete the provider's domain authentication so DKIM signs with d=yourdomain.com, and optionally set a custom Return-Path on a subdomain of yours for SPF alignment too. DKIM alone is enough to flip DMARC to pass.

Source B, your own mail server behind a forwarder:

header_from: yourdomain.com
SPF: fail (forwarder IP not in your SPF)
DKIM: pass for d=yourdomain.com        -> aligned
DMARC: pass

This one already passes via aligned DKIM, despite SPF failing, because forwarding preserved the signature. No action needed. If you saw DKIM fail here instead, the forwarder is modifying the body, and the fix lies with the forwarding configuration, not your DNS.

Same green SPF and DKIM at the mechanism level, completely different DMARC outcomes and completely different fixes. That is why you must read the aligned column, not the raw pass/fail.

Fix checklist for "DMARC fails, SPF and DKIM pass"

Work through these in order:

Confirm the From domain you are actually sending. Everything is judged against header.from. If it is a subdomain, authenticate that subdomain, not just the root. Try the DMARC checker on the exact domain in your From.
Check your alignment mode. If your DMARC record has adkim=s or aspf=s and you did not deliberately choose strict, change them to relaxed (r) or remove the tags. Generate a clean record with the DMARC generator.
Get DKIM aligned first. Complete domain authentication at each sending provider so they sign with d=yourdomain.com. Verify the selector resolves with the DKIM checker. This is the single highest-value fix because DKIM survives forwarding.
Add SPF alignment only where you need it. Set a custom Return-Path / bounce subdomain at providers that support it, then verify with the SPF checker. Watch the 10-lookup SPF limit while you are in there.
Re-read the reports. After changes propagate, the DMARC report analyzer should show the source flipping to an aligned identifier. Only then is it safe to tighten policy.
Do not raise policy until alignment is clean. Moving to p=quarantine or p=reject while a legitimate source is misaligned will junk or bounce real mail. Reach p=reject without breaking email and the enforcement journey sequence this safely.

The practical takeaway

DMARC failing while SPF and DKIM pass is not a contradiction and not a bug. It is the whole point of DMARC working as intended: it refuses to credit authentication that proves a domain other than the one your recipients see. The mechanism passed; it just passed for the wrong domain. Find the misaligned identifier by reading the Authentication-Results header on one message and the aligned columns in your aggregate reports across all sources, then fix it by giving each sender an identifier on your domain, almost always via DKIM domain authentication, with custom Return-Path SPF alignment as a useful extra.

If you want this diagnosed for you rather than by hand, point a domain at continuous monitoring: the DMARC report analyzer breaks every source down by aligned SPF and aligned DKIM, change alerts tell you the moment a source drifts out of alignment, and our done-for-you service takes the domain from p=none to p=reject without dropping a single legitimate message. Start by running your From domain through the DMARC checker and reading one real Authentication-Results header; the misaligned identifier is usually obvious within minutes.

Why DMARC fails when SPF and DKIM pass