SPF, DKIM and DMARC: the three records that matter

SMTP, the protocol that carries essentially all email, was designed with no notion of identity. The From address a recipient sees is just a header the sending machine writes, and nothing in the protocol stops a machine from writing somebody else's domain there. That single design fact is why a message claiming to come from your business can be sent by a stranger from a rented server, and why the recipient has no way to tell by looking.

Authentication is the layer bolted on afterwards. Three DNS records let a receiving mail server ask the domain's owner, in effect, whether this message was really authorised. None of the three is optional in practice any more. Google's sender guidelines require authentication from senders of 5,000 or more messages a day to personal Gmail accounts, a rule that took effect in February 2024, and Yahoo introduced matching requirements on the same timeline. Below that volume the requirement is not formally binding, but the filtering that acts on it does not consult your send volume before deciding where to put your mail. The practical position is that unauthenticated bulk mail is treated as suspicious by default.

SPF is a single TXT record published at your domain, listing the servers permitted to send mail for it. It starts with v=spf1, names each sending source — usually by include: pointing at your mail provider's own record rather than by IP address — and ends with a catch-all instruction: -all to say anything else is a forgery, or ~all to say treat it as suspect.

Two details cause most SPF failures. First, you may publish only one SPF record per domain; two records is not additive, it is an error, and receivers may ignore both. Second, evaluating the record has a hard ceiling of ten DNS lookups, and each include: costs at least one. Add a fifth or sixth sending tool and the record silently exceeds the limit, returns a permanent error, and is treated as though you had no SPF at all — while still looking perfectly fine in your DNS panel.

The structural limit is what SPF checks: the envelope sender used during delivery, not the From address the recipient reads. A message can pass SPF for a domain the reader never sees, which is why SPF on its own does not stop a spoofed From line.

DKIM takes the opposite approach. The sending server holds a private key and uses it to sign selected headers and the message body; the matching public key is published in DNS at a name like selector._domainkey.yourdomain. The receiver fetches that key, recomputes the signature, and learns two things at once: that the domain authorised the message, and that the signed parts have not been altered in transit.

Because the proof rides inside the message rather than depending on which server made the connection, DKIM usually survives forwarding — the case where SPF reliably breaks. That is the single best argument for publishing both rather than picking one.

In practice each sending service gets its own selector, so your invoicing tool, your marketing platform and your helpdesk can each sign as your domain without sharing a key. Use a 2048-bit key where the provider offers a choice, and treat key rotation as routine rather than as an incident: a key that has been sitting in a provider's dashboard for years is a key nobody can confirm is still private.

DMARC is a TXT record at _dmarc.yourdomain carrying a policy — p=none, p=quarantine or p=reject — telling receivers what to do when checks fail, and an rua= address where they should send aggregate reports.

The policy is the visible part, but alignment is the mechanism that matters. DMARC passes only if SPF or DKIM passes and the domain that passed matches the domain in the visible From address. That requirement is what closes the gap the other two records leave open: a spammer can trivially pass SPF for a throwaway domain, but cannot make that domain align with yours.

The reports are the part most businesses never use and should. Aggregate reports arrive as XML from every major receiver and describe, source by source, which mail claimed to be from your domain and whether it authenticated. That is the only view you will get of who is sending as you — including the systems inside your own business that nobody remembered to authorise.

Deploy in sequence, because the last step is the one that can lose real mail. Publish SPF and DKIM first and confirm they pass on messages from every tool that sends as your domain. Then publish DMARC at p=none with an rua= address. At p=none nothing is blocked; you are only asking for reports.

Read those reports for several weeks before tightening anything. This is where the surprises live: an accounting package sending invoices, a booking system sending confirmations, a form on the website relaying through a host, a legacy address that forwards to somebody's personal mailbox. Every one of these is legitimate mail that would start failing under a strict policy, and none of it is written down anywhere.

Only once the report is boring — every source recognised and authenticated — move to p=quarantine, then to p=reject. Jumping straight to reject is the one genuinely dangerous move available here, and the mail it destroys is usually transactional mail somebody depended on.

Forwarding is the most common source of confusing failures. When a message is forwarded, the envelope sender is typically rewritten, so SPF fails at the final destination even though nothing is wrong — the DKIM signature is what carries the proof through. Mailing lists that modify the subject or append a footer can break DKIM too, which is why alignment on either mechanism is enough to satisfy DMARC.

The second recurring failure is growth. Every new sending tool adds an include: to the SPF record, and the ten-lookup ceiling arrives without warning. Adding a subdomain policy matters for the same reason: if you do not set sp=, a permissive parent policy can leave subdomains you never use available for spoofing.

When something does go wrong, the evidence is in the message headers. The Authentication-Results header on a delivered message states plainly which of SPF, DKIM and DMARC passed, which failed, and for which domain — and reading one real header teaches more than any diagram.