You now know two protocols. Neither of them looks at the address the recipient sees. That is not an oversight in either specification — it is a consequence of what each was built to do — but it leaves a gap wide enough to drive an entire category of fraud through.
Three domains in one message
| Domain | Where it lives | Authenticated by | Seen by the reader |
|---|---|---|---|
MAIL FROM | The SMTP envelope | SPF | No |
d= | The DKIM-Signature header | DKIM | No |
From: | The message headers | Nothing | Yes |
The one identity that matters to a human being is the one with nothing checking it.
The attack this permits
An attacker registers a throwaway domain, publishes a correct SPF record for it, signs with a correct DKIM key for it, and sends:
MAIL FROM:<bounce@attacker-owned.example> <- SPF passes, for attacker-owned.example DKIM-Signature: ... d=attacker-owned.example <- DKIM passes, for attacker-owned.example From: "Acme Payroll" <payroll@acme.com> <- what the victim reads
The receiving server records spf=pass and dkim=pass, both truthfully, and the recipient sees a message from Acme Payroll. Nothing malfunctioned. The checks answered the questions they were asked, and nobody asked the right question.
What DMARC adds
The claim DMARC makes
For a message displaying this domain in the From header, at least one of SPF or DKIM must have passed for a domain related to it — and here is what to do if neither did.
Three distinct additions, specified in RFC 7489:
| Addition | What it does |
|---|---|
| Alignment | Ties an SPF or DKIM pass to the From header domain. Without this, a pass for any domain would count — which is exactly the hole above. |
| Policy | Tells receivers what to do when nothing aligns: nothing, quarantine, or reject. SPF and DKIM produce results; DMARC produces an instruction. |
| Reporting | Asks receivers to send back aggregate data on what they saw. This is the part that makes deployment possible at all — without it you would be enforcing blind. |
Reporting is not a side feature
It is tempting to treat the reporting as optional and go straight to a policy. In practice the reporting is the reason the protocol is deployable: no organisation of any size knows its full list of senders, and the reports are the only way to discover the ones nobody remembers. Marketing signed up for a platform two years ago; a facilities system sends booking confirmations; a subsidiary still uses the parent domain.
Publishing a policy without first reading reports is how organisations block their own invoices. The staged path in the last module of this course exists for exactly that reason.