DMARC, SPF, and DKIM explained (and why you need all three)
Email spoofing is trivially easy without email authentication. Here's how SPF, DKIM, and DMARC work together — and how to check yours.
By default, sending email from any address is trivially easy. SMTP — the protocol that delivers mail — was designed in the 1980s when everyone on the internet knew each other. Authentication was an afterthought.
That means if I run telnet your-mx-server 25 and type the right commands, I can send mail that says it's from [email protected]. No password, no challenge. The mail server will accept it unless you've set up authentication.
SPF, DKIM, and DMARC are the three DNS-based mechanisms that fix this. They're not perfect, but together they're enough to block the vast majority of email spoofing.
SPF: who is allowed to send for this domain?
SPF (Sender Policy Framework) is a TXT record that lists the IP addresses and hosts authorized to send email from your domain.
v=spf1 include:_spf.google.com ~all
# Translation: mail from this domain is sent via Google's servers.
# ~all = "soft-fail" anything else (likely spoofing, but accept it).The all mechanism at the end is critical:
-all— hard fail. Reject mail from anyone not on the list.~all— soft fail. Accept but mark as suspicious (most common).+all— allow anyone. (Effectively no policy.)?all— neutral. No opinion.
Also watch the DNS lookup limit — SPF allows at most 10 DNS lookups per check. Beyond that, the record fails open. This is a common cause of "SPF mysteriously stopped working" when you add too many include: statements.
DKIM: signing each outgoing message
DKIM (DomainKeys Identified Mail) signs each outgoing message with a private key. The receiving server uses the corresponding public key (published in DNS) to verify the signature. If the message was tampered with in transit, the signature breaks.
DKIM records live at <selector>._domainkey.<your-domain>. The selector is just a name — different senders use different ones (Google uses 20161025, SendGrid uses smtpapi, etc).
DMARC: the policy
DMARC ties SPF and DKIM together and tells receivers what to do when authentication fails. It also gives you a way to receive reports about who's sending mail using your domain.
v=DMARC1; p=reject; rua=mailto:[email protected]
# p=reject = "reject mail that fails DMARC".
# rua = "send aggregate reports to this address".The policy can be none (monitor only, take no action), quarantine (send to spam), or reject (bounce). Most organizations start at none to gather reports, then move to quarantine and finally reject once they're confident legitimate mail is passing.
Why you need all three
SPF alone is easy to bypass (forwarded mail, mailing lists). DKIM alone can be stripped by intermediate servers. DMARC requires that either SPF or DKIM passes, and that they align with the From: domain. Without DMARC, receivers don't know what to do when SPF/DKIM fail.
Check your own domain — or anyone else's — with our DMARC / SPF / DKIM Checker. We look up all three records in parallel and report what's there, what's missing, and whether the policy is enforceable.
Keep reading
- How to read an open port (and when to actually worry)An 'open port' isn't a vulnerability by itself — it's information. Here's how to tell whether a port being open is fine, suspicious, or actively dangerous, and what to do about each case.
- How to check an SSL/TLS certificate (and what to look for)Every HTTPS site relies on a TLS certificate. Here's how to read one, what each field actually means, and the things that should make you suspicious.