SPF, DKIM and DMARC explained

Email was designed without any way to prove who sent a message. SPF, DKIM and DMARC are the three DNS records bolted on afterwards to fix that. Get them right and client email lands in the inbox. Get them wrong and it lands in spam, or someone else sends invoices in your client’s name. Here is what each one does.

The problem they solve

Anyone can put anything in the From field of an email. Nothing in the original protocol checks it. That is how phishing works, and it is why the receiving server needs some way to ask “was this really sent by someone allowed to send for this domain”.

The three records answer that question in different ways, and they only work properly together.

SPF: who is allowed to send

SPF is a TXT record listing the servers permitted to send email for your domain. The receiving server looks up the record, compares it with the server the message actually came from and passes or fails accordingly.

A typical record looks like this:

v=spf1 include:_spf.google.com include:servers.mcsv.net ~all

Every service that sends on the domain’s behalf needs to be in there: the mail host, the newsletter platform, the CRM, the accounting system, the help desk. The ~all at the end is a soft fail, meaning treat anything else as suspicious. -all is a hard fail, meaning reject it. Move to -all once you are confident the list is complete.

Two things catch people out. You may only have one SPF record per domain, so a second one invalidates both. And SPF allows a maximum of ten DNS lookups, which a handful of include: statements can quietly exceed, at which point the whole record fails.

DKIM: proof the message was not altered

DKIM adds a cryptographic signature to every outgoing message. The private key sits with the sending service, the matching public key is published in DNS under a selector, and the receiving server verifies the signature against it.

That gives you two things SPF cannot: proof the message really came from an authorised sender, and proof the content was not changed in transit. It also survives forwarding, which SPF often does not.

Each sending service issues its own selector and key, so if the domain sends from three platforms it needs three DKIM records. Your provider generates them, you publish them.

DMARC: what to do when the others fail

DMARC is the policy layer. It tells receiving servers what to do with a message that fails SPF and DKIM, and it asks them to send you reports about it.

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

The policy has three settings. p=none means take no action, just report, which is where you start. p=quarantine sends failures to spam. p=reject refuses them entirely.

DMARC also introduces alignment: it is not enough for SPF or DKIM to pass, the domain they pass for has to match the domain in the visible From address. This is what stops a spammer passing SPF for their own domain while displaying your client’s name.

Setting them up in the right order

1. Inventory every sender. List every system that sends email as the domain, including the ones marketing set up without telling anyone.
2. Publish SPF covering all of them, ending in ~all.
3. Enable DKIM on each sending platform and publish the selector records.
4. Publish DMARC at p=none with a reporting address, then leave it for a few weeks.
5. Read the reports. They will show senders you forgot. Fix those.
6. Tighten. Move to p=quarantine, watch, then p=reject.

Skipping straight to p=reject is the classic mistake. It works right up until the moment the client’s invoicing system, which nobody mentioned, stops being delivered.

The mistakes worth checking for

Leaving DMARC at p=none forever protects nobody, it only reports. A second SPF record added by a new supplier breaks the first. Exceeding the ten-lookup limit fails silently. And a new marketing tool added six months after setup will not be in any of the three records unless somebody remembers to add it.

You can check all three on a domain right now with the free SPF, DKIM and DMARC checker, or look at the raw records with the DNS lookup tool.

Watch them over time

These are DNS records, which means they change without a deploy and without a trace. A registrar migration, a new email platform or a tidy-up by someone with access can drop one, and the first sign is usually a client saying their emails have stopped arriving.

Janitor checks SPF, DKIM and DMARC on every domain you manage on a schedule and flags a record that weakens or disappears, so you hear about it before the client’s customers do.