DMARC fail: what it means, why it happens, and how to fix it

A passing SPF check and a passing DKIM signature feel like they should be enough. They are not. A message can clear both and still land on a DMARC fail.

DMARC does not ask “did SPF pass?” or “did DKIM pass?” on their own. It asks whether a passing check authenticated a domain that matches the address your recipient actually saw. That match is called alignment, and it is the second gate where a “dmarc fail” usually originates.

Last updated: May 29, 2026.

This post explains what a DMARC fail is at the protocol level, the difference between authentication failing and alignment failing, where you actually see a fail, the common root causes, and a checklist to fix it. It stays provider-agnostic. If your mail flows through Mailchimp, SendGrid, or Klaviyo, the per-ESP record-by-record fixes live in the sibling guide; here we cover the mechanics that apply to every sender.

What a DMARC fail is at the protocol level

DMARC layers on top of SPF (RFC 7208) and DKIM (RFC 6376) and binds their results to one specific identity: the RFC5322.From domain, which is the domain in the visible From: header your recipient reads. SPF and DKIM each authenticate a domain, but not necessarily the one the human sees. DMARC forces the connection between the passing check and the visible address. (Source: RFC 9989 §3.2.10, the DMARCbis specification that obsoletes RFC 7489.)

The condition for a DMARC pass is stated verbatim in RFC 9989 §5.3.5:

If one or more of the Authenticated Identifiers align with the Author Domain, the message is considered to pass the DMARC mechanism check.

Read that as a single rule:

DMARC pass = (SPF passes AND is aligned) OR (DKIM passes AND is aligned).

Only one of the two paths needs to both pass and align. If neither path satisfies both halves, the result is a DMARC fail. A raw SPF or DKIM pass on its own is not enough, because the passing identifier might point at a domain that has nothing to do with your From: address.

Relaxed vs strict alignment (aspf and adkim)

Alignment has two modes, set per record by the aspf (SPF) and adkim (DKIM) tags. Both default to r, relaxed (RFC 9989 §4.7).

Mode	DKIM (adkim)	SPF (aspf)
Relaxed (r, default)	The Organizational Domain of the DKIM d= domain must equal the Organizational Domain of the From: domain.	The Organizational Domain of the SPF-authenticated domain must equal that of the From: domain.
Strict (s)	Only an exact FQDN match between the DKIM d= domain and the From: domain aligns.	Only an exact DNS domain match between the SPF-authenticated domain and the From: domain aligns.

(Definitions: RFC 9989 §3.2.10.1 for relaxed alignment, §3.2.10.2 for strict.)

The Organizational Domain is the registrable domain that DMARC derives by walking up the DNS tree from the From: domain (RFC 9989 §4.10, the DNS Tree Walk). Historically, under RFC 7489, this was derived from the Public Suffix List; DMARCbis replaced that with the Tree Walk, and for a flat domain the result is the same. So news.example.com and example.com share the Organizational Domain example.com.

A worked example shows the difference. Suppose From: news.example.com and the message is DKIM-signed with d=example.com:

• Relaxed adkim=r: aligned. Both reduce to the Organizational Domain example.com.
• Strict adkim=s: not aligned. The FQDNs news.example.com and example.com are not an exact match.

This is why strict mode is a frequent source of self-inflicted failures, and why relaxed alignment is the default you usually want. We cover the alignment model in depth in DMARC, SPF, and DKIM alignment explained.

Authentication failing vs alignment failing

This is the part of DMARC people most often misread. SPF authenticates the RFC5321.MAIL FROM domain, which is the envelope sender, usually visible as the Return-Path. DKIM authenticates the d= signing domain. Neither of those is automatically your From: domain. So a check can pass at the mechanism level and still fail to align.

There are four outcomes worth knowing:

Case	SPF result	DKIM result	Aligned?	DMARC
1. SPF path works	pass	(any)	SPF aligned to From:	pass
2. DKIM path works	(any)	pass	DKIM d= aligned to From:	pass
3. Pass but not aligned	pass	pass	neither aligned to From:	fail
4. Hard fail	fail	fail	n/a	fail

Case 3 is the one that catches people out. Both SPF and DKIM say “pass,” every individual check looks green, yet DMARC reports a fail because the authenticated identities belong to someone else, typically your email provider.

The common trigger is an ESP sending “on behalf of” you. The envelope sender (MAIL FROM) is the ESP’s bounce domain like bounce.mailer-esp.com, so SPF passes for the ESP, not for you. If the ESP also signs DKIM with its own d=mailer-esp.com, that does not align either. Result: SPF pass, DKIM pass, DMARC fail. We walk through why this happens with ESPs and subdomains in ESPs, subdomains, and DKIM alignment.

Where you actually see a DMARC fail

