SPF, DKIM, DMARC for Cold Email: The Complete DNS Setup Guide with Error Analysis

Three DNS records determine whether your cold emails land in inbox or spam: SPF, DKIM, and DMARC. We audited DNS configurations across 1,000+ domains onboarded to MailDeck and found that 67% had at least one critical authentication error before we fixed it. The most common: multiple SPF records on a single domain (23% of cases), which silently breaks authentication and sends everything to spam.

This guide covers exactly how to set up each record for cold email, the 10 errors we see most often, and how to verify your configuration is correct.

What SPF, DKIM, and DMARC Actually Do

Before setup instructions, here's what each record does in plain language:

SPF (Sender Policy Framework) tells receiving mail servers which IP addresses and servers are allowed to send email on behalf of your domain. If an email arrives from a server not listed in your SPF record, the receiving server knows it's unauthorized.

Technical reference: RFC 7208

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every email you send. The receiving server uses a public key published in your DNS to verify the signature. If the email was altered in transit, the signature won't match and DKIM fails.

Technical reference: RFC 6376

DMARC (Domain-based Message Authentication, Reporting & Conformance) ties SPF and DKIM together. It tells receiving servers: "If an email claims to be from my domain but fails both SPF and DKIM, here's what to do with it — nothing (none), quarantine it, or reject it."

Technical reference: RFC 7489

All three work together. SPF alone is not enough. DKIM alone is not enough. DMARC without SPF and DKIM is useless.

SPF Setup for Cold Email

The Correct SPF Record

An SPF record is a TXT record on your domain's DNS. Here are the correct records for major providers:

Microsoft 365 (used by MailDeck):

```

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

```

Google Workspace:

```

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

```

If using both Microsoft 365 and Google Workspace (not recommended for cold email):

```

v=spf1 include:spf.protection.outlook.com include:_spf.google.com -all

```

If using a third-party sequencer that sends directly (e.g., Instantly, Smartlead):

```

v=spf1 include:spf.protection.outlook.com include:_spf.sequencer-domain.com -all

```

SPF Syntax Rules

Every SPF record must start with v=spf1. This is not optional — without it, the record is ignored entirely.

The record ends with an "all" mechanism that defines the default policy:

The 10-Lookup Limit

SPF records are limited to 10 DNS lookups (RFC 7208, Section 4.6.4). This is the most commonly misunderstood rule in email authentication.

What counts as a lookup:

• Each include: = 1 lookup (plus any nested includes inside it)
• Each a: = 1 lookup
• Each mx: = 1 lookup
• Each redirect= = 1 lookup

What does NOT count:

• ip4: and ip6: mechanisms (use these when possible)
• The all mechanism

Real-world example of the problem:

```

v=spf1 include:spf.protection.outlook.com include:_spf.google.com include:sendgrid.net include:spf.sendinblue.com include:mailgun.org include:amazonses.com include:_spf.salesforce.com -all

```

This record has 7 direct includes, but include:_spf.google.com alone contains 4 nested lookups. Total: 11+ lookups. This exceeds the limit, SPF returns permerror, and authentication fails silently.

How to check your lookup count:

Use MXToolbox SPF Lookup or run in terminal:

```

dig TXT yourdomain.com +short

```

Then count each include:, a:, mx:, and redirect=, including nested records.

DKIM Setup for Cold Email

How DKIM Works

DKIM uses a pair of cryptographic keys:

1. Private key — stored on your email server, used to sign outgoing emails
2. Public key — published in your DNS as a TXT record, used by receiving servers to verify the signature

You don't create these manually. Your email provider (Microsoft 365, Google Workspace) generates both keys. You only need to publish the public key in DNS.

DKIM DNS Record

DKIM records are TXT records with a specific naming format:

```

selector._domainkey.yourdomain.com

```

Microsoft 365 example:

```

Host: selector1._domainkey.yourdomain.com

Type: CNAME

Value: selector1-yourdomain-com._domainkey.yourtenant.onmicrosoft.com

```

Microsoft 365 uses two selectors (selector1 and selector2) for key rotation.

Google Workspace example:

```

Host: google._domainkey.yourdomain.com

Type: TXT

Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A... (your public key)

```

DKIM Key Length

DKIM keys come in two sizes:

Google Workspace defaults to 1024-bit. You must manually enable 2048-bit in Admin Console → Apps → Google Workspace → Gmail → Authenticate Email.

Microsoft 365 defaults to 1024-bit for initial setup but supports 2048-bit through rotation. After initial DKIM setup, rotate keys to upgrade to 2048-bit via Exchange Admin Center.

DMARC Setup for Cold Email

The Correct DMARC Record

DMARC is a TXT record at _dmarc.yourdomain.com.

Stage 1 — Monitoring (start here):

