DMARC Fails but SPF and DKIM Pass? The Alignment Fix (2026)

Objavljeno 2026-07-08

Figures as of 2026-06-29 · methodology v7. Aggregate census data across 261 million graded domains. See how we grade.

DMARC needs more than a pass — the domain that passed SPF or DKIM must match your From domain. Most “SPF pass, DMARC fail” mail passed SPF on the vendor’s bounce domain, not yours. Only 7.4% of 261,086,232 graded domains pass SPF with alignment under an enforcing DMARC policy, according to the Defaults.Exposed census (2026-06-29).

The fix is quicker than the confusion suggests. Read the Authentication-Results header to see which leg — SPF or DKIM — is passing on the wrong domain; then either enable your sending service’s custom-domain DKIM signing (usually a few CNAMEs, and the fix that survives forwarding), or set its custom return-path so SPF passes on your domain. One aligned leg is all DMARC needs.

How can DMARC fail when SPF and DKIM both pass?

Because DMARC never asks “did SPF pass?” It asks: did SPF or DKIM pass for a domain that matches the From address your recipient sees? That extra condition is called alignment, and it is the whole point of DMARC — without it, anyone could pass SPF on a domain they own while displaying yours in the From header.

Each check authenticates a different domain:

Check	Domain it actually evaluates	Where to see it
SPF	The Return-Path (RFC5321.MailFrom, the bounce/envelope-from address) — not the From header	`smtp.mailfrom=` in Authentication-Results
DKIM	The domain in the signature’s `d=` tag — whatever the signer chose	`header.d=` in Authentication-Results
DMARC	Your From-header domain — and it requires SPF’s domain or DKIM’s `d=` to match it	`header.from=` in Authentication-Results

This is how the pieces usually go wrong: your newsletter platform or CRM sends with a Return-Path like [email protected], SPF is checked against vendor.com and passes, DKIM passes with d=vendor.com — and DMARC fails, because neither passing domain matches yourcompany.com. Every check told the truth; none of them authenticated you. Editing your own SPF record cannot fix this — it was never consulted. It’s the same trap covered in SPF failing for your SaaS tools.

The census shows how few senders complete this last step: 27,640,987 of 261,086,232 graded domains (10.59%) have an enforcing DMARC policy at all, and only 7.4% pass SPF with alignment under one. Among the 77.5 million domains whose SPF ends in softfail (~all), just 9.2% sit under an enforcing DMARC policy; among hardfail (-all) publishers, 12,142,351 are enforced while 42,514,532 are not. Most domains stop at “SPF passes” — which, without DMARC acting on it, protects almost nothing.

How do I read Authentication-Results to see which leg is unaligned?

Send yourself a message through the failing service, open the raw source, and find the Authentication-Results header. A typical unaligned result looks like this:

Authentication-Results: mx.google.com;
       spf=pass smtp.mailfrom=bounces.espmail.net;
       dkim=pass header.d=espmail.net;
       dmarc=fail (p=NONE) header.from=yourcompany.com

Read it in three comparisons:

SPF leg: does smtp.mailfrom= end in your domain? Here it’s bounces.espmail.net — unaligned.
DKIM leg: does header.d= end in your domain? Here it’s espmail.net — unaligned.
DMARC verdict: header.from= is the domain DMARC is defending. Neither leg matched it, so dmarc=fail — even though both individual checks say pass.

Whichever leg already involves your own domain (or can be made to) is the one to fix. You only need one.

What’s the difference between relaxed and strict alignment?

DMARC offers two matching modes, set with the aspf (SPF) and adkim (DKIM) tags in your DMARC record:

Relaxed (r, the default): the two domains must share the same organizational domain — the registrable domain per the Public Suffix List. bounce.yourcompany.com aligns with yourcompany.com; so does a DKIM d=mail.yourcompany.com. This is why vendor custom return-paths and custom DKIM, which live on subdomains, work.
Strict (s): the domains must match exactly, character for character. bounce.yourcompany.com no longer aligns with yourcompany.com.

If your record doesn’t mention aspf or adkim, you’re in relaxed mode — and you almost certainly want to stay there. Strict mode adds no meaningful security for most senders and silently breaks every legitimate subdomain sender you set up. If DMARC is failing and your record contains aspf=s or adkim=s, that alone can be the bug.