A fail shows up in three places, and they describe the same event from different angles.

1. The aggregate (rua) report

DMARC aggregate reports are XML documents that receivers email back to you daily. Inside each <record>, the <policy_evaluated> block carries the DMARC verdict per source. Here is a representative fragment for the case-3 scenario above (structure per RFC 9990 Appendix A; treat as a representative example, not a byte-for-byte quote):

<record>
  <row>
    <source_ip>203.0.113.25</source_ip>
    <count>14</count>
    <policy_evaluated>
      <disposition>none</disposition>      <!-- under p=none, still delivered -->
      <dkim>fail</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>example.com</header_from>
  </identifiers>
  <auth_results>
    <spf>
      <domain>bounce.mailer-esp.com</domain>   <!-- SPF auth domain != header_from -->
      <result>pass</result>                    <!-- mechanism PASS, but unaligned -->
    </spf>
    <dkim>
      <domain>mailer-esp.com</domain>
      <selector>s1</selector>
      <result>pass</result>                    <!-- mechanism PASS, but d= unaligned -->
    </dkim>
  </auth_results>
</record>

Notice the deliberate split. The <auth_results> block shows the raw mechanism results (pass for both SPF and DKIM), while <policy_evaluated> shows the alignment-evaluated result (fail for both). That divergence, a mechanism pass next to an alignment fail, is the exact signature of “SPF passed but DMARC failed.” The DMARCResultType values are pass or fail, and DispositionType is none, quarantine, or reject (RFC 9990 Appendix A).

2. The Authentication-Results header

The DMARC verdict is also stamped into the message itself, in an Authentication-Results header (syntax from RFC 8601; the dmarc method and its header.from property are defined by the DMARC specification, RFC 9989):

Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of [email protected] designates 203.0.113.25 as permitted sender) [email protected];
       dkim=pass header.d=mailer-esp.com;
       dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=example.com

Again: spf=pass, dkim=pass, and dmarc=fail on the same message. The header.from=example.com tells you which identity DMARC was evaluated against, and the passing SPF (smtp.mailfrom=...mailer-esp.com) and DKIM (header.d=mailer-esp.com) tell you why neither aligned.

3. The Gmail-style notice

In Gmail’s “Show original” panel, a failing message surfaces a DMARC line with a fail value, and Gmail’s delivery diagnostics use the phrase “dns authentication: dmarc fail”. That exact string is what people most often paste into a search box. It is Gmail UI wording, not an RFC artifact, and Gmail’s exact text changes over time, but the underlying cause is always the dmarc=fail line in the Authentication-Results header above. Other gateways and security products word it differently. A dmarc fail in Mimecast or another mail security gateway reflects the same protocol verdict surfaced under that product’s own labels. The underlying protocol result is identical regardless of which UI names it.

Common root causes of a DMARC fail

Almost every fail traces back to a small set of alignment problems. Each one breaks a specific path to alignment.

DKIM signed by the ESP’s domain, not yours

Your provider signs with d=esp-domain.com instead of your From: domain. DKIM passes, but the d= Organizational Domain does not match yours, so there is no DKIM alignment. The fix is to configure branded or custom DKIM, where a CNAME-delegated selector under your domain makes the signature resolve as d=yourdomain.com. Provider-specific steps are in the setup guides for Mailchimp DKIM and SendGrid DKIM.

Return-Path points at the ESP’s bounce domain

The envelope sender (MAIL FROM) is the ESP’s bounce subdomain, so SPF authenticates the ESP’s domain rather than yours. SPF passes, but it is unaligned. The fix is a custom Return-Path: a CNAME under your own domain so the SPF-authenticated domain shares your Organizational Domain. We cover this in detail in Return-Path and DMARC, and the SPF side of diagnosis in SPF failed: troubleshooting.

Forwarding breaks both checks

A forwarder changes the connecting IP, which breaks SPF for your original sending host, and it may alter the body or headers, which breaks the DKIM signature. With both paths broken, DMARC fails through no fault of your DNS. ARC (RFC 8617) exists to carry prior authentication results across hops, but ARC is not part of the DMARC pass test. Forwarding and mailing-list failures get their own treatment in forwarding and mailing-list DMARC failures.

Subdomain vs Organizational Domain mismatch

You send From: mail.example.com while only example.com is authenticated and signed. Relaxed alignment usually rescues this, because both share the Organizational Domain. Strict mode breaks it, because the FQDNs differ.

Too-strict aspf=s or adkim=s

Strict mode demands an exact FQDN or DNS match. Any subdomain or ESP-domain variance that relaxed mode would tolerate now fails. If you set strict alignment without confirming every legitimate sender matches exactly, you create fails you did not need.

Missing or mistyped DKIM selector

