SPF, DKIM, DMARC: Cold Email Authentication Setup Guide

By Mitchell Keller, Founder & CEO, LeadGrow. Managed 3,626+ cold email campaigns. 6.74% average reply rate. 2,230+ meetings booked in 2025.

Email authentication is the price of admission

Before your cold email even gets evaluated on content, subject line, or relevance, it has to pass an authentication check. Gmail, Outlook, Yahoo, and every major email provider runs this check automatically on every inbound email.

The check is simple: Is this email actually from who it claims to be from?

Three DNS records answer that question: SPF, DKIM, and DMARC. If any of them are misconfigured or missing, your email looks suspicious. Suspicious emails go to spam. It doesn't matter how good your copy is.

We've managed 3,626+ cold email campaigns. When a client comes to us with deliverability problems, authentication is the first thing we check. About 40% of the time, the fix is a DNS record that's wrong or missing. That's it. Five minutes of work that transforms inbox placement. For the full picture on what affects inbox placement, see our cold email deliverability guide.

SPF: Who is allowed to send from your domain

SPF stands for Sender Policy Framework. It's a DNS record that lists every server authorized to send email on behalf of your domain. When a receiving server gets an email from your domain, it checks your SPF record to see if the sending server is on the list. If it's not, the email fails SPF authentication.

How SPF works

Think of SPF like a guest list at a venue. Your domain is the venue. The SPF record is the guest list. Email servers are the guests. If a server tries to send email from your domain and it's not on the SPF list, it gets turned away at the door.

Setting up SPF

SPF is a TXT record in your domain's DNS settings. Here's what it looks like for common email providers:

Google Workspace:

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

Microsoft 365:

v=spf1 include:spf.protection.outlook.com ~all

Google Workspace + a sending tool (like Instantly):

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

Breaking down the syntax:

• v=spf1 declares this is an SPF record (version 1)
• include: adds a provider's sending servers to your authorized list
• ~all means "soft fail" anything not on the list (recommended for cold email). -all is a "hard fail" which is stricter but can cause issues during warmup

Common SPF mistakes

Multiple SPF records. You can only have ONE SPF record per domain. If you add a second one, both break. When you need to authorize multiple providers, combine them into a single record with multiple include: statements.

Too many DNS lookups. SPF has a limit of 10 DNS lookups. Each include: counts as at least one lookup, and some providers chain lookups internally. If you exceed 10, SPF fails silently. Use an SPF flattening tool if you're hitting this limit.

Using +all instead of ~all or -all. The +all setting means "allow everyone to send from this domain." That defeats the entire purpose of SPF. Always use ~all (soft fail) or -all (hard fail).

DKIM: Proving the email wasn't tampered with

DKIM stands for DomainKeys Identified Mail. It adds a cryptographic signature to every email you send. The receiving server uses your public key (published in DNS) to verify that the email content hasn't been modified in transit and that it really came from your domain.

How DKIM works

When you send an email, your email server creates a unique hash of the email content and signs it with a private key. That signature gets attached to the email header. The receiving server looks up your public key in DNS and uses it to verify the signature. If the signature checks out, the email passes DKIM.

Think of it like a wax seal on a letter. The seal proves who sent it and that nobody opened and altered it along the way.

Setting up DKIM

DKIM setup depends on your email provider, but the process is similar across all of them:

Step 1: Go to your email provider's admin console (Google Workspace Admin, Microsoft 365 Admin, etc.)

Step 2: Find the DKIM settings (usually under Authentication or Email Security)

Step 3: Generate the DKIM key. The provider will give you a DNS record to add.

Step 4: Add the CNAME or TXT record to your domain's DNS

Step 5: Go back to the provider and activate DKIM signing

The DNS record looks something like this:

Record type: CNAME or TXT

Host/Name: google._domainkey (varies by provider)

Value: A long string of characters that is your public key

For Google Workspace specifically:

• Go to Admin Console > Apps > Google Workspace > Gmail > Authenticate Email
• Select your domain
• Click "Generate New Record"
• Choose 2048 bit key length (stronger than 1024)
• Copy the TXT record value
• Add it to your DNS as a TXT record with the host name provided
• Go back to Admin Console and click "Start Authentication"

Common DKIM mistakes

Forgetting to activate after adding DNS. Adding the DNS record is step one. You also have to go back to the email provider and turn DKIM signing on. We see this one constantly. The DNS record exists but DKIM is still disabled in the provider settings.

Wrong selector. The selector (like google._domainkey) has to match exactly what the provider expects. Extra characters, wrong prefix, or typos will break it.

Using a sending tool without adding its DKIM. If you use Instantly, Smartlead, or another cold email platform, they often have their own DKIM requirements. Check their documentation and add their DKIM record in addition to your email provider's.

DMARC: The policy that ties it all together

DMARC stands for Domain based Message Authentication, Reporting, and Conformance. It does two things: it tells receiving servers what to do when an email fails SPF or DKIM checks, and it sends you reports about authentication results so you can monitor your domain's health.

How DMARC works

DMARC builds on top of SPF and DKIM. It checks whether the "From" domain in the email aligns with the domains verified by SPF and DKIM. If both checks fail (or if neither passes alignment), DMARC tells the receiving server what to do: nothing, quarantine the email, or reject it outright.

Setting up DMARC

DMARC is a TXT record added to your DNS. Here's the recommended setup for cold email:

Starting DMARC record:

v=DMARC1; p=none; rua=mailto:[email protected]

After monitoring for 2 to 4 weeks:

