Email security: SPF, DKIM and DMARC
How the three email authentication records work together, why p=none leaves you spoofable, and how to move to enforcement safely.
By default, anyone can send email claiming to be from your domain: the "From" address is trivially forged. Three DNS records fix that, and they only work as a set. This is the single highest-value security win available in DNS.
SPF: who is allowed to send
Sender Policy Framework is a TXT record at your domain apex listing which servers may send mail for you. A receiver checks the sending server's IP against that list.
Example: v=spf1 include:_spf.google.com ~all ("Google may send; treat everything else as suspect").
The details
SPF authorises the envelope sender (Return-Path), not the visible From. It's limited to 10 DNS lookups: exceed that and SPF returns permerror, silently weakening you. The final qualifier matters: ~all (softfail) vs -all (hardfail) vs the dangerous +all (allow anyone).
DKIM: a tamper-proof signature
DomainKeys Identified Mail adds a cryptographic signature to every message. Your public key is published in DNS at selector._domainkey.yourdomain; the receiver uses it to verify the signature was made with your private key and that the message wasn't altered in transit.
The details
The selector lets you run multiple keys (per provider, or for rotation). The record is a TXT holding the public key (v=DKIM1; k=rsa; p=…). Rotate keys periodically and keep the published key in sync with what your provider signs with.
DMARC: the policy that ties it together
SPF and DKIM each authenticate a technical identifier, but not the address your recipient actually sees. DMARC (a TXT at _dmarc.yourdomain) closes that gap: it requires SPF or DKIM to align with the visible From domain, and tells receivers what to do when neither passes.
Example: v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain ("reject unaligned mail, and send me aggregate reports").
The details
Alignment is the key idea: a spoofer can pass SPF for their own domain, but they can't make it align with yours. Policies escalate p=none (monitor only) → p=quarantine → p=reject. Start at none with reporting, read the reports, then tighten. p=none with no reporting address is the most common half-finished setup: it protects nothing.
How they combine
- SPF: is the sending server allowed?
- DKIM: is the message genuinely signed and untampered?
- DMARC: does an authenticated identity align with the visible From, and what happens if not?
All three are TXT records. All three can be edited, mistyped, or dropped without any outward sign, which is exactly why they need validating and watching, not just a one-time setup.
DNS Canary validates SPF, DKIM and DMARC against the RFCs, flagging a missing DMARC policy, an SPF record over the 10-lookup limit, or a p=none that never got tightened, and alerts you if any of them change or disappear.
And if a domain sends no email at all? It still needs SPF and DMARC, just in a different form: see non-mail domains: still spoofable.