SPF, DKIM and DMARC: how to set all three up and what each one stops

Google and Yahoo both require authentication from bulk senders, so this is no longer a best practice with a deadline somewhere in the future. It is the floor, and a shop without all three is a shop whose mail is increasingly treated as suspicious.

The acronyms obscure three simple and different jobs: who may send, whether the message was altered, and what to do when the answer is no.

SPF: which servers may send as you

One TXT record on your domain listing the services allowed to send mail with your address in the envelope sender. Without it, anybody can, and receivers have nothing to check against.

• One SPF record per domain. Two records is not twice as good, it is a permanent failure. Merge them.
• The ten-lookup limit is the classic silent killer. Every include: costs lookups and providers nest their own. Exceed ten and SPF returns permerror, which many receivers treat as a fail — and nothing in your tooling tells you.
• End with -all (hard fail) once you are confident, not ?all, which asserts nothing.
• SPF breaks on forwarding. That is expected, and it is exactly why DKIM exists.

DKIM: proof the message was not altered

A cryptographic signature over the headers and body, with the public key published in DNS. The receiver verifies it and knows the message genuinely came from a holder of that key and arrived unmodified.

1. A selector per sending service. campaigns._domainkey, receipts._domainkey. This lets you rotate or remove one provider without touching the others.
2. 2048-bit keys where your DNS provider allows the record length.
3. Rotate annually, and keep the old key published for a fortnight so mail in flight still verifies.
4. DKIM survives forwarding, which SPF does not. This is why a message forwarded through a mailing list can still authenticate.

DMARC: what to do when the checks fail

DMARC also adds alignment: it is not enough for SPF or DKIM to pass, the passing domain has to match the one in the visible From address. This is what actually stops somebody spoofing your brand.

1. Start at p=none with rua= pointing at a mailbox you will read.
2. Read the aggregate reports for two to four weeks. You will find sending services you had forgotten — the invoicing tool, the helpdesk, the shop plugin.
3. Fix or authorise each one, then move to p=quarantine, then p=reject.
4. Go gradually with pct= if your volume is large.

Stopping at p=none is the most common outcome and it protects nobody. It is a monitoring mode, not a destination.

The order to do it in

Not the order the acronyms are usually listed. DMARC monitoring first tells you what you actually have before you change anything.

1. Publish p=none DMARC with a reporting address.
2. Read reports for a fortnight. Inventory every service sending as you.
3. Fix SPF into a single record inside the lookup limit.
4. Set up DKIM with a per-service selector for each legitimate sender.
5. Confirm alignment in the reports, then move to quarantine, then reject.

How to verify it actually works

Do not trust a tool that checks DNS syntax. Send a real message to a real mailbox at Gmail, Outlook and one more provider, and read the raw headers. You want spf=pass, dkim=pass and dmarc=pass, with the DKIM domain aligned to your From domain.

Do this again after any change of sending provider, any DNS migration and any new tool that sends on your behalf — those are the three moments this breaks, and none of them produce an error anywhere you are looking.