DMARC Alignment: Why SPF and DKIM Pass but DMARC Fails
Here’s the short version: DMARC can fail even when SPF and DKIM both pass, because those checks may have authenticated some other domain, not the one in the visible From address. If the domains don’t match, the pass doesn’t count toward DMARC alignment. I see this one all the time. Your sending platform shows green checks for SPF and DKIM, and your DMARC reports still list failures. Annoying? Very. Below I go through which domains get compared, how relaxed and strict alignment differ, what usually goes wrong with third-party senders, and how to read the headers that show you the mismatch.
What does DMARC alignment actually check?
It checks one thing: does the domain in the From: header match the domain that SPF or DKIM authenticated? As Google’s guide to setting up DMARC explains, a message passes or fails DMARC depending on how closely the From: domain matches the sending domain from SPF or DKIM. You don’t need both to line up. One mechanism that passes and aligns is enough. From a marketer’s side there are usually three domains involved: the From address your recipients read, the Return-Path (the bounce address that SPF checks) and the DKIM signing domain, which shows up as d= in the signature.
Which domains are compared: From vs Return-Path vs DKIM d=
For SPF alignment, the From domain is compared with the Return-Path domain. For DKIM alignment, it’s compared with the d= domain in the DKIM signature. Now the catch. SPF only ever authenticates the Return-Path bounce address, and plenty of platforms point that at their own domain by default. So SPF passes for the platform, and your brand domain gets nothing out of it. DKIM can go wrong the same way. If the platform signs with d=platform.com, the signature verifies fine. It just doesn’t align with yourbrand.com.
These are the three header fields you’re looking for:
- From: the address recipients see, and the domain DMARC protects.
- Return-Path (also shown as smtp.mailfrom): the bounce domain SPF authenticates.
- DKIM d= (also shown as header.d): the domain that signed the message.
Relaxed vs strict alignment: the aspf and adkim tags
Relaxed alignment accepts subdomains of the From domain. Strict wants an exact match, nothing less. According to Google’s DMARC record documentation, you set the alignment mode for SPF and DKIM in your DMARC record with the aspf and adkim tags. “r” means relaxed (that’s the default) and “s” means strict. Say a message comes from news.brand.com and is signed with d=brand.com. Under relaxed DKIM alignment it passes. Under strict it fails. So if the failures started right after someone added adkim=s or aspf=s, the first question is simple: do you send from subdomains?
Why DMARC fails with a third-party sending platform
Most of the time the platform is authenticating its own domain, not yours. The usual suspects:
- the platform’s shared default DKIM signature, which puts its own domain in d=;
- a Return-Path owned by the platform, so SPF only passes for the platform’s domain;
- a custom DKIM key that’s published in DNS but was never switched on in the platform’s settings (more common than you’d think);
- a From address on a different domain than the one you verified;
- forwarding, which resends the message from a new server and breaks SPF.
And a status like “SPF and DKIM configured”? It only tells you that authentication works. Whether either result aligns with your From domain is a separate question, and the dashboard won’t answer it.
How to check DMARC alignment in email headers
Open the raw source of a test message and compare the From domain with smtp.mailfrom and header.d in the Authentication-Results line. Step by step:
- Send a test campaign to a mailbox you control.
- Open the raw message (in Gmail it’s called “Show original”).
- Find the Authentication-Results header.
- Compare three domains: the one after spf=pass smtp.mailfrom=, the one after dkim=pass header.d= and the one in header.from=.
If you see a pass next to a domain that isn’t the header.from domain, authentication works and alignment doesn’t. Your aggregate DMARC reports list the same domains, so this check also lets you tie a failing report row back to the platform that sent it.
How to fix alignment for your sending domain
The most reliable fix is getting the platform to sign DKIM with your own domain. You can also set a custom Return-Path on your domain so SPF aligns as well. The DNS records for both are in our guide to SPF, DKIM and DMARC setup. MailCraft has a setup wizard for these records and supports a custom sending domain from the Pro plan, as listed among the MailCraft deliverability features. That said, you still have to confirm the result in the headers for every sender you use. No shortcuts there. Fix alignment while your policy is still in monitoring mode, then tighten it using the steps for choosing a DMARC policy level.
After every DNS or platform change, send a fresh test and read the headers again. Then watch the next aggregate reports to make sure DMARC alignment passes for every source that sends as your brand.
FAQ
Does DMARC need both SPF and DKIM to align?
No. One mechanism that passes and aligns is enough. If I had to pick, I’d go with DKIM, because its signature usually survives forwarding and SPF often doesn’t.
Should I use strict or relaxed alignment?
Relaxed is the default, and it works for most senders who send from subdomains of their main domain. Only go strict if every service sends with exactly the From domain. Under strict, any subdomain fails.
Why do my DMARC reports show failures from sources I don’t recognize?
It could be forgotten tools still sending on your behalf (an old CRM, a helpdesk, that kind of thing). Or it could be someone spoofing you. Identify each source by its Return-Path and DKIM domains before you touch your policy, so you don’t end up blocking legitimate mail.
