SPF, DKIM and DMARC: The 20-Minute Setup That Decides Your Cold Email

There is a version of this article that opens with a paragraph about the importance of email authentication in the modern threat landscape. This is not that article.

Here is the situation: three DNS records stand between your cold email and the spam folder. They are not difficult, they are not expensive, and they take about twenty minutes to configure. Yet a startling number of businesses running outbound have one of them wrong, or missing, and cannot understand why their carefully written emails vanish into the void.

Let us fix that.

The one-sentence version of each

Before the detail, the mental model. Each record answers a different question that a receiving mail server asks about your message:

Notice that these are three different proofs, not three versions of the same one. That is why you need all of them.

SPF: the guest list

Sender Policy Framework is a DNS record listing every server permitted to send email on behalf of your domain. When a receiving server gets mail claiming to be from you, it looks up your SPF record and checks whether the sending server is on that list.

It looks like this:

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

Reading it left to right: this is an SPF record; servers authorised by Google and by SendGrid may send for us; anything else should be treated with suspicion.

The three mistakes that break SPF

Two SPF records. The specification allows exactly one per domain. If you add a second when you connect a new sending service, you do not get both, you get a permanent error that fails both. Merge them into a single record with multiple include: statements.

Too many lookups. SPF permits a maximum of ten DNS lookups when evaluating a record. Each include: costs at least one, and some includes contain further includes. Exceed ten and the whole record fails. If you have accumulated services over the years, audit the record.

Ending with +all. This says "anyone may send for us", which defeats the entire purpose. Use ~all (softfail) while you are setting things up and -all (hardfail) once you are confident.

DKIM: the wax seal

DomainKeys Identified Mail attaches a cryptographic signature to every outgoing message. The private key lives with your sending provider; the matching public key is published in your DNS. A receiving server verifies the signature against the published key and learns two things at once: the message genuinely came from your domain, and nobody altered it in transit.

You do not compose a DKIM record by hand. Your mailbox or sending provider generates the key pair and gives you a hostname and a value to publish, usually something like selector._domainkey.yourdomain.com. You paste it into DNS. That is the whole job.

Two things worth knowing:

• Rotate keys occasionally. Most providers handle this automatically. If yours does not, an annual rotation is sensible hygiene.
• Every sending service needs its own key. If you send from a mailbox provider and a separate marketing platform, both publish a DKIM record, each under a different selector. They coexist happily, unlike SPF.

DMARC: the policy that makes it all count

Here is the part that is easy to miss. SPF and DKIM are just checks. On their own, they tell a receiving server whether something passed or failed, but not what to do about it. That decision is left to each provider, and providers are conservative with mail from domains that have not told them anything.

DMARC is where you tell them. A minimal record looks like this:

v=DMARC1; p=none; rua=mailto:reports@yourdomain.com

The p= value is the policy, and it has three settings:

Since 2024, Gmail and Yahoo have required a DMARC record from bulk senders. A domain without one is not merely unprotected, it is actively penalised.

Alignment: the trap almost everyone falls into

This is the concept that explains most "but I set everything up and it still failed" situations.

DMARC does not just ask whether SPF or DKIM passed. It asks whether the domain that passed matches the domain in the From address the recipient sees. That match is called alignment.

So a message can sail through SPF because the sending platform's own domain is properly authorised, and still fail DMARC, because the recipient sees you@yourcompany.com while SPF authenticated mail.someplatform.com. Two different domains, no alignment, DMARC failure.

The fix is to authenticate using a domain of your own, typically by pointing a subdomain such as mail.yourcompany.com at your sending provider and letting them sign with it. Every reputable provider documents how; the setting is usually called a custom sending domain or custom return path. It is a ten-minute job, and it is the difference between technically configured and actually working.

Your twenty-minute checklist

1. Inventory your senders. Mailbox provider, outreach platform, invoicing tool, helpdesk, newsletter service. Everything that sends as you.
2. Publish one SPF record including all of them, ending in ~all.
3. Enable DKIM with each provider and publish the key each one gives you.
4. Set up a custom sending domain with your outreach platform so DMARC alignment passes.
5. Publish DMARC at p=none with a reporting address.
6. Wait two weeks and read the reports. You will find something you forgot.
7. Move to p=quarantine, watch for a fortnight, then p=reject.

Then verify. Send a message to a mailbox at a major provider, open the original headers, and look for three lines saying spf=pass, dkim=pass and dmarc=pass. If any of them says anything else, you are not finished, whatever your DNS panel says.

Where this fits in the bigger picture

Authentication proves you are who you claim to be. It does not prove you are worth reading. Those are separate problems with separate solutions:

• Identity is DNS: the three records above.
• Reputation is warm-up and sending discipline, built over weeks.
• Relevance is targeting and copy, which no infrastructure will fix for you.

Get identity right first, because it is the only one of the three you can finish in an afternoon. A platform that audits your SPF, DKIM and DMARC records and tells you plainly which one is broken saves a great deal of squinting at DNS panels, and Leads Ranger runs that audit against every domain you connect.

But the records themselves are yours, they live in your DNS, and they belong to you no matter which tool you send with. That is worth twenty minutes of anyone's evening.