DMARC fail: what it means and how to find the actual cause

Q: Does a DMARC fail mean my email goes to spam?

Depends on the published policy: p=none delivers normally, quarantine typically spam-folders, reject bounces. Receivers can also apply their own judgment either way — and repeated failures feed into how they treat your traffic generally.

Q: How do I find out why DMARC is failing?

Send yourself a message and read its Authentication-Results header — the email header analyzer decodes it. The which-domain-passed details identify the cause in most cases within minutes.

2026-08-20

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

Look closely at that header, because it's the most common shape of a DMARC failure in the wild: SPF passed, DKIM passed — and DMARC failed anyway. Nothing here is contradictory. Both passes belong to espmail.net, the sending platform, while the visible From address is example.com, and DMARC fails whenever no pass aligns with the From domain.

This article is the diagnosis lane of our DMARC series: what dmarc=fail actually asserts, the causes ranked by how often they turn out to be it, and how to read the evidence for each. Policy levels and rollout strategy are covered separately, initial setup too, and the aggregate reports you'll use for fleet-wide diagnosis have their own guide.

What dmarc=fail actually asserts

DMARC passes when at least one of two conditions holds: an SPF pass whose validated domain aligns with the From domain, or a valid DKIM signature whose d= domain aligns with it. dmarc=fail means neither happened for this message. That's all it means — it doesn't say why, and the why is everything, because the fixes for different causes have nothing in common.

Note what failure costs depends on your policy: at p=none a failing message is delivered normally (the dis=NONE in the header above shows the receiver's disposition); at quarantine it's spam-foldered; at reject it bounces. Diagnosis is identical at every level — but the urgency isn't, which is exactly why you diagnose at p=none before enforcement raises the stakes.

First, get the evidence

Two sources, use both:

A live header. Send a message through your normal platform to a Gmail or Outlook mailbox you control, open the raw source, and paste it into the email header analyzer. You need four facts it will surface: the SPF result and which domain it validated, the DKIM result and its d= domain, the From domain, and the DMARC verdict.
Your record. Run the domain through the DMARC checker to confirm what's actually published — policy, alignment mode, report address. Diagnosis against an imagined record wastes time; more than one "DMARC mystery" has been a typo'd record or a stale duplicate.

With the evidence up, walk the causes.

Cause 1: your ESP signs DKIM with its own domain

The header at the top of this page. The platform signs every message it sends — with its domain (d=espmail.net) unless you've completed their custom-domain authentication setup. The signature is valid, reputation-relevant, and useless for your DMARC, because espmail.net never aligns with example.com.

Evidence: dkim=pass with a d= that isn't your domain. Fix: enable custom domain signing in your platform (usually under "domain authentication" — you'll add a few CNAME or TXT records they provide), then confirm the d= flips to your domain on a fresh test send. This single cause resolves most sender-side DMARC failures, which is why it's step one.

Cause 2: SPF passes for the wrong domain — by design

SPF validates the envelope sender (return-path), and ESPs routinely set that to their own bounce domain so they can process bounces. Result: spf=pass smtp.mailfrom=mailer.espmail.net — a real pass that will never align with your From domain. This isn't a misconfiguration; it's how the platform works, and it's why aligned DKIM (cause 1's fix) carries most DMARC deployments. Some platforms also offer a custom bounce domain (bounce.example.com), which makes SPF align too — worth enabling where available, since two aligned paths beat one.

Evidence: spf=pass whose smtp.mailfrom domain isn't yours. Fix: custom bounce/return-path domain if the platform supports it; otherwise rely on aligned DKIM and move on.

Cause 3: forwarding broke SPF, and DKIM wasn't there to catch it

When a recipient auto-forwards mail (college address to Gmail, an old work address to a new one), the forwarder's server becomes the sending IP — an IP your SPF record never authorized, so SPF fails for the forwarded copy. DMARC anticipated this: DKIM signatures normally survive forwarding intact, and one aligned pass suffices. The failure happens when your mail carries no aligned DKIM (cause 1 again) — then every forwarded message fails DMARC at its final destination. RFC 7960 catalogs these indirect-flow failures in depth.

Evidence: failures concentrated at receivers you don't recognize, odd receiving domains in your aggregate reports, normal results on direct sends. Fix: aligned DKIM. Forwarding-related SPF failure is unfixable by design; the DKIM path is the designed answer.

Cause 4: a mailing list modified the message

Traditional discussion lists append footers or rewrite subjects — invalidating the DKIM signature — then resend from their own servers, failing SPF alignment as well. Mail your users send to such lists fails DMARC at every subscriber's mailbox. Modern list software works around this with From-rewriting, but that's the list operator's choice, not yours.

