Why does DMARC fail?

A report told you. Or a header said dmarc=fail. Or your mail started bouncing with a 5.7.26 error and a sentence about your domain's DMARC policy. Whatever brought you here, you've got the same question everyone does at this point: it's set up, so why is it failing?

Good news first. DMARC fails for a short, knowable list of reasons, and once you know which one you're looking at, each has a clean fix. The trick is that the most common reason is also the least obvious, and it's the one that makes people throw up their hands and say "but I added the record." Let's go through them in the order you're most likely to hit them.

The short version

DMARC passes only if SPF or DKIM both passes and aligns with the domain in your visible From address. That word "aligns" is doing almost all the work, and it's where most failures live. Everything below is really a variation on one of two things: something isn't passing, or it's passing but for the wrong domain.

So as you read, hold one question in your head: is the check failing, or is it passing and just not lined up with my From? That single distinction tells you which half of the problem you have.

Reason 1: it passes, but it doesn't align

This is the big one. It's the reason behind most "I set up DMARC and nothing happened" stories, and if you only understand one thing about DMARC, make it this.

DMARC doesn't just ask "did SPF or DKIM pass?" It asks "did they pass for the same domain my recipient sees in the From field?" There are two ways to satisfy that:

• SPF alignment: the domain in the hidden return-path (the envelope, where bounces go) has to match your From domain.
• DKIM alignment: the d= domain in the DKIM signature has to match your From domain.

You only need one of those to line up. The problem is that when you send through a third-party tool (a marketing platform, a CRM, an outbound sequencer), the tool often signs and sends using its own domain by default. So SPF passes, DKIM passes, both genuinely, but both for the tool's domain, not yours. Nothing aligns to your From. DMARC fails.

Two green checks. One red verdict. That's alignment.

The fix: configure each sending tool to authenticate as your domain. Almost every serious platform supports this, usually called a "custom sending domain," "authenticated domain," or "dedicated sending domain." You publish a couple of records they give you, and suddenly DKIM signs as your domain, alignment is satisfied, and DMARC flips to pass. There's also a relaxed-versus-strict setting (adkim and aspf); relaxed is the sane default and treats a subdomain as aligned with the parent. Use strict only when you have a specific reason to.

Reason 2: SPF quietly broke

SPF has two failure modes that are sneaky because the record still looks fine to you.

• The ten-lookup limit. SPF is only allowed to trigger ten DNS lookups while it evaluates. Every tool you authorize with an include spends some of that budget, and some tools spend several each. Chain enough of them and you cross the limit, SPF returns a PermError, and it fails for everyone, all at once, with no visible change to the record. The fix is SPF flattening or trimming includes you don't actually use.
• More than one SPF record. You're only allowed one. Two records (often because something auto-published a second one) is an instant PermError. The fix is to merge them into a single record.

Worth knowing: SPF also breaks on forwarding, which we'll get to. And if SPF is your only passing-and-aligned mechanism, these breaks take DMARC down with them. This is exactly why you want DKIM aligned too, as a second leg to stand on.

Reason 3: a DKIM source isn't signing

DKIM fails for a few specific reasons, and the cause is usually one source, not your whole domain:

• A source has no DKIM key at all. You enabled DKIM on your main mailbox but never on your invoicing tool, or your newsletter platform, or that one CRM. That source signs nothing and fails.
• The published key is wrong or missing. A typo in the DNS record, a key that was rotated on the provider side but not updated in DNS, or a selector that doesn't match.
• The message got modified in transit. DKIM signs the body. If something rewrites the body after signing (a mailing list appending a footer, some security gateways), the signature no longer matches and DKIM breaks even though it was valid on the way out.

If a header shows dkim=fail or dkim=none, check the d= value and the selector against what's actually published in DNS. Nine times out of ten the mismatch is right there.

Reason 4: a sending source you forgot

This is the one your DMARC reports are built to catch. Companies send from far more places than anyone remembers: the main mail, the marketing platform, the CRM, the helpdesk, the invoicing system, the e-sign tool, payroll, that one webhook a developer wired up in 2021. Each is a separate sending source, and each needs to be authenticated and aligned.

When you read an aggregate DMARC report, you'll see a source failing that you didn't even know was sending as you. Sometimes it's a legitimate tool nobody flagged. Sometimes it's an attacker spoofing your domain, which is the whole reason DMARC exists. Either way, the report is how you find it. You cannot fix a source you don't know about, and the report is the only thing that reliably surfaces them all.

Reason 5: forwarding and mailing lists

Here's a failure that often isn't really your fault, and it's worth understanding so you don't chase a ghost. When someone forwards your email, or it goes through a mailing list, the forwarding server sends it onward from its own IP, which isn't in your SPF. So SPF breaks on the forward. DKIM usually survives, because the signature travels with the message, which is exactly why DMARC lets DKIM alone carry the pass. But if that mailing list also rewrites the body (adding a footer or a subject tag), DKIM breaks too, and the forwarded copy fails DMARC.

You'll see these in your reports as a small slice of failures from forwarding sources. They usually don't mean your setup is broken. The thing that protects you here is having solid, aligned DKIM in the first place, so the majority of forwards still pass on the DKIM leg.

The self-inflicted one: bouncing after p=reject

This deserves its own section because it's the failure that actually hurts, and it's entirely avoidable. You moved your DMARC policy to p=reject while a legitimate sending source was still failing alignment. So now the providers are doing exactly what you told them to: rejecting that mail. Your invoices, your password resets, or your campaign just started bouncing, and it feels like the fix broke everything.

The lesson underneath this is the whole discipline of DMARC: you go none, then quarantine, then reject, slowly, checking reports at every step, and you never tighten while a legitimate source is still red. Done that way, nobody ever notices it happening. Rushed, it's the most expensive way to learn this.

How to read which reason is yours

You can narrow it down fast, and reading never changes anything, so there's no risk in looking. The fastest first pass is to run the domain through our free authentication check, which reads your SPF and DMARC and flags the obvious breaks in seconds. To go deeper by hand:

1. Open the headers. Send yourself a message, and in Gmail use "Show original." You'll see spf, dkim, and dmarc results. If SPF and DKIM say pass but DMARC says fail, you've got an alignment problem (Reason 1). If one of them says fail, that's your starting point (Reasons 2 or 3).
2. Run the records. Drop your domain into mxtoolbox and check SPF and DMARC. It flags a second SPF record and the ten-lookup limit immediately.
3. Read your aggregate reports. If you don't have DMARC reporting on yet, publish a record in monitor mode with a reporting address. A day or two later the reports show every source, pass or fail, which is how you catch the forgotten ones (Reason 4) and the forwarding noise (Reason 5).

Between the headers (what's failing) and the reports (which source), you'll land on your specific reason. From there the fix is mechanical. The diagnosis is the hard part, and you've just done most of it.

One honest note to close on. Getting DMARC to pass is squarely fixable, and it's the part we guarantee. It also doesn't, by itself, guarantee your mail lands in the inbox, because placement also rides on your reputation and how people engage with your mail, and no DNS record controls that. But a failing DMARC is a reason you're filtered, full stop. Fix that first, and you've removed the part that's actually in your hands.