SPF, DKIM, and DMARC Setup Guide for Cold Email Teams

Why Authentication Matters for Cold Email

Email authentication — SPF, DKIM, and DMARC — is the technical foundation that determines whether your emails reach the inbox or land in spam. For cold email senders, where recipient engagement signals are initially low, authentication carries outsized weight in deliverability decisions.

In a January 2026 audit of 1,847 cold email domains on our platform, we found:

• 34.2% had at least one authentication misconfiguration
• 12.7% had SPF records that exceeded the 10-lookup limit
• 8.4% had DKIM alignment failures (signing domain did not match From domain)
• 18.9% had DMARC set to p=none with no plan to upgrade
• 6.1% had no DMARC record at all

Domains with all three protocols correctly configured showed a median inbox placement rate 14.3 percentage points higher than domains with one or more misconfigurations (91.7% vs. 77.4% across a 30-day measurement period).

This guide provides exact DNS record configurations, a testing checklist, and troubleshooting for the most common failure modes. It is written for technical operators, not marketers — you will need access to your domain's DNS management panel.

SPF (Sender Policy Framework)

What SPF Does

SPF tells receiving mail servers which IP addresses are authorized to send email on behalf of your domain. When a server receives an email claiming to be from your-domain.com, it checks the SPF record to verify the sending IP is authorized. If it is not, the email fails SPF authentication.

Correct SPF Record Format

SPF is published as a TXT record on your domain's root (@ or bare domain). The record must start with v=spf1 and end with an -all (hard fail) or ~all (soft fail) mechanism.

Example: Google Workspace only

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

Example: Google Workspace + third-party sending service

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

Example: Microsoft 365 only

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

Example: Microsoft 365 + Mailgun

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

The 10-Lookup Limit

SPF records are evaluated using DNS lookups. Each include:, a, mx, and redirect mechanism consumes one lookup. Nested includes (an include that itself contains includes) count toward the total. The SPF specification (RFC 7208) limits evaluation to 10 DNS lookups.

Exceeding 10 lookups causes SPF to return a "permerror" result — effectively the same as no SPF record. In our audit, 12.7% of domains exceeded this limit, typically because they had accumulated includes from multiple SaaS tools (CRM, marketing automation, transactional email, helpdesk) over time.

How to check your lookup count:

dig TXT your-domain.com +short

Then recursively count each include and its nested includes. Online tools like MXToolbox SPF Lookup or dmarcian SPF Surveyor will calculate this automatically.

How to fix lookup limit exceedance:

• Remove includes for services you no longer use
• Replace include: mechanisms with ip4: or ip6: directives for services with stable IP ranges (fewer lookups)
• Use an SPF flattening service that resolves includes to IP addresses and keeps the record within limits (note: flattened records must be updated when provider IPs change)

Hard Fail vs. Soft Fail

-all (hard fail) instructs receiving servers to reject emails from unauthorized IPs. ~all (soft fail) instructs them to accept but flag the email. For cold email, we recommend ~all during initial setup and the first 30 days of warmup, then upgrading to -all once you have confirmed all legitimate sending sources are included.

DKIM (DomainKeys Identified Mail)

What DKIM Does

DKIM attaches a cryptographic signature to every outgoing email. The receiving server uses a public key (published in your DNS) to verify that the email content was not modified in transit and that the signature was generated by the claimed sending domain.

Setting Up DKIM

DKIM requires two components: a private key (stored on your email server or provider) and a public key (published as a DNS TXT record).

Google Workspace DKIM setup:

1. In Google Admin Console, navigate to Apps → Google Workspace → Gmail → Authenticate email
2. Select your domain and click "Generate new record"
3. Choose 2048-bit key length (1024-bit is deprecated by most providers as of 2025)
4. Copy the generated TXT record value
5. Add a TXT record in your DNS with host/name: google._domainkey and the value from step 4
6. Return to Google Admin Console and click "Start authentication"

Example DKIM DNS record:

