SPF, DKIM and DMARC for Cold Email, Explained Without the Jargon

Email was designed in an era when nobody expected people to lie about who they were. Anyone can send a message claiming to be from any address, and the protocol itself does nothing to stop them.

SPF, DKIM and DMARC are the three patches bolted on afterwards to fix that. They are DNS records. They answer three questions a receiving server asks about your mail.

Since 2024, Google and Microsoft have required all three from bulk senders. Without them your mail is not merely less likely to arrive, it is likely to be rejected outright.

Here is what each one is, in order.

SPF: which servers may send as you

The question it answers: is this server allowed to send email claiming to be from this domain?

SPF is a list, published in your DNS, of the servers permitted to send on your behalf. A receiving server looks up that list and checks whether the mail came from one of them.

It is a single TXT record on your root domain:

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

Reading that:

• v=spf1 says this is an SPF record.
• include:_spf.google.com says Google Workspace is permitted to send for this domain. Your provider tells you what to put here. Microsoft 365 uses include:spf.protection.outlook.com.
• ~all means anything else is a soft fail: treat it as suspicious but do not necessarily reject it.

The mistakes

Two SPF records. This is the most common failure by a wide margin. SPF permits exactly one record per domain. If you add a second when you add a new sending tool, SPF does not become more permissive, it breaks entirely and everything fails.

To add a sender, put another include: inside the record you already have:

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

More than ten lookups. Each include: costs a DNS lookup, and the limit is ten. Exceed it and the record returns a permanent error, which counts as a failure. If you have accumulated many tools, audit the record and remove the ones you no longer use.

Using -all too early. -all is a hard fail, meaning reject anything not on the list. It is stricter and better, but only once you are completely certain every legitimate sender is included. Start with ~all and tighten later.

DKIM: proof the message was not altered

The question it answers: did this message genuinely come from this domain, and has it been changed in transit?

DKIM adds a cryptographic signature to every outgoing message. Your provider signs with a private key. The matching public key lives in your DNS. The receiving server fetches the public key, checks the signature, and now knows both that you sent it and that nobody edited it on the way.

You do not write this record yourself. Your email provider generates it and gives you a value to paste. It looks like:

Host:  google._domainkey
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhki... (a long key)

The google._domainkey part is the selector. Different providers use different selectors, which is what allows several signing services to coexist without conflicting. Unlike SPF, multiple DKIM records are fine.

The mistakes

Generating the key but never enabling signing. In Google Workspace these are two separate actions. You generate the key, add the DNS record, and then have to go back and click "Start authentication". People routinely skip the second step and cannot work out why DKIM fails.

Truncating the key. Keys are long. Some DNS interfaces split them across multiple strings and some do not. Paste the whole value and check it afterwards.

Waiting for propagation and giving up. DNS changes can take up to 48 hours. Usually it is minutes. Do not conclude it is broken after ten.

DMARC: what to do when the first two fail

The question it answers: if SPF and DKIM do not pass, what should the receiving server do about it, and where do I want to be told?

DMARC is the policy layer. It also enforces alignment: it requires that the domain in the visible From address matches the domain that passed SPF or DKIM. This is what closes the loophole where someone passes SPF for their own domain while displaying yours in the From field.

A starting record:

Host:  _dmarc
Value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; pct=100; adkim=r; aspf=r

Reading it:

• p=none is monitor mode. Report, but do not act. Always start here.
• rua= is where aggregate reports are sent. Use a real inbox you will actually read.
• pct=100 applies the policy to all mail.
• adkim=r and aspf=r set relaxed alignment, which allows subdomains to align with the root domain. Almost always what you want.

The three policy levels

Move through them in order, over weeks, not in one afternoon. Run p=none and read the reports until you are confident every legitimate sender passes. Only then move to quarantine, then reject.

Jumping straight to p=reject before you know your full sending landscape is how a company discovers that its invoicing system, its helpdesk and its newsletter were all sending as the domain and are now being refused by everyone.

The aggregate reports arrive as XML and are unreadable by eye. Use a free DMARC report parser to turn them into something you can look at.

Testing all three

Do not assume. Confirm.

1. mail-tester.com. Send a real email to the address it gives you and it scores your setup, showing SPF, DKIM and DMARC status individually. Fastest complete check available.

2. Check the headers directly. Send yourself an email, open the original message, and look for:

Authentication-Results:
  spf=pass
  dkim=pass
  dmarc=pass

Three passes. Anything else is a problem to solve before you send anything cold.

3. Test from the actual sending tool. Passing from your normal mailbox does not prove your cold email platform passes. It uses a different path. Send a test through the tool itself.

The order to do it in

1. Buy the sending domain and put a real page on it.
2. Set up the mailboxes with your provider.
3. Add SPF. One record, correct includes.
4. Enable DKIM and add the key. Then confirm signing is actually switched on.
5. Add DMARC at p=none with a reporting address.
6. Test with mail-tester and confirm three passes.
7. Start warm-up. Weeks, not days.
8. Read DMARC reports for a few weeks, then tighten to p=quarantine.

Only after all of that does the first real prospect get an email.

What this does and does not buy you

Authentication gets your mail eligible for the inbox. It does not get it into the inbox.

Passing all three means you are allowed through the front door. What happens next is decided by your sending reputation, your volume pattern, your bounce rate, complaint rate, and whether people engage with what you send. A perfectly authenticated domain sending a badly targeted email to a stale list will still land in spam, and it will deserve to.

Authentication is the floor, not the ceiling. The rest of the floor is in the deliverability checklist.