Why DMARC fails and how to fix it

Your headers say dmarc=fail even though you set up SPF and DKIM. Nine times out of ten the cause is one of the four problems below — in plain English, with the fix for each.

Run our free DMARC checker — no signup

First, the rule that explains everything: alignment

DMARC doesn't just ask "did SPF or DKIM pass?" It asks: did one of them pass for the domain the recipient actually sees in the From: header?

• SPF is checked against the return-path domain (the invisible bounce address).
• DKIM is checked against the d= domain in the signature.

If neither of those matches your From: domain, DMARC fails — even with spf=pass and dkim=pass in the headers. Every cause below is some version of this rule biting.

Cause 1: your provider signs with its own domain

Marketing platforms, CRMs, and transactional-mail services sign everything by default — with their domain. dkim=pass with d=some-esp.com does nothing for yourdomain.com.

Fix: in the provider's settings, enable the option called custom DKIM, domain authentication, or sender verification. You'll publish a couple of CNAME or TXT records, after which their signatures use your domain and align.

Cause 2: the return-path belongs to the provider

Those same services usually set the return-path to their own bounce domain, so even a correct SPF record on your domain never gets checked. This is invisible unless you look at the raw headers.

Fix: the same domain-authentication setup usually adds a custom return-path (e.g. bounce.yourdomain.com) so SPF aligns too. But honestly: once DKIM is aligned (Cause 1), DMARC passes — aligned SPF is a bonus, not a requirement.

Cause 3: forwarding

When someone auto-forwards your mail (a university address forwarding to Gmail, an old work address, a distribution alias), the forwarding server isn't in your SPF record, so SPF fails at the final hop. A DKIM signature normally survives forwarding intact.

Fix: there isn't one on your side, and you don't need one — make sure every real sending source has aligned DKIM, and forwarded mail keeps passing DMARC. A small tail of SPF-only failures from forwarders in your reports is normal and safe to ignore. (Mailing lists that rewrite content can break DKIM too — that's the "body hash did not verify" error; that residual tail is why p=reject is a decision, not a default — see none vs quarantine vs reject.)

Cause 4: a sender you forgot exists

The invoice tool the accountant set up, the helpdesk that sends "as" your domain, the newsletter tool from two years ago — anything sending with your From: domain and no DKIM setup fails DMARC on every message.

Fix: you can't fix what you can't see, and this is exactly what aggregate reports are for. They list every source IP claiming to be your domain with its pass/fail results. Work down the list: recognized services get DKIM enabled (Cause 1); unrecognized IPs are forwarders — or someone spoofing you, which is the whole reason to finish this and reach p=reject.

How to debug a single message

Open the message headers (in Gmail: three-dot menu > Show original) and read the Authentication-Results line. It shows the three verdicts plus the domains they were evaluated against:

Authentication-Results: mx.google.com;
  spf=pass  smtp.mailfrom=bounce.some-esp.com;
  dkim=pass header.d=some-esp.com;
  dmarc=fail header.from=yourdomain.com

This example is Causes 1 and 2 at once: both passes belong to the provider's domains, so nothing aligns with yourdomain.com. If you're new to the three protocols, start with SPF vs DKIM vs DMARC; if SPF shows permerror, see too many DNS lookups.