How do I fix DMARC alignment?

Run the free scan at defaults.exposed before touching DNS. It shows your DMARC record and policy, whether your SPF and DKIM are set up to align, and what else is broken — so you fix the right leg first.
Test each sending service and read its Authentication-Results (as above). List every source — mailbox provider, newsletter tool, CRM, invoicing app — and note per source whether smtp.mailfrom and header.d are your domain or the vendor’s.
Enable custom-domain DKIM signing for each vendor — the fix that lasts. Every serious sending service offers “domain authentication”: a few CNAME records that let it sign as d=yourcompany.com (or a subdomain, which aligns in relaxed mode). Aligned DKIM is usually the easier fix and the only one that survives forwarding, because forwarding breaks SPF by design.
For SPF alignment, enable the vendor’s custom return-path (often called a custom bounce domain) — typically one CNAME such as bounce.yourcompany.com pointing at the vendor. SPF then passes on your organizational domain and aligns. Do this where offered, but treat it as the second leg, not a substitute for aligned DKIM.
Leave alignment in relaxed mode unless you have a specific, understood reason for aspf=s/adkim=s.
Re-scan and confirm both legs, then move toward enforcement. A DMARC policy of p=none reports but blocks nothing; once your real senders align, the full path to a policy that protects you is on the fix DMARC page, and provider walk-throughs like DMARC on IONOS cover the DNS-panel clicks.

Should I fix SPF alignment or DKIM alignment?

You need one aligned leg per sending source. If you can only do one, the choice is not close:

Fix	What it involves	Survives forwarding?
Aligned DKIM (custom-domain signing)	A few CNAMEs in the vendor’s “domain authentication” panel	Yes — the signature travels with the message
Aligned SPF (custom return-path/bounce domain)	One CNAME, where the vendor offers it	No — any forwarder’s IP replaces the vendor’s

The special case worth knowing: Google Workspace and Microsoft 365 will DKIM-sign your mail by default with their own fallback domains (gappssmtp.com, onmicrosoft.com) — so DKIM shows pass while DMARC still fails. It’s the single most common specific instance of this whole problem, and it has its own guide: DKIM passes but DMARC still fails: the default-signature trap.

Frequently asked questions

Do both SPF and DKIM need to align for DMARC to pass? No — one aligned pass is sufficient. Best practice is to align both anyway, so that when forwarding breaks the SPF leg, the DKIM leg still carries the DMARC pass. Of 261,086,232 domains graded in the 2026-06-29 census, only 3.87% complete the full SPF + DMARC + DKIM triad.

My ESP dashboard says SPF and DKIM are “verified” — why does DMARC still fail? “Verified” usually means the vendor’s own sending passes on the vendor’s domains. Unless you completed their custom domain steps (DKIM CNAMEs, custom return-path), mail authenticates as the vendor, not as you — and DMARC compares against your From domain.

Is a strict -all SPF record enough without alignment? No. A strict qualifier strengthens SPF’s verdict on the Return-Path domain, but DMARC still needs that domain to be yours. As of the 2026-06-29 census, only 12,142,351 of the domains publishing -all sit under an enforcing DMARC policy — the other 42,514,532 have a strict record that no policy acts on.

Should I switch to strict alignment (aspf=s/adkim=s) for more security? Almost never. Relaxed alignment already requires the same registrable domain, which a spoofer doesn’t control. Strict mode mostly breaks your own subdomain senders — check for it whenever alignment fails unexpectedly.

DMARC fails only on mail that recipients forward — same fix? That’s the SPF leg dying in transit: the forwarder’s server isn’t in anyone’s SPF record for your return-path. You can’t fix SPF for forwarded mail; aligned DKIM is the answer, since the signature survives forwarding intact. Details in forwarded email fails SPF.

Send the owner the report

If you’re fixing this for a client or your employer, close the loop with evidence. Re-run the free scan after the CNAMEs land and forward the graded report to the business owner: dated, plain-language, showing SPF, DKIM and DMARC aligned and passing. That’s the artefact they’ll need for the cyber-insurance renewal and the next supplier security questionnaire — proof of a working configuration, not just “I added some DNS records”.

Check your domain → · DKIM passes but DMARC still fails → · Fix DMARC → · How we grade → · Aggregate data only. Data stored and processed in the EU.