v=DMARC1; p=quarantine; rua=mailto:[email protected]

Full enforcement (when everything is clean):

v=DMARC1; p=reject; rua=mailto:[email protected]

Breaking down the syntax:

• v=DMARC1 declares this is a DMARC record
• p=none means "monitor only, don't take action on failures" (start here)
• p=quarantine means "send failing emails to spam"
• p=reject means "reject failing emails entirely"
• rua=mailto: specifies where to send aggregate reports

DNS record details:

Record type: TXT

Host/Name: _dmarc

Value: Your DMARC policy string

Why start with p=none

When you first add DMARC, set the policy to none. This tells providers to send you reports about authentication results without actually blocking any emails. Monitor those reports for 2 to 4 weeks. If everything looks clean (your legitimate emails are passing SPF and DKIM), upgrade to quarantine. After another few weeks of clean reports, move to reject.

Going straight to reject on day one is risky. If you have any authentication misconfiguration, legitimate emails will get blocked and you won't know until someone tells you they never received your message.

Common DMARC mistakes

No DMARC record at all. Some teams set up SPF and DKIM but skip DMARC entirely. Starting in 2024, Gmail and Yahoo require DMARC for bulk senders. If you're sending cold email without DMARC, your deliverability is actively being penalized.

Using p=reject too early. If your SPF or DKIM has any issues you haven't caught yet, p=reject will silently kill your emails. Start with p=none, monitor, then escalate.

Not monitoring DMARC reports. The reports tell you exactly what's happening with your authentication. Use a free DMARC monitoring tool (DMARC Analyzer, Postmark's DMARC tool, or dmarcian) to parse the XML reports into readable dashboards. Check weekly.

The complete setup checklist

Here's the full authentication setup for a new cold email domain, step by step:

• Buy your domain (Porkbun, Namecheap, Spaceship)
• Set up email hosting (Google Workspace or Microsoft 365)
• Add SPF record to DNS. Include your email provider and any sending tools.
• Generate and add DKIM record. Don't forget to activate it in your provider's admin console.
• Add DMARC record with p=none to start monitoring.
• Verify all three records using MXToolbox or Google's Check MX tool.
• Start warmup. Authentication needs to be clean before you begin.
• Monitor DMARC reports for 2 to 4 weeks.
• Upgrade DMARC to p=quarantine once reports are clean.
• Begin cold sending after warmup period completes (21 to 28 days).

Total time: 15 to 30 minutes for the DNS work. Then 3 to 4 weeks of warmup before you send your first cold email.

Verification tools: how to check your setup

After configuring everything, verify. Don't assume it's correct because you followed the steps. DNS propagation can take up to 48 hours, and small typos break authentication silently.

Tool	What It Checks	Cost
MXToolbox (mxtoolbox.com)	SPF, DKIM, DMARC, blacklists, DNS health	Free
Google Check MX (toolbox.googleapps.com/apps/checkmx)	MX records, SPF, DKIM for Google Workspace domains	Free
Mail Tester (mail-tester.com)	Overall email score including authentication, content, blacklists	Free (3 checks/day)
DMARC Analyzer (dmarcanalyzer.com)	DMARC report parsing and monitoring	Free tier available
Learndmarc.com	Visual, step by step DMARC validation	Free

Run MXToolbox checks on every domain after setup. Then again after 24 hours (DNS propagation). Then weekly as part of your deliverability monitoring routine. We check authentication on all client domains every Monday morning. It takes 10 minutes and catches problems before they affect campaign performance.

What happens when authentication fails

When SPF, DKIM, or DMARC fails, the consequences depend on which one broke and how the receiving server handles it:

Failure	Impact	Common Cause
SPF fails	Email flagged as suspicious. Often lands in spam.	Sending from a server not listed in SPF record. Or multiple SPF records on the domain.
DKIM fails	Email looks potentially tampered with. Reduced trust score.	DKIM not activated in provider settings. Wrong selector in DNS.
DMARC fails	Depends on policy. p=none does nothing. p=quarantine sends to spam. p=reject blocks entirely.	SPF and DKIM both failing. Or alignment mismatch between header and envelope domains.
All three fail	Email almost certainly goes to spam or gets rejected.	Brand new domain with no DNS records configured. Or DNS records deleted accidentally.

The fix is almost always a DNS record edit. Check MXToolbox, find the failing record, fix it, wait for propagation (15 minutes to 48 hours depending on TTL), and verify again.

Authentication for cold email senders specifically

Cold email has additional authentication considerations that regular business email doesn't:

Multiple sending tools. If you use Instantly, Smartlead, or another cold email platform alongside Google Workspace, your SPF record needs to include both. Same for DKIM. Check each tool's documentation for their specific DNS requirements.

New domains with no history. Authentication alone doesn't build reputation. A brand new domain with perfect SPF, DKIM, and DMARC will still have a neutral (not positive) reputation. That's why warmup matters even when authentication is configured correctly. Our cold email domains calculator covers how many domains you need and the day-by-day warmup timeline.

Volume sensitivity. Email providers track authentication pass rates as a percentage. If 95% of your emails pass and 5% fail, that's fine for a normal business domain. But cold email domains are under more scrutiny. Aim for 100% pass rate. Any failures need immediate investigation.

Google and Yahoo requirements (2024+). Both Google and Yahoo now require SPF, DKIM, and DMARC for senders sending more than 5,000 emails per day. Even below that threshold, having all three properly configured gives you a significant deliverability advantage over senders who don't.