SPF, DKIM, and DMARC Explained for Cold Email

If your cold email lands in spam, the first thing to check is authentication. SPF, DKIM, and DMARC are three DNS records that tell receiving servers your mail is really from you and not a spoofer. Get them wrong and even a perfect email gets filtered.

Here is what each one does and how to set it up.

SPF: which servers may send for your domain

SPF (Sender Policy Framework) is a single TXT record in your DNS. It lists the servers allowed to send email on behalf of your domain. When a receiving server gets your message, it checks the sending IP against that list.

A record looks like this:

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

The include pulls in Google’s sending servers (use this if you send from Gmail or Google Workspace). The ~all at the end means “soft fail everything else.” Keep these in mind:

• You can only have one SPF record per domain. Multiple records break it.
• SPF allows a maximum of 10 DNS lookups. Too many include statements and it fails.
• SPF alone checks the envelope sender, not the visible From address, which is why you also need DKIM and DMARC.

DKIM: a cryptographic signature

DKIM (DomainKeys Identified Mail) signs each message with a private key. Your DNS holds the matching public key as a TXT record. The receiving server uses the public key to verify the signature, which proves two things: the mail came from your domain, and it was not altered in transit.

Setup depends on your provider. In Google Workspace you generate a DKIM key in the admin console, then publish the given TXT record at a selector like google._domainkey.yourdomain.com. Use a 2048-bit key where offered. Once DNS propagates, turn on signing.

DKIM is the strongest of the three because it survives forwarding and does not depend on the sending IP.

DMARC: a policy that ties it together

DMARC (Domain-based Message Authentication, Reporting and Conformance) builds on SPF and DKIM. It tells receivers what to do when a message fails authentication, and it requires alignment: the domain in the visible From must match the domain that passed SPF or DKIM.

A starter record:

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

The p=none policy means “monitor only, take no action.” The rua address receives daily aggregate reports showing who is sending as you. Start with p=none, read the reports for a week or two, confirm your legitimate mail passes, then tighten:

1. p=none to observe.
2. p=quarantine to send failures to spam.
3. p=reject to block failures outright.

Moving to p=reject too fast can bounce your own mail if SPF or DKIM is not aligned yet. Verify first.

How this affects deliverability

Major providers now expect all three. Google and Yahoo require SPF, DKIM, and a DMARC record for bulk senders, and cold outreach that fails these checks gets filtered or bounced. Authentication does not guarantee the inbox, but its absence nearly guarantees spam.

Authentication is table stakes, not the whole game. Content, volume, and reputation still decide the rest. For the full picture see our cold email deliverability guide, and if you are already landing in spam, work through why cold emails go to spam.

Keep it healthy

DNS records drift. A provider change, a new sending tool, or a typo can break alignment overnight, and you often do not notice until replies stop.

PitchButler runs SPF, DKIM, and DMARC checks every day and pauses sending if something breaks, so a silent DNS failure never quietly torches your reputation. That is the same protect-the-sender thinking behind our warm-up ramp and the safeguards described on our security page.

Set the three records once, verify with your DMARC reports, and monitor them. It is the cheapest deliverability work you will ever do.