SPF, DKIM and DMARC in plain English

Three DNS records decide whether mailbox providers trust your email. Here is what SPF, DKIM and DMARC each do, and how to set them up for cold email.

Anyone can type any address into the From line of an email. Email authentication is how the receiving mailbox checks that a message really came from the domain it claims, and wasn't changed on the way.

Three DNS records do that job: SPF, DKIM and DMARC. Mailbox providers expect all three from anyone sending at volume. Email without them is treated as suspect from the first message, no matter how good it is.

SPF: who is allowed to send

SPF (Sender Policy Framework) is a guest list. It's a DNS record on your domain that lists the servers allowed to send email for it. When an email arrives, the receiving server checks whether the server that sent it is on the list.

A domain can have only one SPF record. If you send through more than one service, they all go in the same record.

DKIM: a signature that proves the email wasn't changed

DKIM (DomainKeys Identified Mail) is a wax seal. Your sending service signs every email with a private key, and you publish the matching public key in DNS. The receiving server uses the public key to check the signature. If the email was altered on the way, or didn't come from you, the check fails.

DKIM records live under a selector, a short name that lets one domain hold several keys, one per sending service.

DMARC: what to do when the checks fail

DMARC (Domain-based Message Authentication, Reporting and Conformance) ties the other two together. It tells receiving servers what to do with email that fails SPF and DKIM, and where to send reports about it.

It also checks alignment: the domain in the From line has to match the domain that passed SPF or DKIM. That's what stops someone from passing the checks on their own domain while showing yours.

A DMARC policy has three levels:

p=none: deliver as usual and send reports. For watching.
p=quarantine: send failing email to spam.
p=reject: refuse failing email outright.

All three, side by side

DNS records for an example sending domain

SPFThese servers may send email for this domain.
Host
getostervane.com
Value
v=spf1 include:_spf.example.net ~all
DKIMHere is the key to check our signature.
Host
s1._domainkey.getostervane.com
Value
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOC…
DMARCIf a check fails, do this, and send us a report.
Host
_dmarc.getostervane.com
Value
v=DMARC1; p=none; rua=mailto:dmarc@getostervane.com

A setup order that works

SPF first, listing every service that sends for the domain.
DKIM next, one key per sending service.
DMARC at p=none with a reporting address, so you can see who sends as your domain.
Move to p=quarantine once the reports show only your own services, usually after a few weeks.
Move to p=reject when you're confident nothing legitimate fails.

Common mistakes

Two SPF records. Only one is allowed. Merge them into one.
Too many lookups in SPF. SPF allows at most 10 DNS lookups. Every include counts.
A new service without DKIM. Every service that sends for you needs its own key.
Jumping straight to p=reject. Read the reports first, or you'll block your own email.
Setting up the wrong domain. Cold email should go out from separate sending domains, and each one needs its own records.

How Leadgenerator.io handles it

When you add a sending domain, Leadgenerator.io shows you the exact records to add, checks them, and creates the mailboxes on the domain as soon as it verifies. Then the mailboxes warm up before they carry real volume.