SPF, DKIM, and DMARC Explained for Cold Emailers

What each DNS record does, why all three are required for cold email, and how to verify they are configured correctly before your first send.

The Three Records That Determine Whether Your Emails Land

Three DNS records determine whether your cold email lands in the inbox or gets flagged as spam before your prospect ever sees it. SPF, DKIM, and DMARC are not optional for cold email. They are the foundation. Missing or misconfigured authentication records are the single most common cause of deliverability failures I see in cold email operations, and they are also the most fixable.

Here is what each record does, why it matters for cold email specifically, and how to verify your setup is correct before you send a single campaign email.

SPF: Authorizing Your Sending Servers

SPF (Sender Policy Framework) is a DNS TXT record that tells receiving mail servers which IP addresses are authorized to send email from your domain. Without SPF, any server can claim to send email from yourdomain.com. Receiving servers have no way to verify whether an email actually came from you or from someone else claiming to be you.

For Google Workspace, your SPF record looks like this: v=spf1 include:_spf.google.com ~all. For Microsoft Outlook 365: v=spf1 include:spf.protection.outlook.com ~all. The ~all at the end means soft fail for anything not in your authorized list. Using -all (hard fail) is stricter and signals to receiving servers that you are serious about authentication. For dedicated cold email sending domains, use -all once you have confirmed your SPF covers every legitimate sending source.

The most common SPF mistake is exceeding 10 DNS lookups. SPF has a strict limit of 10 DNS queries during a lookup. If your record requires more than 10 to resolve, authentication fails silently. This happens when you include multiple services that each include other records. Use an SPF flattening tool to consolidate your record into a single flat list of IPs if you hit this limit. Another common mistake: using +all, which means any server can send from your domain, completely defeating the purpose of SPF.

DKIM: Proving Your Email Was Not Tampered With

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every outgoing email. The receiving mail server uses a public key you publish in DNS to verify that the email actually came from your domain and was not modified in transit. If someone intercepts and alters your message, the signature fails and the receiving server knows the email is not authentic.

To set up DKIM, you enable it in your email provider's admin console. Google Workspace and Microsoft 365 both generate a DKIM public key that you copy into a DNS TXT record on your sending domain. The record looks something like: google._domainkey.yourdomain.com IN TXT "v=DKIM1; k=rsa; p=MIIBIjAN...".

DKIM requires two steps: enabling it in your provider's admin panel AND adding the DNS record. One without the other does not work. After making changes, allow 24 to 48 hours for DNS propagation before testing. Use the free DNS checker to confirm the DKIM record is publishing correctly and the signature is valid.

DMARC: The Policy Layer

DMARC (Domain-based Message Authentication, Reporting and Conformance) sits on top of SPF and DKIM. It tells receiving servers what to do when an email fails authentication: let it through anyway (none), move it to spam (quarantine), or reject it entirely (reject). It also requires alignment, meaning the domain that passes SPF or DKIM must match the domain in the From: header of the email.

Alignment is why DMARC matters beyond just authentication. Without DMARC, a sophisticated attacker can pass SPF on a different domain while spoofing your From: address. DMARC closes that gap by requiring that the authenticated domain matches what the recipient actually sees as the sender.

A solid starting DMARC record for cold email domains: v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com. The p=quarantine policy means emails that fail authentication go to spam rather than being delivered normally. The rua address receives aggregate reports showing authentication results across all emails sent from your domain. These reports help you catch configuration problems early, before they affect live campaigns.

Move to p=reject once you have confirmed that your legitimate sending sources all pass authentication cleanly. Reject is the strongest signal to receiving servers that you run a clean operation. Just confirm everything works in quarantine mode first.

Why All Three Are Required

Some cold emailers think SPF alone is enough. It is not. Here is how the three records work together and why each one is necessary:

SPF alone can be bypassed by attackers who use your domain in the envelope sender but a different domain in the From: header. Without DMARC alignment checking, SPF does not protect what the recipient actually sees.
DKIM alone can fail if email is forwarded or modified by mailing list software. It also does not tell receiving servers what to do with failed messages.
DMARC alone cannot function without SPF or DKIM, because DMARC checks alignment against authentication results from one of those two mechanisms.

Together, SPF authenticates your sending IP, DKIM authenticates the message content and sender identity, and DMARC defines the policy and enforces alignment. Missing any one of the three leaves a gap that receiving servers notice, and that gap shows up in your inbox placement numbers.

How to Check Your DNS Setup

The free DNS checker runs SPF, DKIM, and DMARC checks on any sending domain in under 30 seconds. Use it on every domain before your first campaign. If any check fails, fix it before sending a single email.

For a more detailed breakdown, MXToolbox runs individual checks on each record type and shows the raw record contents alongside a clear pass or fail result. Their Email Header Analyzer lets you paste an email header and see exactly which authentication checks passed and which failed for a specific sent message.

GlockApps is the most thorough tool for cold email specifically. It sends test emails from your accounts to seed addresses across 70 or more email providers and shows where each message landed: inbox, spam, promotions, or not delivered. Run a GlockApps test before every new domain goes into production. A clean DNS setup should show 85 percent or better inbox placement on GlockApps before you start any campaign.

Set DNS Before Warmup

The order matters more than most people realize. Set up SPF, DKIM, and DMARC before you start warming a domain. Warmup builds sending reputation on the emails you send during that period. If your authentication is broken during warmup, you are building reputation on unauthenticated mail. The reputation does not transfer cleanly when you fix the records later. You waste the warmup period and may need to start over from scratch.

The correct order: register the domain, configure DNS records (SPF, DKIM, DMARC, MX), verify all records are passing with the DNS checker, then start warmup. Puzzle Inbox handles this automatically for every inbox they provision. Google Workspace and Outlook 365 accounts arrive with DNS fully configured and verified, which removes this entire failure mode from your setup.

Bottom line: SPF authorizes your sending servers. DKIM signs your messages cryptographically. DMARC enforces alignment and defines what happens when authentication fails. All three are required for cold email to land in the inbox consistently. Check your records with the free DNS checker before every new domain goes live, and always configure DNS before warmup, not after. Broken authentication is the most common and most fixable deliverability problem in cold email.

Ready to start sending?

Puzzle Inbox provisions pre-warmed Google Workspace and Outlook 365 cold email inboxes ready to send within 24-72 hours. See the pricing page, the how-it-works walkthrough, or the our-process page for full details. Comparisons follow our editorial methodology.