SPF, DKIM, and DMARC: The Cold Email Sender's Practical Setup Guide for 2026
By Lara Meunier, Compliance Researcher · Oct 4, 2026 · 10 min read · Last reviewed Oct 4, 2026
If your cold emails land in spam and you can't figure out why, the answer is almost always in your DNS records. Here's how SPF, DKIM, and DMARC actually work and how to set them up correctly.
10 min read | Updated October 2026
If you've ever had a cold email campaign that just stopped working, and you couldn't figure out why, your DNS records are the first place to look. SPF, DKIM, and DMARC are not optional configurations for cold email. They're the authentication layer that tells Gmail and Outlook whether to trust your emails at all. Get any one of them wrong and you're sending into a black hole, regardless of how good your copy is.
This is the practical setup guide. Not the academic explanation. Here's what each record does, where people screw it up, and how to verify your setup before you send a single email.
What SPF Actually Does
SPF stands for Sender Policy Framework. It's a DNS record on your sending domain that specifies which mail servers are authorized to send email on behalf of that domain. When Gmail receives an email from your domain, it checks your SPF record to see whether the server that sent it is on your approved list. If it's not, Gmail treats the message as suspicious.
For cold email, the most common SPF mistake is having no record at all, having a broken syntax, or having multiple SPF records on the same domain. You can only have one SPF record. If you have two, both get ignored.
A correct SPF record for a Google Workspace account looks like this:
v=spf1 include:_spf.google.com ~all
For Microsoft 365, it's:
v=spf1 include:spf.protection.outlook.com -all
The ~all at the end means "softfail" - emails from unlisted servers get a warning but still deliver. The -all means "hardfail" - emails from unlisted servers get rejected. For cold email, softfail is safer when you're first getting started because a hardfail will reject your own legitimate emails if you miss an authorized server.
If you're using a sending platform like Smartlead or Instantly on top of Google Workspace, you don't need to add the platform to your SPF record because the email is still being sent through Google's servers via OAuth. The SPF record covers Google, and Google covers the rest.
What DKIM Actually Does
DKIM stands for DomainKeys Identified Mail. It adds a cryptographic signature to every email you send. The private key lives on the sending server (Google Workspace handles this automatically). The public key lives in your DNS records. When Gmail or Outlook receives your email, they look up your public key and verify the signature. If the signature matches, the email is confirmed as actually coming from your domain and unchanged in transit.
Google Workspace generates your DKIM key automatically, but you have to publish it in your DNS and activate it in the Admin Console. This is where most people slip up. The key gets generated but never actually turned on, and the emails go out unsigned.
To set up DKIM in Google Workspace:
- Go to Admin Console, then Apps, then Google Workspace, then Gmail
- Click "Authenticate email" and then "Generate new record"
- Copy the TXT record and add it to your domain's DNS
- Wait 24 to 48 hours for DNS propagation
- Come back and click "Start authentication"
For Microsoft 365, the DKIM setup lives in the Defender portal under Email Authentication Settings. Microsoft now generates DKIM keys automatically for most new domains, but you still need to verify that signing is enabled and that the CNAME records are live in your DNS.
The DKIM Selector Problem
Each DKIM key has a "selector" prefix in the DNS record name. Google's default selector is "google." If you're using multiple sending services, each one needs its own DKIM key with its own selector. This is a common issue when teams use both Google Workspace and a supplemental SMTP provider. Two different DKIM keys on the same domain don't conflict, they just need different selectors in the record name.
What DMARC Actually Does
DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It's the enforcement layer that tells recipient mail servers what to do when an email fails SPF and DKIM checks. It also sends you reports about who's sending email using your domain, which is useful for catching misconfigured sending tools and spoofing attempts.
A basic DMARC record looks like this:
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com
The p=none policy means "do nothing, just report." This is where you should start. A p=quarantine policy sends failing emails to spam. A p=reject policy refuses them entirely. Start with none, monitor the reports for 2 to 4 weeks to understand what's sending from your domain, and only tighten the policy after you're confident your legitimate email sources all pass authentication.
DMARC requires at least one of SPF or DKIM to "align" with your From domain. Alignment means the domain in the From header matches the domain used for the SPF check (the envelope sender) or the DKIM signature domain. Google Workspace and Microsoft 365 both handle alignment automatically when configured correctly. The alignment problem shows up when teams use custom SMTP providers that send email from a different envelope domain than the From address.
The Three Mistakes That Kill Cold Email Deliverability
Mistake 1: Missing or Broken SPF
Run a DNS lookup on your sending domain right now. The command is: dig TXT yourdomain.com or use the free DNS checker. You should see exactly one record starting with "v=spf1". If you see two, you have a conflict. If you see none, your emails have no authentication at all.
Mistake 2: DKIM Generated but Not Activated
A DKIM key sitting in your DNS but not activated in Google Workspace Admin Console does nothing. It's like having a lock without putting it on the door. Check that signing is actually turned on for your domain, not just that the DNS record exists.
Mistake 3: Jumping Straight to Reject Policy
DMARC with p=reject before you've audited every service that sends email from your domain will break legitimate email. Most organizations have more email sources than they realize: the CRM sends transactional emails, the billing system sends invoices, the newsletter tool sends updates. All of these need to pass DMARC or they get rejected. Start at p=none, read the reports, and move to quarantine then reject over 30 to 60 days as you confirm all sources are authenticated.
Subdomain vs Root Domain for Cold Email
Most cold email practitioners send from subdomains rather than their root domain. Instead of sending from @company.com, they send from @mail.company.com or @outreach.company.com. There are two reasons for this.
First, if a cold email campaign goes wrong and a domain ends up on a blocklist, you want it to be the subdomain, not the root domain. The root domain staying clean protects your main business email. Second, keeping sending reputation isolated to the subdomain means your main domain's deliverability isn't affected by the reputation built or burned through cold outreach.
Each subdomain needs its own complete DNS authentication: its own SPF record, its own DKIM key activated in the sending platform, and its own DMARC record or a DMARC policy inherited from the root domain. Verify each subdomain separately. A DMARC policy on the root domain does apply to subdomains by default unless you explicitly override it per subdomain.
How to Verify Your Setup Before You Send
Check your DNS records with the free DNS checker. It runs SPF, DKIM, and DMARC validation in one place and shows you exactly what's missing or misconfigured. For a deeper check, use GlockApps to send a test email through your actual setup and see the authentication headers. GlockApps shows you whether DMARC passes, which policy was applied, and whether SPF and DKIM alignment is working.
The minimum acceptable standard before any cold email sequence starts:
- SPF record present with correct include statement for your inbox provider
- DKIM signing enabled and verified in your sending platform
- DMARC record present at minimum p=none with a reporting email address
- All three records propagated (wait 24 to 48 hours after making changes)
Once your DNS is clean, confirm your inbox placement with a GlockApps or EmailGuard test before the campaign goes live. Authentication passing doesn't guarantee inbox placement. It removes the authentication failure reason for landing in spam. There are other factors: domain age, sending history, content, and link reputation.
Ongoing Maintenance
DNS records don't expire but situations change. Every time you add a new sending tool, change inbox providers, or set up a new subdomain for an outreach campaign, redo the authentication check. An infrastructure change that breaks DKIM or adds a second SPF record will tank deliverability silently. You won't see bounce rates spike because emails aren't bouncing, they're just landing in spam without a single bounce or error.
Check DMARC reports monthly. They show you whether any unexpected sources are sending from your domain and whether authentication is working correctly across all your sending infrastructure. Most DMARC reporting tools parse the raw XML reports into readable summaries. EasyDMARC and Dmarcian both have free tiers that cover the basic reporting use case for small cold email operations.
Related Articles
- Best Cold Email Infrastructure Providers in 2026 — Honest Comparison
- Why Your Cold Emails Land in Spam (And How to Fix It)
- SMTP vs Google Workspace for Cold Email — Why Infrastructure Type Matters
- How to Set Up SPF, DKIM, and DMARC for Cold Email in 2026
Related Tool Reviews
- ColdSire — Cold email infrastructure service
- Email Astra — Pre-warmed Google Workspace accounts
- Emailchaser — Bundled inbox infrastructure and lead data platform
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.