Evidence: failures tied to specific list domains in reports; complaints from list participants when you move to p=reject. Fix: none on your side. Known, bounded, and one reason organizations whose users live on mailing lists weigh quarantine against reject carefully.

Cause 5: DKIM is genuinely broken

Sometimes the signature itself fails: a key rotation where DNS wasn't updated, a deleted selector record, a migration that changed selectors, or an intermediary (security gateway, footer-stamping appliance) modifying messages after signing.

Evidence: dkim=fail or dkim=neutral where you expect a pass — distinct from cause 1, where DKIM passes for the wrong domain. Verify the published key for your selector with the DKIM checker, and check whether an in-house gateway touches outbound mail. Fix: repair the DNS record, republish the key, or re-order the pipeline so signing happens last.

Cause 6: it isn't your mail at all

The diagnosis everyone forgets: DMARC failing on traffic you never sent is DMARC working. Spoofers and phishers sending as your domain fail authentication by nature, show up as failing sources in your aggregate reports, and — once you reach enforcement — stop arriving in anyone's inbox as you.

Evidence: failing source IPs in reports that belong to no platform you use, often in networks or countries where you have no infrastructure. Fix: nothing to repair — this is the case for finishing the rollout to p=reject rather than a reason for alarm about your setup.

The workflow, compressed

Run the test send and header analysis. If DKIM passes with your domain in d= and DMARC still fails, check your record's alignment mode and the exact From domain (subdomain mismatches under strict alignment trip people). If DKIM passes with the wrong d=, that's cause 1 — fix it first and re-test before touching anything else. If direct sends pass but reports show scattered failures, look at causes 3, 4 and 6 in your aggregate data. And after every fix, re-verify with a fresh send rather than declaring victory from configuration screens — the email authentication checker plus one real test message is the full loop.

Related guides

Email header analyzer — extract the four facts diagnosis needs
DMARC checker — confirm what your domain actually publishes
DKIM checker — verify selectors and published keys
SPF checker — validate the record and its lookup budget
DMARC generator — rebuild the record if diagnosis finds it malformed
What is DMARC? — alignment mechanics in full
Reading DMARC reports — fleet-wide diagnosis at scale

About this guide

Written by InboxRatio Editorial. The cause ranking reflects the failure patterns we see configuring authentication on our own domains for every benchmark cycle and in submissions to our free checking tools; protocol behavior follows RFC 7489 and RFC 7960. No vendor's troubleshooting marketing informs the ordering.

Methodology

InboxRatio configures SPF, DKIM and DMARC on its own sending domains before every controlled placement test, which means we debug real DMARC failures on real platforms as routine work. Our benchmark protocol — identical campaigns, controlled seed list, per-provider placement — is documented at how we test.

Last updated

21 August 2026. Cause patterns and provider behavior reviewed quarterly.

Frequently asked questions

What does DMARC fail mean? No authentication result aligned with the visible From domain: SPF didn't pass for that domain, and no valid DKIM signature carried it in d=. It's an alignment verdict — SPF and DKIM can both "pass" for other domains and DMARC still fails.

Why does DMARC fail when SPF and DKIM pass? Because passing isn't aligning. An ESP's bounce domain passing SPF and an ESP's own DKIM signature are the classic pair — both legitimate, neither matching your From domain. The fix is custom-domain DKIM signing (and a custom bounce domain where offered).

Does a DMARC fail mean my email goes to spam? Depends on the published policy: p=none delivers normally, quarantine typically spam-folders, reject bounces. Receivers can also apply their own judgment either way — and repeated failures feed into how they treat your traffic generally.

How do I find out why DMARC is failing? Send yourself a message and read its Authentication-Results header — the email header analyzer decodes it. The which-domain-passed details identify the cause in most cases within minutes.

Should I worry about DMARC failures in my reports for mail I didn't send? Investigate, don't panic. Unrecognized failing sources are usually spoofing attempts — the traffic DMARC exists to shut down. Confirm the source isn't a forgotten internal system, then let enforcement handle it.

Can forwarding cause DMARC failures I can't fix? Forwarding predictably breaks SPF alignment, and there's no sender-side fix for that path. Aligned DKIM survives normal forwarding, which is the designed remedy — mailing lists that modify content remain the one genuinely unfixable case.

Remember the shape of the problem: dmarc=fail is a symptom with a short suspect list, and the d= domain of your DKIM signature convicts the usual culprit in one look. Run a test send through the email header analyzer now — the four facts it surfaces will place you on this page's map within minutes.