Host: google._domainkey.your-domain.com
Type: TXT
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA... (truncated)

Microsoft 365 DKIM setup:

1. In Microsoft 365 Defender portal, navigate to Email & collaboration → Policies & rules → Threat policies → Email authentication settings → DKIM
2. Select your domain
3. Add two CNAME records to your DNS:
   • Host: selector1._domainkey → Value: selector1-your-domain-com._domainkey.your-tenant.onmicrosoft.com
   • Host: selector2._domainkey → Value: selector2-your-domain-com._domainkey.your-tenant.onmicrosoft.com
4. Wait for DNS propagation (up to 48 hours), then enable DKIM signing in the Defender portal

DKIM Alignment

DKIM alignment means the domain in the DKIM signature (the d= field) matches the domain in the email's From header. Misalignment occurs when:

• You send through a third-party service that signs with its own domain (e.g., d=sendgrid.net) instead of your domain
• You have DKIM configured for a parent domain but send from a subdomain (or vice versa) without relaxed alignment

In our audit, 8.4% of domains had DKIM alignment failures. The fix is always to configure custom DKIM signing on your sending service so that it signs with your domain, not the service's default domain.

DMARC (Domain-based Message Authentication, Reporting & Conformance)

What DMARC Does

DMARC builds on SPF and DKIM by adding a policy layer. It tells receiving servers what to do when an email fails both SPF and DKIM checks: accept it (p=none), quarantine it to spam (p=quarantine), or reject it entirely (p=reject). DMARC also enables reporting — receiving servers send aggregate reports back to you showing authentication pass/fail rates.

DMARC Record Configuration

DMARC is published as a TXT record on the _dmarc subdomain.

Starting configuration (monitoring only):

Host: _dmarc.your-domain.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@your-domain.com; pct=100

Intermediate configuration (after 30 days of clean reports):

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@your-domain.com; pct=100

Full enforcement (after 60+ days, all sources aligned):

v=DMARC1; p=reject; rua=mailto:dmarc-reports@your-domain.com; pct=100

DMARC Policy Progression

We recommend a staged approach:

1. Weeks 1–4 (p=none): Monitor reports. Identify all legitimate sending sources. Fix SPF and DKIM alignment issues.
2. Weeks 5–8 (p=quarantine): Non-aligned emails go to spam instead of inbox. Monitor for false positives (legitimate email being quarantined).
3. Week 9+ (p=reject): Non-aligned emails are rejected entirely. Only implement this after confirming all legitimate email sources pass authentication.

In our platform data, domains at p=reject had 2.7 percentage points higher inbox placement than domains at p=none, all else equal. The improvement was more pronounced for Outlook recipients (+3.4 pp) than Gmail recipients (+1.9 pp).

Testing Methodology

After configuring all three protocols, verify them using this checklist:

Automated Checks

1. SPF validation: Use dig TXT your-domain.com or MXToolbox to confirm the record exists, parses correctly, and is under 10 lookups.
2. DKIM validation: Send a test email to a Gmail address, open it, click the three-dot menu → "Show original." Look for dkim=pass in the Authentication-Results header. Verify the d= domain matches your From domain.
3. DMARC validation: Use dig TXT _dmarc.your-domain.com to confirm the record exists and parses correctly.
4. Aggregate test: Send a test email to mail-tester.com and review the authentication section of the report. Score should be 9/10 or higher with all three protocols passing.

Manual Verification

1. Send test emails from every sending source (primary mailbox, secondary mailbox, any third-party services) to confirm all pass SPF and DKIM.
2. Wait 24–48 hours after initial DMARC deployment, then check aggregate reports (sent to the rua address) for any authentication failures.
3. If using multiple sending services, verify DKIM alignment for each service individually.

8 Common Misconfigurations and Their Impact

Based on our audit of 1,847 domains, these are the most frequent authentication errors:

1. Multiple SPF Records (4.3% of domains)

Problem: DNS contains two or more TXT records starting with v=spf1. RFC 7208 specifies that multiple SPF records cause a permerror — SPF effectively fails.

