DMARC
A DNS policy that tells receivers what to do when SPF/DKIM checks fail for your domain.
Say it out loud
“Our written instruction to Gmail about what to do with mail that fails our checks: ignore it, bin it, or refuse it.”
DMARC ties SPF and DKIM to the visible From domain and states, publicly, what a receiver should do when neither aligns. It can also request aggregate reports so you can see who is sending as you. The policy lives on your domain's DNS, which means no platform can publish it for you and no platform can get it wrong on your behalf.
- 1
- DMARC record per domain
- RFC 7489 §6.6.3
Where every domain starts. It changes nothing about delivery, and tells you everything.
The destination. Also the fastest way to break your invoicing tool if you arrive here without reading reports first.
Yours
Nobody does this for you.
What goes wrong
Publishing p=reject on day one because a checklist said DMARC was required. Every forgotten sender — the invoicing platform, the recruiting tool, the CEO's newsletter plugin, the ticketing system — starts failing immediately, and you find out from the sales team rather than from a dashboard.
What people get told
The claim. “p=none does nothing, so skip to reject.”
Actually. p=none plus a reporting address is the only way to discover who is currently sending as your domain, and there is always someone you have forgotten. It is the reconnaissance phase, and skipping it is precisely how the rollout to reject goes wrong.
Check it yourself
Read the policy and whether anyone is reading the reports
Run it now →The dated rules behind this
A definition is not a citation. These are the pages with the primary source, the date it was published, and what to do about it.
See also
Where this sits
Stop 4, identity gets checked. The receiver works out whether the message really comes from who it says it does.