Email authentication: SPF and DKIM explained

Email authentication is three DNS records that let a receiving server check that mail claiming to come from your domain actually did. SPF and DKIM do the checking; DMARC decides what happens when they fail. This guide covers the first two, which are where most misconfiguration lives.

None of it improves your deliverability on its own. It is a prerequisite: passing gets you considered, failing gets you filtered before anything else about the message is weighed.

SPF: which servers may send for you

A TXT record on your domain listing the servers permitted to send mail on its behalf. A receiver takes the envelope sender — the Return-Path, which your recipient never sees — looks up that domain’s SPF record, and checks whether the connecting server is on the list.

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

The tail matters. ~all is a soft fail, meaning “treat anything else as suspicious”; -all is a hard fail, meaning “reject it”. Start soft and tighten once the reports are clean.

The ten-lookup limit

This is the single most common way SPF breaks, and it breaks silently. An SPF record may trigger at most ten DNS lookups when evaluated. Every include: costs at least one, and each included record may chain further includes of its own.

Adding one more SaaS tool to a record that already sits at nine is enough to exceed it. The result is a permanent error, which under DMARC counts as an SPF failure — so mail that authenticated fine yesterday starts failing today, with nothing in your own systems reporting a change. If you use several senders, check the lookup count rather than assuming.

Forwarding breaks SPF

When a recipient auto-forwards your message, the forwarding server becomes the sender. It is not on your SPF record, so SPF fails — correctly, by its own logic. Nothing is wrong with your configuration; the mechanism simply does not survive forwarding. This is precisely why DMARC accepts either SPF or DKIM rather than requiring both.

DKIM: a signature on the message

DKIM signs outgoing mail with a private key and publishes the matching public key in DNS. A receiver fetches the key and verifies the signature, which proves the message was authorised by whoever controls the domain and has not been altered in transit.

The record lives at <selector>._domainkey.yourdomain.com. The selector is the part people get wrong: your sending tool signs with a specific selector, and if the key published under that name is missing or stale, verification fails. Confirm the selector your tool actually uses matches the one in DNS — not a selector from a previous provider.

Two practical notes. Use a 2048-bit key where the provider offers a choice; 1024 is still accepted but is the weaker option. And DKIM survives forwarding as long as the message body is not modified, which makes it the more robust of the two mechanisms and the one to get right if you only get one right.

Why the visible From address is not checked

Worth stating plainly, because it surprises people: neither SPF nor DKIM validates the address your recipient sees. SPF checks the envelope sender. DKIM checks whatever domain the signature declares in its own d= tag. A message can pass both while displaying any From address at all.

Closing that gap is the entire job of DMARC, which requires one of the two to both pass and align with the visible domain. SPF and DKIM without DMARC leave the spoofing problem unsolved — the DMARC guide covers alignment and how to roll out a policy without losing your own mail.

Checking your setup

Send a message to a mailbox you control at a major provider and inspect the headers. In Gmail, “Show original” reports SPF, DKIM and DMARC results in plain language.
Read DMARC aggregate reports. Publishing rua= gets you XML from receivers listing every source sending as your domain and whether it passed. It is the only view that covers senders you have forgotten about.
Count your SPF lookups whenever you add a sending tool.
Re-check after any migration. Changing email host, CRM or sending tool is when selectors and includes go stale.

Authentication is a one-afternoon job that then needs checking twice a year and after every change to who sends on your behalf. It is the cheapest deliverability work there is, and the only kind where the answer is unambiguous: the records either validate or they do not.