DMARC pass and fail, explained

Updated 2026-10-04 · Troubleshooting

You're looking at a dashboard full of verdicts — pass, fail · p=none, would quarantine, would reject — and you need to know, precisely, what each one is claiming about your mail. This article decodes them. (Its companion, DMARC alignment explained, teaches why the rules work this way; this one is for when you're staring at results and want them translated.)

The one rule that decides pass

A message passes DMARC when at least one of these is true:

SPF passed, and the domain it passed for aligns with the visible From domain, or
DKIM verified, and the signing domain aligns with the visible From domain.

One aligned pass is enough — you never need both. Every verdict you will ever see is downstream of that single rule.

The corollary trips everyone once: a check can pass and still count for nothing. SPF that passes for your email provider's bounce domain, or a DKIM signature from the provider's own domain rather than yours, is a real pass for an unaligned domain — and an unaligned pass contributes exactly as much to DMARC as a fail.

The ways a message fails

Three distinct situations all end in the same word, and telling them apart is most of the diagnostic skill:

What happened	SPF	DKIM	DMARC	Typical culprit
Everything passed raw — nothing aligned	pass (unaligned)	pass (unaligned)	fail	An ESP on default settings, authenticating as itself instead of you
One check broke, the other unaligned	fail	pass (unaligned)	fail	Half-finished setup: custom-domain DKIM never completed
Both checks positively failed	fail	fail	fail	Spoofing — or, rarely, a mailing list that modified the message

The first two rows are your mail with unfinished homework: the sender is legitimate and the fix is completing its aligned setup, usually the provider's custom-domain DKIM. The last row is the one DMARC exists to catch — no aligned identity, no raw authentication, nothing vouching for the message at all.

That is the shape of a failure; for the underlying causes, roughly ranked by how often they turn up in reports, and the fix for each, see Common causes of DMARC failure.

How the verdicts appear in DMARCmetric

The Sending sources table answers the pass/fail question before anything else: it splits your traffic into three sections.

Section	What it means
Verified	DMARC passed. Usually both SPF and DKIM counted (`fully aligned`); sometimes only one did, and the reason chip says which.
Carried by DKIM alone	DMARC passed on your DKIM signature only — SPF did not back it up. Forwarded mail usually lands here, but so does a missing or broken SPF record, and the reason says which.
Not verified	DMARC failed: neither check passed for your domain.

Each source row (expand any provider) carries three cells. The SPF and DKIM cells show whether the check succeeded — ✓ or ✕ — and whose domain it was for — = yours, ≠ someone else's, ○ none. A pass for someone else's domain (✓ ≠) is real authentication that DMARC cannot use, which is exactly how DMARC counts it. The DMARC cell gives the row's verdict:

pass — the row is in Verified or Carried by DKIM alone. Nothing is at risk.
fail · p=none — the row is in Not verified and your policy is monitoring only: the mail is still delivered.
would quarantine — Not verified, and your policy is p=quarantine: receivers are asked to treat it as suspicious, usually the spam folder.
would reject — Not verified, and your policy is p=reject: receivers refuse it.

The verdict follows your published policy as the latest report saw it, so the same failing row reads fail · p=none today and would reject once reports covering the new record arrive — typically a day or two after you change it. Provider rows carry no verdict of their own: a provider can have sources in more than one section, and each section shows only its share, so nothing is averaged away. The table itself is covered in Sending sources, grouped by provider.

Reading verdicts in practice

Three rows you will actually meet, decoded — note that two of them sit in the same section and need opposite remedies:

*Google, in Carried by DKIM alone* — pass, reason forwarded — nothing to do.** SPF failed because a forwarder resent the mail from its own servers, but your DKIM signature survived and carried it. Nothing to do.
*Mailchimp, in Not verified* — fail · p=none.** SPF ✓ ≠ (Mailchimp's own bounce domain) and DKIM ✓ ≠ (Mailchimp's own signature) or no signature: a second audience connected without the domain-authentication step. To DMARC a fully unauthenticated legitimate stream is indistinguishable from spoofing — which is exactly why it must be fixed before you enforce. The row's From domain and IP tell you which stream.
*Unknown, in Not verified, from a country you have never sold to.* Both cells ✕, modest probing volume. Spoofing: nothing to configure, because it was never yours — your policy is the fix, and once reports arrive under p=reject the row reads would reject.

Same section, opposite remedies: one row you repair, the other your policy blocks. The From domain, country and volume pattern are how you tell them apart.

One habit ties it together: judge sources, not messages. A single failing message might be a forwarder; a source that fails consistently is either your unfinished setup or someone else's forgery, and the cells tell you which. Where these verdicts sit in the bigger picture — KPIs, trends and the compliance ring — is mapped in Understanding your dashboard, and you can practise reading them on realistic data in the live demo.