```

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

```

This collects reports without affecting delivery. Run for 2-4 weeks to identify any legitimate sending sources you might have missed in SPF.

Stage 2 — Quarantine:

```

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

```

Emails failing both SPF and DKIM go to spam. Move to this after confirming all legitimate sources pass authentication.

Stage 3 — Reject (maximum protection):

```

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

```

Emails failing both SPF and DKIM are rejected entirely. This is the strongest signal to receiving servers that you take authentication seriously.

Why DMARC Matters for Cold Email

According to Google's Email Sender Guidelines, bulk senders (5,000+ messages per day) must have DMARC configured. As of February 2024, Google and Yahoo enforce this requirement.

Enterprise recipients increasingly check DMARC. Emails from domains without DMARC are filtered more aggressively by corporate mail servers running Microsoft Exchange Online Protection and Google's spam filters.

DMARC Alignment

DMARC checks "alignment" — whether the domain in the From: header matches the domains used in SPF and DKIM. There are two alignment modes:

For cold email, relaxed alignment (default) is fine. Strict alignment can cause failures if your sending subdomain differs from your From: address domain.

The 10 Most Common DNS Errors in Cold Email

Based on our audit of 1,000+ domains onboarded to MailDeck, here are the errors we find most frequently, ranked by how often we see them:

Error #1: Multiple SPF Records (23% of domains)

The problem: A domain has two or more TXT records starting with v=spf1. Per RFC 7208, only one SPF record is allowed. When multiple exist, receiving servers should return permerror — SPF fails.

How it happens: The domain owner adds an SPF record for their email provider, then later adds another for a marketing tool, without merging them.

Wrong:

```

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

v=spf1 include:sendgrid.net -all

```

Correct:

```

v=spf1 include:spf.protection.outlook.com include:sendgrid.net -all

```

How to check:

```

dig TXT yourdomain.com +short | grep "v=spf1"

```

If you see more than one line starting with v=spf1, you have this error.

Error #2: No DMARC Record (19% of domains)

The problem: SPF and DKIM are configured, but DMARC is missing entirely. Without DMARC, receiving servers have no policy guidance for failed authentication, and you get no reporting on who is sending as your domain.

How to check:

```

dig TXT _dmarc.yourdomain.com +short

```

If empty — DMARC is missing.

Fix: Add the Stage 1 monitoring record immediately:

```

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

```

Error #3: SPF with +all (14% of domains)

The problem: The SPF record ends with +all instead of -all or ~all. This tells receiving servers "anyone in the world is authorized to send email as my domain." It effectively disables SPF.

How it happens: Copy-paste errors, or following outdated guides that use +all as a "temporary" setting during testing.

Fix: Replace +all with -all immediately. There is no legitimate reason to use +all.

Error #4: Exceeding 10 DNS Lookups (12% of domains)

The problem: SPF record has too many include: mechanisms, exceeding the 10-lookup limit. SPF returns permerror and fails silently — you won't see an error unless you specifically test for it.

Fix: Audit your includes. Remove services you no longer use. Replace include: with ip4: where the sending IP is static. Consider using SPF flattening tools like AutoSPF for complex configurations.

Error #5: DKIM Not Enabled (11% of domains)

The problem: The email provider supports DKIM, but it was never turned on. Microsoft 365 and Google Workspace both require manual DKIM activation — it's not automatic.

Microsoft 365: Go to Microsoft Defender → Policies → Email Authentication → DKIM → Select domain → Enable.

Google Workspace: Go to Admin Console → Apps → Google Workspace → Gmail → Authenticate Email → Generate DKIM key → Add DNS record → Start authentication.

Error #6: DMARC Stuck on p=none (9% of domains)

The problem: DMARC was set to p=none for monitoring and never progressed to quarantine or reject. At p=none, receiving servers take no action on failed emails — you're only collecting reports.

Fix: After 2-4 weeks of monitoring with clean reports, move to p=quarantine. After another 2-4 weeks, move to p=reject.

Error #7: Wrong DKIM Selector (4% of domains)

The problem: The DKIM DNS record uses a selector that doesn't match what the email server is signing with. The receiving server looks up the wrong public key, signature verification fails.

How to check: Send a test email to mail-tester.com and check the DKIM section for selector mismatches.

Error #8: SPF Record Too Long (3% of domains)

The problem: A single DNS TXT record is limited to 255 characters per string. SPF records longer than this need to be split into multiple strings within one TXT record. Some DNS providers don't handle this correctly.

How to check: If your SPF record is longer than 255 characters and you're seeing intermittent SPF failures, this may be the cause.

Error #9: Missing MX Records (2% of domains)

The problem: The domain has SPF, DKIM, and DMARC, but no MX record. Some receiving servers check whether the sending domain can receive email. No MX record raises a red flag.

