How SPF, DKIM and DMARC actually work

Three records that together let a receiver tell your mail from someone pretending to be you. They only work as a set.

Email was designed with no way to verify who sent a message. Anyone can put your domain in the From line. These three records are the retrofit, and each does a different job.

SPF — which servers may send

A TXT record listing the servers authorised to send mail for your domain. A receiver checks whether the connecting server is on the list.

The ten-lookup limit is what breaks it. RFC 7208 allows an SPF evaluation ten DNS lookups. Each include costs one — and each include's own includes cost more, so a record with four providers can easily be over the limit without looking it.

Past ten, receivers stop evaluating and return a permanent error. The record fails rather than partially working, which is why this breaks suddenly when a fifth provider is added rather than degrading gently.

Two SPF records is also a hard failure. Receivers do not merge them; they return an error and SPF fails for the domain. If a provider asks you to add a second, merge the includes into the existing one instead.

DKIM — proof the message was not altered

Your mail server signs each message with a private key. The public key is published in DNS at <selector>._domainkey.<domain>, and the receiver verifies the signature.

Unlike SPF, DKIM survives forwarding — the signature travels with the message. That matters, because forwarding is what breaks SPF constantly.

Selectors cannot be listed from DNS. You have to know yours, and it is in the s= field of the DKIM-Signature header of any mail your domain has sent. Any tool claiming to check DKIM without a selector is guessing at common names.

DMARC — what to do when they fail, and who to tell

A record at _dmarc.yourdomain that ties the other two together. It tells receivers what to do with mail that fails, and where to send reports.

Alignment is the part people miss. DMARC does not just require SPF or DKIM to pass — it requires the domain that passed to match the one in the From header. A message can pass SPF for a mailing list's domain and still fail DMARC for yours.

The order to roll them out in

1. Publish SPF with ~all, listing everything that sends for you. Take the time to find them all — the marketing platform, the ticketing system, the invoicing tool nobody mentioned.
2. Set up DKIM with each provider.
3. Publish DMARC with p=none and an rua address. This blocks nothing. It makes receivers send you reports about mail claiming to be from you.
4. Read the reports for a few weeks. This is where you find the senders you forgot. Enforcing before this step is how a company discovers its invoices stopped arriving.
5. Move to p=quarantine, then to p=reject.

Frequently asked questions

What is the SPF ten-lookup limit?

RFC 7208 allows ten DNS lookups per evaluation. Each include costs one, and nested includes cost more. Past ten, receivers return a permanent error and the record fails entirely rather than partially working.

Can I have two SPF records?

No. Receivers return an error rather than merging them, and SPF fails for the domain. Merge the includes into one record.

Why do I need a DKIM selector to check DKIM?

DNS gives no way to enumerate selectors. Yours is in the s= field of the DKIM-Signature header of mail your domain has sent.

Does p=none protect anything?

No. Receivers report what they saw and deliver either way. Its value is the reports, which show you which of your own senders would break before you enforce.

Why does my mail fail DMARC when SPF passes?

Alignment. DMARC requires the domain that passed SPF or DKIM to match the From header domain. Forwarding and mailing lists commonly break that for SPF, which is why DKIM matters.