Impact: SPF always fails. Inbox placement drops 11–18 pp.

Fix: Merge all SPF directives into a single TXT record.

2. SPF Lookup Limit Exceeded (12.7% of domains)

Problem: More than 10 DNS lookups in the SPF evaluation chain.

Impact: SPF returns permerror. Same effect as no SPF record.

Fix: Remove unused includes. Replace includes with IP addresses where possible. Use SPF flattening if needed.

3. DKIM Not Enabled After DNS Record Creation (6.2% of domains)

Problem: DNS record exists but DKIM signing was never activated in the provider console. Emails are sent without DKIM signatures despite the public key being published.

Impact: DKIM check returns "none" (no signature found) rather than "pass."

Fix: Complete the activation step in your provider's admin console.

4. DKIM Alignment Failure (8.4% of domains)

Problem: DKIM signature uses a different domain (typically the ESP's default domain) than the From address.

Impact: DKIM passes technically but fails DMARC alignment. If SPF also fails alignment, DMARC reports a failure.

Fix: Configure custom DKIM signing on all sending services to use your domain.

5. DMARC Record Syntax Errors (3.1% of domains)

Problem: Typos, missing semicolons, or invalid tag values in the DMARC record (e.g., p=Non instead of p=none).

Impact: DMARC record is ignored entirely. No policy enforcement, no reports.

Fix: Validate record syntax using dmarcian or MXToolbox DMARC lookup tools.

6. Missing DMARC Record (6.1% of domains)

Problem: No DMARC record published. SPF and DKIM may still pass, but the domain has no policy enforcement and receives no authentication reports.

Impact: Moderate. Gmail and Yahoo as of February 2024 require at minimum DMARC p=none for bulk senders. Missing DMARC may trigger throttling for high-volume senders.

Fix: Add a DMARC record starting with p=none.

7. Stale SPF Records After Provider Migration (5.8% of domains)

Problem: Domain migrated from one email provider to another (e.g., G Suite to Microsoft 365) but the old provider's include remains in the SPF record while the new one was added.

Impact: Wastes SPF lookups. May cause lookup limit exceedance. Old provider include is unnecessary but harmless unless it pushes you over 10 lookups.

Fix: Audit SPF includes against current sending sources. Remove includes for services no longer in use.

8. Using 1024-bit DKIM Keys (7.3% of domains)

Problem: DKIM key length is 1024 bits. While technically still valid, 1024-bit keys are considered weak by modern standards and some receiving servers may assign lower trust scores.

Impact: Minor. DKIM still passes, but security-conscious receivers may flag the key as suboptimal. Google recommends 2048-bit keys.

Fix: Regenerate DKIM keys at 2048-bit length and update DNS records.

Ongoing Monitoring

Authentication is not a set-and-forget configuration. We recommend:

• Review DMARC aggregate reports weekly for the first 60 days, then monthly
• Re-validate SPF, DKIM, and DMARC after any DNS changes, provider additions, or email infrastructure changes
• Monitor inbox placement as a downstream indicator — authentication issues often manifest as gradual placement decline before they appear in DMARC reports
• Set calendar reminders to check DKIM key rotation (recommended annually for 2048-bit keys)

Limitations of This Guide

• DNS configuration interfaces vary by registrar and hosting provider. Exact navigation steps will differ from the examples shown here.
• Authentication alone does not guarantee inbox placement. Content quality, sending reputation, recipient engagement, and list hygiene are independent factors.
• The audit data (1,847 domains) is drawn from WarmySender users, who skew toward cold email senders. Misconfiguration rates in the broader email-sending population may differ.
• Provider-specific DKIM setup steps reflect interfaces as of March 2026. Admin console layouts change; verify against current documentation.

Audit data collected January 2026 across 1,847 domains on the WarmySender platform. Guide last verified against Google Workspace and Microsoft 365 admin interfaces on March 15, 2026. Contact research@warmysender.com for questions.