Fix: Add an MX record pointing to your email provider, even if you don't plan to receive email on cold email domains.

Error #10: DMARC rua Email Doesn't Exist (1% of domains)

The problem: The DMARC record specifies rua=mailto:dmarc@yourdomain.com but that email address doesn't exist or can't receive mail. DMARC reports bounce, and you have no visibility into authentication results.

Fix: Create the mailbox specified in your rua tag, or use a DMARC reporting service like Postmark DMARC (free) to receive and visualize reports.

Complete Setup Checklist

Use this checklist to verify your DNS configuration for each cold email domain:

SPF:

• [ ] Exactly one TXT record starting with v=spf1
• [ ] Includes your email provider's SPF mechanism
• [ ] Ends with -all (or ~all during initial setup only)
• [ ] Total DNS lookups ≤ 10 (including nested)
• [ ] Verified with MXToolbox SPF check

DKIM:

• [ ] DKIM enabled in email provider admin panel
• [ ] DNS CNAME or TXT record published with correct selector
• [ ] Key length is 2048-bit (not 1024-bit)
• [ ] Verified by sending test email to mail-tester.com

DMARC:

• [ ] TXT record exists at _dmarc.yourdomain.com
• [ ] Policy is p=quarantine or p=reject (not stuck on p=none)
• [ ] rua email address exists and can receive reports
• [ ] Verified with MXToolbox DMARC check

General:

• [ ] MX record exists for the domain
• [ ] All records propagated (check with dig or DNSChecker.org)
• [ ] Test email passes all checks on mail-tester.com (score 9+/10)

Verification Tools

These free tools help verify your DNS configuration:

How MailDeck Handles DNS Authentication

For context on our approach: MailDeck automates SPF, DKIM, and DMARC configuration for all domains provisioned through our platform. During the 48-hour onboarding, our system configures all three records, verifies propagation, and flags any issues before the first email is sent.

This is why our setup takes 48 hours instead of 10 minutes — we wait for full DNS propagation and verify authentication end-to-end. The result is 98% inbox placement from day one, versus the weeks of troubleshooting that manual DNS setup often requires.

For teams managing their own DNS (or using other providers), this guide covers everything you need to configure correctly.

FAQ

What DNS records do I need for cold email?

You need three DNS records: SPF (defines which servers can send from your domain), DKIM (cryptographic signature verifying email integrity), and DMARC (policy for handling failed authentication). All three are required — missing any one significantly reduces inbox placement rates.

What is the correct SPF record for cold email?

For Microsoft 365: v=spf1 include:spf.protection.outlook.com -all. For Google Workspace: v=spf1 include:_spf.google.com -all. The record must start with v=spf1, include your provider's sending servers, end with -all, and stay under 10 DNS lookups.

What should my DMARC policy be for cold email?

Start with p=none for 2-4 weeks of monitoring, then progress to p=quarantine, then p=reject. Most cold email domains should reach p=reject within 4-8 weeks. Staying on p=none indefinitely provides no deliverability benefit.

Why are my cold emails going to spam despite having SPF and DKIM?

Most common reasons from our audit data: DMARC is missing (19% of cases), multiple SPF records exist on the domain (23%), SPF exceeds 10 DNS lookups (12%), or DKIM was never actually enabled in the email provider (11%). Use mail-tester.com to identify the specific failure.

How many DNS lookups can an SPF record have?

The limit is 10 DNS lookups per RFC 7208. Each include:, a:, mx:, and redirect= counts as one lookup. Nested includes inside other includes also count. Exceeding 10 causes SPF to return permerror. Use ip4: and ip6: instead of includes where possible — IP mechanisms don't count toward the limit.

How long does DNS propagation take?

DNS changes typically propagate within 1-48 hours depending on TTL settings and DNS provider. Most changes are visible globally within 4-6 hours. Set TTL to 300 seconds (5 minutes) before making changes to speed up propagation.

Should I use -all or ~all in my SPF record?

Use -all (hard fail) for cold email domains. The only reason to use ~all (soft fail) is during initial setup when you're still identifying all legitimate sending sources. Once your SPF record is complete, switch to -all. Never use +all.

Methodology

This analysis is based on DNS audits of 1,000+ domains onboarded to MailDeck between January 2025 and March 2026. Error percentages reflect the state of DNS records at the time of onboarding, before our automated system applied corrections.

Data collected: January 2025 — March 2026

Domains audited: 1,000+

Last updated: March 2026

Written by Nikita Stoletov

CTO | Outbound Infrastructure & Deliverability Engineering

CTO designing cold email infrastructure and outbound systems at scale. Built and managed infrastructure delivering over 50M emails monthly across 1,200+ domains with 98% inbox placement.

LinkedIn View Profile