DMARC fails but mail still delivered

Updated 2026-10-04 · Troubleshooting

Your reports show mail failing DMARC — and being delivered anyway. If you expected DMARC to work like a firewall, this looks broken. It isn't: a DMARC policy is a request you publish, not a command you enforce. The receiving mail system makes the final delivery decision, every time, and there are four ordinary reasons it delivers failing mail. Work through them in order — the first explains the vast majority of cases.

First: what is your policy actually asking for?

p=none requests exactly this behaviour. A monitoring policy tells receivers: deliver everything normally, just send me reports. Failing mail being delivered under p=none is not a gap — it is the entire design of the monitoring phase. If your record says p=none, there is nothing to diagnose; the question is simply whether your data says you're ready to move up the policy ladder.

pct= sampling waives the rest. A record like p=quarantine; pct=25 asks receivers to apply quarantine to a quarter of failing mail and treat the remaining three-quarters under none. Those sampled-out messages are delivered, correctly and by your own instruction. If you set pct during a staged rollout and forgot it, this is your answer — check your live record with the free checker.

Second: the receiver's own judgement

Even with a clean p=reject, receivers sometimes deliver failing mail deliberately:

• Recognised forwarding and list traffic. Receivers know what forwarded mail looks like, and increasingly verify it via ARC — the chain that proves a message authenticated fine before an intermediary broke it. Rather than bounce mail their user genuinely wants, they override the policy for that message. Why SPF fails on forwarded mail covers this whole family of cases.
• Softened enforcement. Some providers treat reject as "quarantine, aggressively" for borderline traffic — Google historically shunted some reject-worthy mail to spam rather than refusing it outright, and providers' bulk-sender rules add their own layer of judgement on top of yours. From the outside this reads as "delivered despite failing"; from the receiver's side it's harm reduction for their users.

These overrides are per-message, principled and, importantly, visible — which brings us to the reports.

Read the disposition, not just the verdict

Every aggregate report states, per row, what the receiver actually did — the disposition field: none (delivered), quarantine or reject. Reading it against your published policy turns confusion into information:

When a receiver overrides, reports usually say why — a reason entry such as forwarded, mailing_list, local_policy or sampled_out next to the row. A disposition differing from your policy with a stated reason is the system being transparent, not disobedient. How to read a DMARC report walks through these fields in a real report.

What the dashboard shows

In the Sending sources table, mail that failed DMARC sits in the Not verified section, and its verdict follows the policy your reports show you have published: fail · p=none while you are monitoring — failing, and delivered, exactly as your policy requests — would quarantine under p=quarantine and would reject under p=reject.

So "the dashboard says it failed but the mail was delivered" is not a contradiction: under p=none you have asked receivers to deliver failing mail and report on it, and even under p=quarantine or p=reject the final decision is the receiver's own judgement. The failing rows you see while monitoring are precisely the protection you haven't switched on yet.

When to worry — and when it's fine

Fine, no action:

• Failing mail delivered under p=none or within your pct ramp — that's the policy you published.
• Occasional disposition: none rows at enforcement carrying a forwarded or local_policy reason — receivers rescuing legitimate forwarded traffic.
• A trickle of spoofed mail marked quarantine where you asked for reject — it's still out of the inbox.

Worth acting on:

• Your own senders failing and being delivered — delivery today doesn't fix authentication; complete their SPF/DKIM alignment before a receiver stops being lenient.
• Spoofing delivered in volume while you sit at p=none. The reports have done their job; the remaining risk is the policy. Start the climb.
• At p=reject, failing mail consistently delivered with no override reason. Rare — check your record is syntactically valid, has no leftover pct, and that subdomain traffic isn't slipping past via a leftover sp=none tag or a subdomain's own, more lenient DMARC record.

The pattern behind all of it: DMARC gives you visibility immediately and control gradually. Delivered-despite-failing is what the gap between those two looks like — and the reports tell you, row by row, exactly how wide the gap still is.