The advice is always phrased as a verb of addition. Just add DMARC. Add it like you’d add a meta tag or a line to a config file. It shows up in security checklists, in “10 things to harden your domain” posts, in the remediation notes auditors paste from a template. And it is, as stated, terrible advice — not because DMARC is bad, but because the word “add” describes about five percent of the actual job and hides the ninety-five percent that matters.
Here’s what “just add DMARC” actually produces in the wild. Someone reads the advice, publishes a TXT record that says v=DMARC1; p=none, watches the checklist item turn green, and moves on. They now “have DMARC.” They are also exactly as spoofable as they were the day before, because p=none tells receiving servers to do nothing. It’s a policy of “please observe, take no action.” The spoofed invoice still lands. The fake CEO wire request still lands. Nothing was defended. A box got checked.
I’ve written before about how p=none is where DMARC deployments go to die. But the reporting trap is only half of why “just add it” fails. The other half is more technical, less discussed, and it’s the reason even people who do set p=reject sometimes discover they’ve quietly broken their own mail. It’s called alignment, and almost nobody who says “just add DMARC” has ever explained it.
SPF and DKIM Can Both Pass and DMARC Still Fails
This is the part that breaks people’s brains the first time, so let me be specific.
DMARC does not care whether SPF passes. It does not care whether DKIM passes. It cares whether SPF or DKIM passes for a domain that matches the one in the From header your recipient actually sees. That matching requirement is alignment, and it’s the entire mechanism (RFC 7489 defines it). SPF and DKIM are the old locks. Alignment is the thing DMARC bolted on top to fix the hole both of them left: neither one, on its own, has anything to say about the visible From address.
Look at how they can drift apart. SPF authenticates the envelope sender — the MAIL FROM return-path address the servers negotiate, which your recipient never sees. DKIM authenticates whatever domain is in the signature’s d= tag. Your recipient, meanwhile, is looking at the From: header, which can be a completely different domain from either of those. An attacker can register not-your-bank.example, set up perfectly valid SPF and DKIM for it, put “Your Bank” in the display name and security@yourbank.com in the From, and produce a message where SPF passes and DKIM passes and every legacy check is green — while the From domain is one they don’t own at all. That’s the spoofing SPF and DKIM never closed. Alignment closes it by demanding that the authenticated domain and the From domain be the same organization.
Which is great, until it turns around and bites the legitimate sender.
The ESP Trap
Say you send your marketing mail through a big email platform. You dutifully “added DMARC.” You even went to p=reject because someone told you enforcement is the goal. Then your campaign open rates crater and your own newsletter starts bouncing at Gmail.
Here’s why. That platform sends with its own return-path domain, so SPF authenticates and aligns to the platform’s domain, not yours — SPF alignment fails for you. And unless you specifically set it up otherwise, the platform DKIM-signs with d= set to its domain too — so DKIM authenticates, but it aligns to the platform, not to your From. Both underlying checks pass. Neither aligns to the address your subscribers see. DMARC fails. And because you jumped to p=reject, you just told the entire internet to throw your own newsletter in the trash.
The fix isn’t hard, but it is work, and it is exactly the work “just add DMARC” pretends doesn’t exist: you set up a custom return-path (usually a CNAME the platform gives you) so SPF aligns to your domain, and you configure the platform to DKIM-sign with a key published on your domain so DKIM aligns. You do this for the marketing platform. And the invoicing system. And the helpdesk. And the HR tool. And the one weird relay in the Frankfurt office. Every single service that sends as you has to be brought into alignment, one at a time, or enforcement will eat its mail.
That’s not a record you add. That’s an inventory project.
What the Advice Should Say
DMARC done right is a sequence, and every step is a verb of doing, not adding:
Publish p=none with a reporting address, and — this is the step everyone skips — actually ingest the reports. The aggregate reports are ugly XML, they arrive in bulk, and they are the only map you will ever get of who sends mail as your domain. Without reading them you are blind. You will not know that a SaaS trial from 2023 still sends as you, or that payroll’s third-party vendor never aligned, until you either read the reports or break their mail at enforcement. Reading them is the job.
Then you fix alignment for every legitimate sender the reports reveal. Then, and only then, you move to p=quarantine, watch, and finally p=reject. The record changes are trivial. The discovery and remediation between them is the actual security work, and it takes weeks to months for a real organization, because real organizations send mail from more places than anyone can remember.
None of that fits in the word “add.”
Why the Bad Version Spread
The bad advice won because it became compliance-shaped. In early 2024 Google and Yahoo started requiring bulk senders — roughly anyone sending over 5,000 messages a day to their users — to publish a DMARC record. The requirement, crucially, was to have a record. A p=none record satisfies it. So a huge wave of domains “added DMARC” to keep their mail flowing, and the industry got to announce a jump in adoption that was, in enforcement terms, almost entirely cosmetic. The advice and the mandate reinforced each other: both treat the record as the deliverable.
I don’t think DMARC is the problem. The protocol does a genuinely clever thing — it ties authentication to the identity the human actually reads, which SPF and DKIM never did. The problem is that we compressed a multi-week alignment-and-monitoring project into a two-word imperative and then acted surprised that domains with DMARC still get spoofed and legitimate senders still get their mail rejected.
If someone tells you to “just add DMARC,” ask them one question: aligned to what? If they don’t know what you mean, they’ve never actually done it. They just added the record.