If selector._domainkey.yourdomain.com is absent, mistyped, or rotated out, DKIM returns permerror, none, or fail, which removes the DKIM path to alignment entirely. If SPF is also unaligned, DMARC fails.

SPF too long (permerror)

SPF allows at most 10 DNS lookups. Exceed that and SPF returns permerror (RFC 7208 §2.6), which is not a pass, so it eliminates the SPF alignment path. Flattening your SPF record mitigates this.

What p=none, p=quarantine, and p=reject mean for a fail

The p= tag in your DMARC record tells receivers what to do with a failing message. It does not change whether the message failed; it changes the consequence. For a full reference on what each DMARC tag does, see our record tags guide.

Policy	What it requests	What happens to a failing message
p=none	“No specific action” (RFC 9989 §4.7). Monitoring only.	Still delivered. Failures appear in your rua/ruf reports, but mail disposition is unchanged (a discovered policy of p=none does not modify existing mail disposition).
p=quarantine	Treat failing mail as suspicious (§4.7).	Typically routed to spam/junk.
p=reject	Reject failing mail (§4.7).	A strong signal to refuse the message. Note that DMARCbis softened this: receivers MUST NOT reject solely on p=reject, and in the absence of other analysis MUST treat such mail as p=quarantine (RFC 9989 §7.4). General-purpose mailbox domains SHOULD NOT deploy p=reject (RFC 9989 Appendix C.6). This is the dmarc reject policy enforcement state.

Two related notes matter. The sp tag sets the policy for subdomains; DMARCbis also adds an np tag for non-existent subdomains, and both fall back sensibly when absent (RFC 9989 §4.7). The old pct tag, which under RFC 7489 set the percentage of failing mail the policy applied to, was removed in DMARCbis (RFC 9989 Appendix A.6). It is replaced by the t= test-mode flag (§4.7): t=y asks receivers to apply the next-lower policy (reject becomes quarantine, quarantine becomes none) while still sending reports. Records that still carry pct= keep working, because receivers ignore unknown tags.

One point trips people up: seeing fails under p=none is normal, and it is the point. Monitoring mode exists so you can watch failures accumulate in reports without affecting delivery, identify every legitimate source that is failing, fix alignment for each one, and only then raise the policy to quarantine or reject. A fail under p=none is data, not an outage. A fail under a dmarc reject policy is mail that may be refused or quarantined by the receiver, which is why you fix alignment before you enforce.

The fix checklist

Work through this in order. Each step closes one alignment gap.

1. Pull your aggregate reports and find the failing source. The report tells you the source_ip, the header_from, and which mechanism the receiver evaluated. Identify which sending service each failing source is.
2. Decide which path you want to align: SPF, DKIM, or both. You only need one. DKIM alignment is more durable because it survives forwarding better than SPF.
3. For DKIM alignment: configure the sending service to sign with a selector delegated under your domain, so header.d= resolves to your Organizational Domain. Confirm the selector’s TXT record exists at selector._domainkey.yourdomain.com.
4. For SPF alignment: set a custom Return-Path under your own domain so the MAIL FROM domain shares your Organizational Domain. Confirm your SPF record stays within 10 DNS lookups.
5. Re-check your alignment mode. Unless you have a specific reason and have verified every sender, leave aspf and adkim at the relaxed default. Do not set strict mode to “be safe”; it removes tolerance you usually need.
6. Confirm with a delivered message. Inspect the headers. DMARC passes when Authentication-Results shows dmarc=pass, the DKIM header.d= is your Organizational Domain (or a subdomain of it), and/or the Return-Path is under your Organizational Domain. In Gmail, the “via provider-name” label disappearing is a quick visual proxy that From-domain alignment was achieved.
7. Only then tighten the policy. Move from p=none to p=quarantine, then to p=reject, watching reports at each step. You can create a DMARC policy record with the new p= value and re-publish it in DNS. Our troubleshooting hub links the per-symptom guides if a specific source keeps failing.

Summary

A DMARC fail almost never means your DNS is broken. It usually means a passing SPF or DKIM check authenticated the wrong domain, the one that does not match your visible From: address. Authentication is the first gate. Alignment is the second, and it is the one that catches people out. Fix alignment for each failing source, verify with real headers, then raise your policy.

The hard part of any DMARC fail is seeing which source failed and whether it was SPF or DKIM alignment that broke. That is exactly what aggregate (rua) reports show, source by source. For a quick posture snapshot of any domain’s published DMARC, SPF, and related records, the free DMARC checker gives you a read in seconds. When you are ready to diagnose real failures, DMARCTrust turns the daily aggregate XML into a readable per-source view, so you can see the failing IP, the evaluated identity, and which alignment path to fix, instead of parsing XML by hand.