DMARC fails but SPF and DKIM pass

DMARC (Domain-based Message Authentication, Reporting and Conformance) fails while SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) 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 (Canonical Name records) 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.

Both passes belong to other domains, so neither counts towards DMARC for 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.

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 (Domain Name System), 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 332,492,319 graded domains in the October 2026 census, 131,972,311 publish an SPF record without an enforcing DMARC policy, and 8,262,372 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 bounce-123@mail.vendor.com. 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 steps to switch the signature to your own domain are further down this page. Where the gappssmtp.com name comes from has its own page.

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 (Internet Protocol) replaces the vendor’s, so treat it as the second leg, with aligned DKIM carrying the pass whenever a forwarder sits in the path.

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.

Turning on your own signature in Google Workspace or Microsoft 365

Both providers sign with their own fallback domain until you switch on custom-domain signing. The change is safe to make today. Mail that went out with the default signature goes out with one under your domain, and the provider keeps managing the keys.

Google Workspace

In the Admin console go to Apps, then Google Workspace, then Gmail, then Authenticate email. Select the domain and generate the record. Take the 2048-bit key unless your DNS host can’t store a value that long. Publish the TXT (Text) record it gives you at google._domainkey.yourcompany.com, then wait for DNS, which Google says can take up to 48 hours.

Once the record resolves, go back to the same screen and click Start authentication. This is the step people miss. Generating and publishing the record changes nothing about your outbound mail until you press that button, and Google carries on signing with the gappssmtp.com default.

Microsoft 365

In the Defender portal open Email authentication settings and choose DKIM. Select your custom domain and create the keys. Publish both CNAMEs, selector1._domainkey and selector2._domainkey, pointing at the targets the portal shows you, and copy the targets exactly. Domains enabled before May 2025 point at your tenant’s .onmicrosoft.com; newer ones point at .dkim.mail.microsoft. Guessing the pattern from an old blog post is how people end up with one broken selector.

You need both selectors because Microsoft rotates keys between them. A domain with only selector1 published signs correctly until the next rotation and then stops. Once both CNAMEs resolve, toggle signing on for the domain. In mail received by Microsoft the default shows up as dkim=pass header.d=yourtenant.onmicrosoft.com alongside compauth=fail, the same cause in a different receiver’s vocabulary.

If the signing domain is still the default

Send a fresh test and read header.d= again (Gmail writes it as header.i=@). If it still names the provider, the usual causes are a DNS panel that appended your zone to the CNAME target, a TXT value that got split or truncated, or a Start authentication button that never got clicked. Don’t delete the records later to tidy up, because signing stops the moment the key disappears.

Work through your senders one at a time

1. List each source that sends as your domain: the mailbox provider, the newsletter tool, the CRM, the invoicing app, the support desk.
2. Send one test through each source and read its Authentication-Results.
3. Note per source whether smtp.mailfrom and header.d are your domain or the vendor’s.
4. Fix the leg that can carry your own domain: the DKIM CNAMEs first, then the custom return-path where the vendor offers one.
5. Leave alignment in relaxed mode unless you have a specific, understood reason for aspf=s or adkim=s.
6. 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 from the defaults.exposed census, data as of 12 October 2026. Census numbers move every month; the current values are on the census data page.