A recurring moment when setting up DMARC: the checking tool reports pass for SPF, pass for DKIM — and the DMARC report that arrives a few days later still says fail. It looks like a contradiction. It is not. DMARC does not check the same thing as the two mechanisms it builds on. It asks a question neither of them ever asks.
Every message carries two sender addresses
An email names its sender in two independent places, and nothing in the standard requires the two to match.
- The envelope. During the SMTP conversation the sending server states a
MAIL FROM. That address ends up in the headers asReturn-Pathand decides where bounce notifications go. No mail client displays it. - The header. The
From:in the message header is the address the recipient sees — and the only one they judge the message by.
This is not a design flaw. It is the paper letter expressed as a protocol: the envelope and the letterhead are allowed to say different things. The return address on the envelope belongs to the mailroom, the signature inside belongs to the author.
SPF checks the envelope, the reader reads the header
That is the whole matter. SPF answers one question: is this server allowed to send for the domain in MAIL FROM? The domain in From: plays no part in an SPF check. It is not checked, not compared, not mentioned.
A bulk sending provider puts its own domain in the envelope, because the bounce notifications need to land with them. The header carries yours. So SPF checks the provider domain, finds the provider record, and correctly reports pass — for a domain nobody ever sees.
What DMARC adds: alignment
DMARC does not invent a third check. It takes the results of SPF and DKIM and asks one extra question: does the checked domain belong to the domain in From:? That comparison is called alignment.
DMARC passes when at least one of the two paths passes and is aligned:
- SPF aligned: the domain in
MAIL FROMmatches the domain inFrom:. - DKIM aligned: the domain in the signature's
d=field matches the domain inFrom:.
A pass without alignment counts for nothing. That is why a report can show two green ticks and the message can still fail DMARC.
Strict or relaxed
How exact the comparison is depends on two settings in the DMARC record: aspf for SPF and adkim for DKIM. Each takes two values, and the difference matters in practice.
| Mode | Value | Matches From: info@company.com |
|---|---|---|
| relaxed (default) | r | mail.company.com yes, sender.example no |
| strict | s | only exactly company.com |
With nothing specified, r applies. Relaxed means the same organisational domain is enough, subdomains included. That is precisely why the usual workaround works — more on that below. Strict is rarely necessary and tends to break more than it prevents.
The three cases that occur in practice
| Situation | SPF | DKIM | DMARC |
|---|---|---|---|
| Own server, own domain throughout | pass, aligned | pass, aligned | pass |
| Provider with no setup of your own | pass, not aligned | pass on a foreign domain, not aligned | fail |
| Provider signing DKIM with your domain | pass, not aligned | pass, aligned | pass |
The middle case is the common one, and the one that suddenly becomes visible when the policy moves to p=quarantine. While the policy sits at p=none, the result changes nothing about delivery — it only appears in the report, where nobody looks at it.
The way out runs through DKIM, not SPF
Two routes lead out of the middle case, and they cost very different amounts of effort.
The easy one: have DKIM signed with your domain. Almost every sending service offers this. You add two or three CNAME records, and the service then signs with d=company.com instead of its own domain. The envelope stays as it is — it does not need to be aligned, because one aligned path is enough. This is the standard route and takes about fifteen minutes.
The laborious one: your own return path. Some services allow a dedicated bounce subdomain such as bounce.company.com, pointed at their infrastructure by CNAME. Then SPF is aligned as well, because in relaxed mode a subdomain counts towards the main domain. This is rarely required. It is worth doing when you want both paths covered, so that a DKIM path broken in transit does not take everything down with it.
How to spot it in the report
The aggregate reports DMARC requests list both results separately for each sender: the raw pass from SPF and DKIM, and the result after alignment. An entry showing spf: pass next to an unaligned result describes exactly the situation in this article. Anyone who looks only at the summary figure after switching DMARC on will miss it — the two columns sit side by side for a reason.
In short: SPF and DKIM check whether a server may send for a domain. DMARC checks whether that permission applies to the domain the recipient actually sees. Two green ticks are therefore not yet a DMARC pass — the decisive question is asked one level up.