DMARC fails but SPF and DKIM pass

DMARC fails while SPF and DKIM pass because both of them passed for a domain that isn’t yours. SPF checked the bounce address, DKIM checked whichever domain signed the message, and DMARC compared each of those with the domain in your From header and found no match. The header you have open already shows which domain is wrong, and the fix is a handful of CNAMEs in the sending service’s domain panel.

The header that names the problem

Send yourself a message through the failing service, open the raw source and find the Authentication-Results header. An unaligned result looks like this:

Authentication-Results: mx.google.com;
       spf=pass smtp.mailfrom=bounces.espmail.net;
       dkim=pass header.d=espmail.net;
       dmarc=fail (p=NONE) header.from=yourcompany.com

The block carries three domains on three lines, and the whole diagnosis is comparing two of them with the third.

Does smtp.mailfrom= end in your domain? Here it’s bounces.espmail.net, so the SPF leg is unaligned.
Does header.d= end in your domain? Here it’s espmail.net, so the DKIM leg is unaligned.
header.from= is the domain DMARC is defending. Neither leg matched it, so the verdict is dmarc=fail while both individual checks say pass.

Each check told the truth about its own domain, and none of them said anything about yours.

Three checks, three different domains

DMARC asks whether SPF or DKIM passed for a domain that matches the From domain the recipient sees. A plain SPF pass on some other domain doesn’t answer that question. The extra condition is called alignment, and it’s the reason DMARC exists at all: without it, anyone could pass SPF on a domain they own while displaying yours in the From header.

Check	The domain it evaluates	Where it shows
SPF	The Return-Path (RFC5321.MailFrom, the bounce or envelope-from address), never the From header	`smtp.mailfrom=` in Authentication-Results
DKIM	The domain in the signature’s `d=` tag, whatever the signer chose	`header.d=` in Authentication-Results
DMARC	Your From-header domain, and it needs SPF’s domain or DKIM’s `d=` to match it	`header.from=` in Authentication-Results

One aligned leg is all DMARC needs, per sending source. If DKIM signs as your domain, SPF can pass on the vendor’s bounce domain all day and the message still passes DMARC.

The census reads DNS, so it can report which records and policies exist on a domain and has no view of whether a particular message aligned. What it can count is how far most domains stop short of the finish. Of the 316,600,902 graded domains in the September 2026 census, 127,330,729 publish an SPF record without an enforcing DMARC policy, and 7,862,126 carry all three of SPF, DKIM and an enforcing DMARC policy, the combination that lets a receiver act on the result.

Which branch you’re in

Three causes produce that header, and the two unaligned domains tell you which one you have.

A vendor’s bounce domain

A newsletter platform or CRM sends with a Return-Path like [email protected]. SPF is checked against vendor.com and passes, DKIM passes with d=vendor.com, and DMARC fails because neither passing domain matches yourcompany.com. Editing your own SPF record can’t fix this case, because your record was never consulted.

The vendor’s dashboard may well report SPF and DKIM as verified. That usually means the vendor’s own sending passes on the vendor’s domains, which is a different statement from your mail aligning. A strict -all qualifier on your own SPF record strengthens SPF’s verdict on the Return-Path domain and still does nothing for DMARC unless that domain is yours.

Your mail provider’s default signature

Google Workspace and Microsoft 365 DKIM-sign outgoing mail by default with their own fallback domains, gappssmtp.com and onmicrosoft.com. DKIM reports pass on the fallback domain and DMARC fails on yours. If header.d= in your header ends in one of those two, you’re in this branch, and the page on provider default signing walks through switching the signature to your own domain.

A strict tag in your own DMARC record

If the mismatch is between bounce.yourcompany.com and yourcompany.com, the two domains already share a registrable domain, and the fail comes from your own record telling receivers to demand an exact match. That’s the strict-alignment branch, and the tag that causes it is covered next.

Relaxed and strict alignment

DMARC has two matching modes, set with the aspf tag for SPF and the adkim tag for DKIM.

Relaxed alignment (r, the default) requires the two domains to share the same organisational domain, the registrable domain per the Public Suffix List. bounce.yourcompany.com aligns with yourcompany.com, and so does a DKIM d=mail.yourcompany.com. This is why vendor custom return-paths and custom DKIM, which live on subdomains, work.

Strict alignment (s) requires the domains to match exactly, character for character, and bounce.yourcompany.com no longer aligns with yourcompany.com.

If the record mentions neither aspf nor adkim, it’s in relaxed mode. Where alignment fails unexpectedly and the record carries aspf=s or adkim=s, that tag alone can be the bug, because strict mode breaks legitimate subdomain senders. Relaxed mode already demands the same registrable domain, which a spoofer doesn’t control, so removing the tag costs you nothing you were relying on.

The free scan reads your DMARC record and shows its policy and any alignment tags, alongside your SPF record and whether a DKIM selector is visible, so you know which leg to fix before you touch DNS.

Fix the leg that can carry your domain

Take the DKIM leg first where you can. Most sending services offer a domain-authentication panel with a few CNAME records that let the service sign as d=yourcompany.com or as a subdomain, which aligns in relaxed mode. Aligned DKIM survives forwarding, because the signature travels with the message.

For the SPF leg, enable the vendor’s custom return-path, often called a custom bounce domain. It’s typically one CNAME such as bounce.yourcompany.com pointing at the vendor. SPF then passes on your organisational domain and aligns. It doesn’t survive forwarding, because any forwarder’s IP replaces the vendor’s, so treat it as the second leg, with aligned DKIM carrying the pass whenever a forwarder sits in the path.

Fix	What it involves	Survives forwarding
Aligned DKIM (custom-domain signing)	A few CNAMEs in the vendor’s domain-authentication panel	Yes, the signature travels with the message
Aligned SPF (custom return-path)	One CNAME, where the vendor offers it	No, any forwarder’s IP replaces the vendor’s

Mail that fails DMARC only when a recipient forwards it is the SPF leg dying in transit, and the same answer applies: aligned DKIM carries the pass through the forwarder.

Work through your senders one at a time

List each source that sends as your domain: the mailbox provider, the newsletter tool, the CRM, the invoicing app, the support desk.
Send one test through each source and read its Authentication-Results.
Note per source whether smtp.mailfrom and header.d are your domain or the vendor’s.
Fix the leg that can carry your own domain: the DKIM CNAMEs first, then the custom return-path where the vendor offers one.
Leave alignment in relaxed mode unless you have a specific, understood reason for aspf=s or adkim=s.
Send one more test through each source and confirm dmarc=pass in the header.

That header showed p=NONE, which reports and blocks nothing. Once your real senders align, the path from p=none to a policy that protects you is on the DMARC page, and the same Authentication-Results line tells you when each source is ready to move.

Figures as of 5 September 2026, from the September 2026 edition of the defaults.exposed census. Census numbers move every month; the current values are on the census data page.