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. For most organisations it is the most useful thing DNS can do for security.
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 blocks nothing even with reporting on. Without a reporting address it also tells you nothing, which is the half-finished setup we see most.
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 live in DNS, usually as TXT records (Microsoft 365 publishes DKIM as CNAMEs). 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.
sec.team checks 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. It is free to start.
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.