Why DMARC fails when SPF and DKIM pass

22 June 2026 · 6 min read

DMARC fails while SPF and DKIM pass when both checks passed for a domain other than the one in your visible From address. DMARC only counts a result that passes and aligns: the domain SPF or DKIM authenticated must match the From domain. A sending platform can pass SPF for its own bounce domain and DKIM for its own signing domain, and the message is then authenticated, just not as you.

The fix is to give at least one mechanism an identifier on your own domain, usually by completing DKIM setup at the sending service.

What DMARC actually compares

• SPF checks the envelope sender, also called the Return-Path or MAIL FROM. That is the bounce address set during the SMTP conversation, which recipients normally never see.
• DKIM checks the domain in the d= tag of the DKIM-Signature header. The sender chooses it, and the receiver fetches the public key from that domain (RFC 6376).
• DMARC takes the domain in the From: header and asks whether SPF or DKIM passed for a domain that aligns with it (RFC 9989). One aligned pass is enough.

So spf=pass for bounce.mailer.example and dkim=pass for d=mailer.example both count for nothing when the From address is you@example.com.

Relaxed and strict alignment

The aspf and adkim tags in your DMARC record set the mode for each mechanism. Both default to relaxed.

• Relaxed (r): the two domains must share the same organisational domain. bounce.example.com aligns with example.com.
• Strict (s): the two domains must be identical. bounce.example.com does not align with example.com.

If your record contains aspf=s or adkim=s and you did not choose strict deliberately, a service that uses a subdomain of yours for bounces or signing will fail alignment. Removing the tags restores the relaxed default.

Under RFC 9989, receivers find the organisational domain with a DNS tree walk: they look up DMARC records at the From domain and its parent names, instead of consulting the Public Suffix List that the older RFC 7489 relied on. For a normal setup the outcome is the same. news.example.co.uk and example.co.uk share the organisational domain example.co.uk.

Read the Authentication-Results header

The fastest diagnosis is one received message. Open it in Gmail or Outlook, view the original source and find the Authentication-Results header added by the receiver. This example, adapted from Microsoft's documentation, shows the failure:

Authentication-Results: spf=pass (sender IP is 198.51.100.10)
  smtp.mailfrom=bounces.mailer.example; dkim=pass (signature was verified)
  header.d=mailer.example; dmarc=fail action=oreject
  header.from=example.com

Compare each passing domain with header.from:

• smtp.mailfrom=bounces.mailer.example is the domain SPF passed for. It is not under example.com, so SPF is not aligned.
• header.d=mailer.example is the DKIM signing domain. Also not under example.com, so DKIM is not aligned.
• dmarc=fail follows, because neither pass aligned.

Gmail writes the DKIM domain as header.i=@mailer.example rather than header.d=. If either domain matches your From domain, or shares its organisational domain under relaxed alignment, DMARC passes. The email header analyser lays these fields out for you.

Read your aggregate reports for every source

One message shows one path. Aggregate reports, sent to the rua address in your DMARC record, cover every source that sends as your domain. Each row shows the From domain, the raw SPF and DKIM results with the domains they were checked against, and the aligned verdicts in the policy_evaluated section. An SPF or DKIM result of pass next to a policy_evaluated result of fail is this exact problem. The DMARC report analyser shows, per source, which mechanism aligned.

Cause 1: the service uses its own bounce domain

Email platforms usually set the envelope sender to their own domain so bounces return to their systems. SPF passes for that domain and does not align with yours. There are two ways out:

1. Set up a custom Return-Path (sometimes called a custom bounce or MAIL FROM domain) if the service offers one. You point a subdomain such as bounce.example.com at the service, SPF is then checked against your subdomain, and it aligns under relaxed mode.
2. Ignore SPF alignment for that service and rely on DKIM, which is usually easier to get and survives forwarding.

Cause 2: the service signs with its own domain

Many platforms sign every message with their own d= until you complete their domain authentication (also called domain verification, sender authentication or DKIM setup). Once you publish the records they give you, usually CNAMEs at <selector>._domainkey.example.com, they sign with d=example.com. Some keep adding their own signature as well, which does no harm: DMARC only needs one aligned signature.

If the selector record has a typo or has not propagated, the platform may fall back to its own signature and alignment fails again. Check the selector with the DKIM checker.

Cause 3: strict alignment

Covered above: adkim=s with a signature from mail.example.com, or aspf=s with a bounce domain of bounce.example.com, fails although everything belongs to you.

Cause 4: a subdomain you did not authenticate

If an application sends as alerts.example.com, alignment is judged against alerts.example.com. Under relaxed mode a DKIM signature for example.com still aligns with it, because both share the organisational domain. A signature from the provider's own domain does not, and the subdomain inherits your DMARC policy through sp= or the parent record. Authenticate the subdomain at the provider as well.

Cause 5: forwarding

When a message is forwarded, the forwarding server sends it from its own IP address, so SPF for your domain fails. If the forwarder rewrites the envelope sender to its own domain, SPF passes for the forwarder, which still does not align. A DKIM signature for your domain survives as long as the forwarder does not change the signed headers or body, so the message still passes DMARC. If the forwarder adds a footer or rewrites the subject, DKIM breaks too and DMARC fails. That is why aligned DKIM matters more than aligned SPF. Why forwarding breaks authentication covers this case in detail.

Fix checklist

1. Confirm the exact From domain, including any subdomain.
2. Remove aspf=s or adkim=s unless you chose strict alignment on purpose.
3. Complete DKIM domain authentication at each sending service so it signs with your domain.
4. Add a custom Return-Path where the service supports one, if you also want SPF to align.
5. Check the reports again once DNS has propagated, and only then tighten your policy.

Run the DMARC checker against your From domain to see the published policy and alignment mode. For the concepts behind this, read DMARC alignment explained. If you would rather have every source's alignment tracked for you, DMARC analytics breaks your aggregate reports down by sender and alerts you when one stops aligning.