SPF, DKIM and DMARC explained: what each record does and how to check yours
The three DNS records that stop other people sending mail as your domain, what a correct one looks like, the mistakes that silently break them, and how to check them for free.
Email has no built-in sender verification: anyone can put your domain in the From header. SPF, DKIM and DMARC are three DNS records that let receiving mail servers check whether a message claiming to be from example.com was actually sent by something example.com authorised. Together they are the difference between your invoices landing in the inbox and a phishing campaign using your name.
SPF — who may send
A TXT record on the domain listing the servers allowed to send mail for it. The receiver checks the connecting server's IP against the list.
example.com. TXT "v=spf1 include:_spf.google.com include:sendgrid.net -all"
include:pulls in another domain's SPF (your mail provider, your transactional sender).- The final mechanism matters:
-all(hard fail) rejects everything else,~all(soft fail) marks it suspicious,?allsays nothing, and+allauthorises the whole internet — never use it. - Limit of 10 DNS lookups. Every
include:,a,mx,redirect=andexists:counts, and includes nest. Past 10 the record is a permanent error and SPF fails for everyone. This is the most common silent breakage. - Exactly one SPF record. Two
v=spf1TXT records on the same name is also a permanent error.
DKIM — was it tampered with
The sending server signs each message with a private key; the public key sits in DNS at <selector>._domainkey.example.com. The receiver verifies the signature, proving the message came from a holder of the key and was not altered in transit.
google._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq…"
Each sending service uses its own selector, so a domain typically has several. Rotate keys when a provider is dropped; a stale selector is harmless but a missing one for an active sender means every message fails DKIM.
DMARC — what to do when checks fail, and tell me about it
A TXT record at _dmarc.example.com that tells receivers what to do with mail that fails SPF *and* DKIM alignment — and where to send reports. Without DMARC, SPF and DKIM are advisory.
_dmarc.example.com. TXT "v=DMARC1; p=quarantine; sp=reject; rua=mailto:dmarc@example.com; pct=100"
| Tag | Meaning |
|---|---|
p= | Policy for the domain: none (monitor only — spoofed mail is still delivered), quarantine (spam folder), reject. |
sp= | Policy for subdomains; default is the same as p. |
rua= | Where aggregate reports go. Without it you learn nothing about who is sending as you. |
pct= | Percentage of failing mail the policy applies to — useful for a gradual rollout to reject. |
adkim= / aspf= | Strict or relaxed alignment between the From domain and the SPF/DKIM domains. |
The rollout that works
- Publish SPF with
~alland DKIM for every sender. Publish DMARC withp=noneand arua=address. - Read the reports for two to four weeks. They list every source sending as your domain, including the marketing tool nobody told IT about.
- Fix the legitimate senders (add them to SPF, enable DKIM), then move to
p=quarantine, thenp=reject. Tighten SPF to-alllast.
+all, too many lookups, p=none, no rua. A Domain Security monitor checks them continuously alongside DNSSEC and the registry record, and opens a change event when any of them moves.