The one-sentence version
SPF says which servers may send for your domain. DKIM proves a message was not altered and came from someone holding your private key. DMARC tells receiving servers what to do when either check fails, and — the part everyone misses — requires that the passing check belong to the domain your recipient actually sees.
SPF — authorising servers
SPF is a TXT record listing the servers permitted to send mail using your domain in the envelope sender. A receiving server looks it up, compares it to the connecting IP, and passes or fails.
example.com. TXT "v=spf1 include:sadasend.net ~all"The ten-lookup limit will catch you
SPF permits a maximum of ten DNS lookups while evaluating a record. Every include, a, mx, ptr and exists costs one, and includes nest — your provider's include may itself contain three more.
Exceed ten and the result is permerror, which most receivers treat as a failure. This is why adding a fourth vendor silently breaks the three that were working. Check the resolved count, not the record length.
- Use one include per sending vendor, and remove vendors you have stopped using.
- Prefer ip4: and ip6: mechanisms where a vendor publishes stable addresses — they cost no lookups.
- Never publish two SPF records on one domain. That is also a permerror; merge them into one.
- Use ~all (softfail) while you are still finding senders, and -all (hardfail) once you are confident.
DKIM — signing messages
DKIM attaches a cryptographic signature to the message headers and body. The receiver fetches your public key from DNS at the selector you named, and verifies it. A pass means the signed portion was not modified in transit and the sender held your private key.
Most providers now hand you a CNAME rather than a raw public key, so they can rotate keys without asking you to touch DNS again. Take the CNAME.
sada._domainkey.example.com. CNAME sada.dkim.sadasend.net.DMARC — the policy, and alignment
DMARC does two jobs. It publishes a policy telling receivers how to treat failures, and it requires alignment: the domain that passed SPF or DKIM must match the domain in the From header your recipient sees.
This is why mail can pass SPF and still fail DMARC. If your provider uses its own bounce domain as the envelope sender, SPF passes for that domain — not yours — and alignment fails. The fix is a custom return-path on your own domain, which is why good providers ask you for a fourth record.
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com; pct=100"Rolling out a policy without losing mail
Do not start at p=reject. Start at none, read the aggregate reports for a few weeks, and find the legitimate senders you had forgotten about — the invoicing tool, the CRM, the help desk.
| Stage | Policy | What it does |
|---|---|---|
| 1 — Observe | p=none | Nothing is blocked. Reports show you who is sending as you |
| 2 — Contain | p=quarantine; pct=25 | A quarter of failing mail goes to spam. Raise pct gradually |
| 3 — Enforce | p=reject | Failing mail is rejected outright. Only after stages 1 and 2 are clean |
The two mistakes worth checking first
- Cloudflare's orange proxy cloud enabled on a DKIM CNAME. Proxying breaks the lookup. Set these records to DNS only.
- A DMARC record with no rua address. Technically valid, completely useless — you have opted into a policy with no visibility into what it is doing.