SPF, DKIM, and DMARC, plainly
These three checks are how a receiving mail server decides whether a message claiming to be from your domain actually is. Here's what each one does, and how to move from "we have no idea what's sending mail as us" to a fully enforced policy without losing legitimate mail along the way.
Three checks, one decision
SPF and DKIM each verify something different about a message. DMARC is what combines the two and tells the receiving mail server what to actually do.
SPF
Sender Policy Framework
A DNS record listing which mail servers are allowed to send as your domain.
DKIM
DomainKeys Identified Mail
A cryptographic signature on each message, proving it wasn’t altered in transit.
DMARC
Domain-based Message Authentication
Ties SPF and DKIM together and tells receiving servers what to do when a message fails both.
Getting to enforcement
A DMARC policy is deployed in stages, not switched on all at once — moving too fast is the most common way legitimate mail gets silently blocked.
- 01p=noneMonitor
The record exists but enforces nothing. Every sending source that touches your domain shows up in reports — this is how you find out what's actually sending mail as you before you risk blocking any of it.
- 02p=quarantineContain
Once the report data is clean — every legitimate sender accounted for and passing — mail that fails authentication gets routed to spam instead of the inbox.
- 03p=rejectEnforce
The end state: mail that can't prove it's from you is refused outright. This is what actually stops domain spoofing and look-alike phishing.
Want the mechanics — how to actually read a report, or where SPF quietly breaks? The blog covers that. Otherwise, get in touch with questions.