SPF, DKIM and DMARC in plain English

SPF, DKIM and DMARC are three DNS records that together prove an email genuinely comes from the domain shown in its from-address. SPF publishes a list of servers allowed to send on the domain's behalf, DKIM attaches a cryptographic signature to every message, and DMARC tells receiving servers what to do when either check fails. Without all three configured, cold email in 2026 mostly goes to spam or gets rejected before a human ever sees it.

What problem are these records solving?

Email's original design lets anyone put anything in the from field. A spammer in a rented data centre can send mail claiming to be from your bank, your accountant, or you. Receiving servers therefore cannot take a from-address on faith; they need independent proof that the sender is who they claim to be.

That proof is authentication, and it is the entry ticket to the inbox — one of a handful of inputs filters weigh alongside domain reputation, volume behaviour, engagement and list quality. The full picture is in the practical guide to cold email deliverability; this article covers the identity layer only. Google and Microsoft have both tightened their sender rules in recent years, and for any sender doing volume the three records have moved from best practice to effectively mandatory.

What does SPF actually do?

SPF — Sender Policy Framework — is a single TXT record in your domain's DNS that lists the servers permitted to send email for that domain. When a receiving server accepts a connection, then it checks the IP address that delivered the message against the list in your SPF record. If the IP is on the list, SPF passes. If it is not, SPF fails, and the receiver treats the message with suspicion or discards it, depending on how strict your record says to be.

Two practical notes. A domain may have only one SPF record — a second one breaks both. And SPF checks the hidden return-path address rather than the visible from-address, which is a gap DMARC exists to close.

What does DKIM actually do?

DKIM — DomainKeys Identified Mail — is a tamper-evident signature. Your sending server holds a private key and signs selected headers and the body of every outgoing message. The matching public key is published in your DNS. When a receiver gets the message, then it fetches that public key and verifies the signature. If anything was altered in transit — a link swapped, a paragraph injected — the signature no longer matches and DKIM fails.

Where SPF answers "did this come from an approved server?", DKIM answers "is this the message that server actually sent, signed by the domain that claims it?". DKIM also survives forwarding, which SPF often does not.

What does DMARC actually do?

DMARC — Domain-based Message Authentication, Reporting and Conformance — is the policy layer on top. It does two things. First, it requires alignment: the domain in the visible from-address must match the domain that passed SPF or DKIM, closing the gap where a spammer passes SPF on their own domain while displaying yours. Second, it tells receivers what to do on failure: p=none (deliver but report), p=quarantine (send to spam), or p=reject (refuse outright).

DMARC also sends you aggregate reports on who is sending as your domain — the only routine visibility you get into spoofing attempts. The sensible path is to start at none, read the reports for a few weeks, then move to quarantine or reject once legitimate senders all pass.

How do the three work together when an email arrives?

The receiving server runs the checks in sequence, in seconds:

1. The connection opens. The receiver notes the IP address delivering the message.
2. SPF check. It looks up the sending domain's SPF record; when the delivering IP is on the list, then SPF passes.
3. DKIM check. It fetches the public key from DNS and verifies the signature; when the message is unaltered, then DKIM passes.
4. DMARC check. It confirms at least one passing check aligns with the visible from-domain, and reads your published policy.
5. Verdict. When both identity and alignment hold, then the message proceeds to reputation and content scoring. When they fail, then your own DMARC policy decides its fate — often before any filter looks at the copy.

Does passing all three get you to the inbox?

No. Authentication is necessary, not sufficient. It is a passport, not a character reference: it proves who you are, while reputation records how you have behaved. Perfectly authenticated mail sent to a decaying list still bounces, still hits spam traps, and still buries the domain — the pruning discipline in list hygiene matters just as much.

Note also that these records are set per domain. Cold outbound should run on secondary domains, and each one needs its own SPF, DKIM and DMARC before warm-up begins — a fifteen-minute job per domain that a surprising number of paid campaigns skip. No tool automates its way around this layer, which is the same reason AI on its own won't fill your pipeline: the clever part only works when the unglamorous part is built.

---

Next step: the Growth System Audit — £450, seven days, credited against any build — maps where your growth system leaks and what to build first.