SPF, DKIM, DMARC: Email Auth in Plain English
Why spoofed mail carries your domain, what each record actually verifies, and the order to deploy them without losing legitimate mail.
Short answer
SPF authorizes which servers may send mail for your domain. DKIM signs messages. DMARC sets policy and reporting. Deploy SPF and DKIM first, then DMARC at p=none, then tighten.
What each record does
SPF: who may send. DKIM: cryptographic signature. DMARC: what receivers should do on failures and where to send reports.
All three matter. One alone leaves easy spoof paths.
Readers skimming spf dkim dmarc explained often stop at definitions. The part that prevents incidents is the verification step after the change - and the habit of re-checking after the next deploy that touches the same layer.
Deploy order
Inventory senders, SPF includes them, DKIM on each platform, DMARC p=none with reporting, then quarantine, then reject.
Skipping inventory is how you lock out the invoice ESP on day two of p=reject.
Common failure mode for spf dkim dmarc explained: staging looks fine, production still serves the old config because a CDN, load balancer, or second vhost was never updated. Always verify the hostname customers hit.
Proof
Send test mail through each stream and check headers for SPF/DKIM pass and DMARC alignment.
DNS records that exist but do not align still fail DMARC - verify with real messages.
If this section on spf dkim dmarc explained becomes a recurring ticket, automate the check. Manual one-offs rot; a post-deploy assertion or weekly grade keeps the control honest.
What to do this week
- Inventory every system that sends mail as your domain.
- Publish/fix SPF to include them; enable DKIM per platform.
- Publish DMARC p=none with a reporting mailbox.
- Read one week of aggregate reports before tightening.
Spoofed mail is a domain problem, not only an inbox problem.
Update log (1)
2026-07-01Editorial form rewrite for length and uniqueness.
Sources + verification
Practical guidance based on mainstream browser behavior, common reverse-proxy configuration, and widely published RFCs and vendor docs. Verify on your own stack with curl, browser devtools, and a re-scan after each change.
