Why does DMARC fail when SPF and DKIM both pass?

Because of alignment. DMARC does not ask whether SPF and DKIM passed, it asks whether either passed for the domain in the visible From header. SPF checks the envelope sender and DKIM checks its d= signing domain, and a sending platform uses its own domain for both by default. Both checks then pass for the platform and neither aligns to you.

What is DMARC alignment?

The requirement that the domain a check authenticated matches the domain in the From header a reader sees. Relaxed alignment, the default, accepts any subdomain of your organisational domain. Strict alignment, adkim=s and aspf=s, requires an exact match. DMARC passes if either SPF or DKIM aligns.

How do I fix a sending platform that fails DMARC alignment?

Complete the platform's domain authentication step. Custom DKIM signing puts your domain in the d= tag and is the one that matters, because DKIM alignment survives forwarding. A custom Return-Path, where offered, aligns SPF too — some platforms, Mailchimp among them, do not offer one, which is why DKIM comes first.

Why did DMARC start failing after I set adkim=s and aspf=s?

Because you switched from relaxed to strict alignment, which requires the domains to match exactly rather than merely sharing an organisational domain. A platform signing with a subdomain it created for you, or marketing sent from a subdomain while the signature comes from the parent, passes on relaxed and fails on strict. Go back to relaxed until your reports show strict passing.

Should I set p=none to stop DMARC failures?

No. That stops the reports looking bad without fixing anything — p=none blocks nothing, so the problem simply becomes invisible. Alignment is the whole mechanism: a domain whose senders do not align cannot be enforced, which means DMARC protects nobody. Align your senders first, then enforce.

Learn · Reading your report

DMARC fails but SPF and DKIM pass

Every check is green and DMARC still says fail. This is not a bug in your report and it is not a receiver being difficult — it is the one rule that makes DMARC worth anything. DMARC does not ask whether SPF and DKIM passed. It asks whether either of them passed for the domain your reader sees. That extra condition is called alignment, and it is almost always what you are looking at.

The one-sentence version: a spammer can trivially pass SPF and DKIM for a domain they own. Alignment is what stops that from vouching for your domain.

The three domains in every message

A message carries more than one domain, and each check looks at a different one:

The From header — From: billing@yourdomain.com. The only one your reader ever sees, and the only one DMARC cares about protecting.
The envelope sender — also called Return-Path or MAIL FROM. Set by whoever is transmitting, invisible in a normal mail client. SPF checks this one.
The DKIM signing domain — the d= tag in the DKIM-Signature header. DKIM proves this domain signed the message.

DMARC passes only if the envelope sender matches the From domain (SPF alignment) or the d= domain matches the From domain (DKIM alignment). Either one is enough. Both misaligned means DMARC fails, no matter how green the individual checks are.

Why this happens: your sending platform

This is the cause in the overwhelming majority of cases. A marketing platform, CRM, help desk or invoicing tool sends on your behalf, and by default it uses its own domain for both the envelope sender and the DKIM signature. Both checks pass — for the platform. Neither aligns to you.

Open the headers of one of the failing messages and you will see it immediately:

From: news@yourdomain.com
Return-Path: bounces@sendingplatform.net
DKIM-Signature: v=1; d=sendingplatform.net; s=s1; ...

Two green checks, both for sendingplatform.net, zero alignment with yourdomain.com. Your aggregate reports show exactly this: spf and dkim pass in auth_results, and both fail in policy_evaluated, which is the aligned verdict. DMARC aggregate reports explained covers reading those two sections against each other.

The fix

Complete the platform's domain-authentication step — every serious sender has one, usually called "authenticate your domain", "sending domain" or "branded links":

Custom DKIM signing puts your domain in the d= tag. Publish the CNAMEs the platform gives you and its signatures start aligning. Do this one first: DKIM alignment survives forwarding, where SPF alignment does not.
A custom Return-Path (sometimes "custom bounce domain" or "custom MAIL FROM") puts a subdomain of yours in the envelope sender, which aligns SPF too. Not every platform offers it — Mailchimp famously does not, which is why DKIM is the one that matters.

Confirm with the free DKIM checker once the records are live, then send yourself a test and check that d= now names your domain.

Why this happens: you set strict alignment

If your record ends in adkim=s; aspf=s, you asked for strict alignment: the domains must match exactly. Under the default relaxed mode, any subdomain of your organisational domain counts — mail.yourdomain.com aligns with yourdomain.com.

So a setup that passes happily on relaxed can start failing the moment you tighten, typically because a platform signs with a subdomain it created for you, or you send marketing from news.yourdomain.com while the signature comes from the parent.

Strict is the stronger setting and a reasonable destination, but move to it after your reports show it passing, not as part of the same change that enforces your policy. If you have just tightened and mail started failing, drop back to relaxed — remove both tags, or set adkim=r; aspf=r — and reintroduce strict later.

Why this happens: a broken signature in transit

A mailing list that appends a footer, a gateway that rewrites the subject line, an appliance that strips an attachment — all of them alter bytes the DKIM signature covers, and the signature no longer verifies. Meanwhile the relay is not in your SPF record, so SPF fails too.

This is not your configuration and there is nothing to publish. ARC exists to carry the original verdict across those hops, and receivers that honour it will often deliver the message anyway — which is why you sometimes see failures in reports with a disposition of none even under enforcement.

Telling them apart in two minutes

What you see	Cause	What to do
`d=` and Return-Path both name a platform you use	Unauthenticated sending platform	Complete its domain authentication — DKIM first
`d=` is a subdomain of yours, and your record has `adkim=s`	Strict alignment you opted into	Go back to relaxed until reports show strict passing
Sender is a mailing list or a security gateway; volumes are low	Signature broken in transit	Nothing — expected, and ARC often covers it
Both checks fail, not pass	Different problem entirely	See why SPF and DKIM show fail

Don't fix this by weakening DMARC

The tempting shortcut is to relax the policy until the failures stop. It works, in the sense that a warning light goes out: p=none reports everything and blocks nothing, so the mail flows and the problem is invisible again.

But alignment is the whole mechanism. A domain whose senders do not align is a domain where DMARC cannot distinguish you from someone impersonating you — which means it cannot be enforced, which means it protects nobody. Align your senders first, then enforce; DMARC policies explained covers the sequencing.

Free checks: DMARC checker DKIM checker SPF checker Report analyzer

Got a report in front of you? The free DMARC report analyzer parses it in your browser and shows the aligned verdict per sender, which is the column that answers this question.