SPF, DKIM, and DMARC for Cold Email: The Complete Setup Guide

Why These Three Records Decide Whether You Land in the Inbox

Google, Microsoft, Yahoo, and every other major inbox provider evaluate sender reputation before deciding where to deliver your email. The first thing they check isn't your content, your copy, or even your list hygiene — it's whether the email is cryptographically authenticated.

Three DNS records govern authentication: SPF, DKIM, and DMARC. Get them right and inbox providers treat you as a legitimate sender before they even read the email. Get them wrong (or skip them) and you're landing in spam regardless of how good your campaign is.

In February 2024, Google and Yahoo made these requirements explicit: any sender pushing more than 5,000 messages per day to Gmail or Yahoo inboxes must have all three configured correctly, or mail gets rejected outright. For cold email senders running multiple mailboxes, this isn't optional — it's table stakes.

This guide walks through exactly what each record does, how to set them up, and how to verify everything is working before you send a single email.

SPF — Sender Policy Framework

What It Does

SPF tells inbox providers which IP addresses are authorized to send email on behalf of your domain. When a message arrives claiming to be from sales@yourcompany.com, the receiving server looks up your domain's SPF record and checks whether the originating IP is in the allowed list.

If yes → email passes SPF. If no → email fails SPF, which is a significant negative signal.

The SPF Record Format

An SPF record is a TXT DNS record on your domain's root. It looks like this:

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

Breaking it down:

• v=spf1 — SPF version identifier (always this)
• include:_spf.google.com — authorizes Google Workspace servers
• include:spf.coldrelay.com — authorizes ColdRelay's sending infrastructure
• ~all — "softfail" any IP not in the above list (treat as suspicious but don't reject)

Common SPF Scenarios

Using only Google Workspace:

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

Using Google Workspace + a cold email platform:

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

Using Microsoft 365 + a cold email platform:

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

Using dedicated infrastructure only:

v=spf1 include:spf.coldrelay.com ~all

The 10-Lookup Limit

SPF has a hard technical limit: the record (after all include: lookups are resolved) can perform at most 10 DNS lookups. Exceed this and receivers treat the SPF as invalid — equivalent to having no SPF at all.

This is a common failure point when teams stack multiple email tools (CRM, marketing automation, transactional email, cold email sender, helpdesk) on one domain. Each tool wants its own include: and you quickly blow past 10 lookups.

How to check: Use an SPF flattening tool or spf-record.com to count lookups. If you're at 9 or 10, you're near the cliff.

How to fix: Either consolidate email providers, use an SPF flattening service that rewrites the record with direct IPs, or split senders across subdomains.

The all Mechanism

The final part of an SPF record defines what happens to unauthorized senders:

• -all — "hard fail" — reject unauthorized mail
• ~all — "soft fail" — flag but don't reject (recommended for cold email)
• ?all — "neutral" — not recommended, effectively no enforcement
• +all — "pass all" — catastrophic, authorizes every server in the world (never use)

For cold email, use ~all. Hard fail (-all) can cause legitimate forwarded emails to bounce in edge cases.

DKIM — DomainKeys Identified Mail

What It Does

DKIM adds a cryptographic signature to every outgoing email. The signature is generated using a private key stored on your sending server; the matching public key is published as a DNS record on your domain.

When an email arrives, the receiving server:

1. Looks up the public key from your DNS
2. Verifies the signature
3. Confirms the message hasn't been tampered with in transit
4. Confirms the sender controls the claimed domain

If any of these fail → email fails DKIM, major negative signal.

The DKIM Record Format

DKIM records live at a subdomain like selector._domainkey.yourcompany.com where selector is a unique identifier your provider chooses (often google, k1, s1, or a custom name).

Example:

Host: google._domainkey.yourcompany.com
Type: TXT
Value: v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ...

The long string starting with p= is your public key. You don't generate this — your email provider (Google Workspace, Microsoft 365, ColdRelay, etc.) gives it to you.

Setting Up DKIM by Provider

Google Workspace:

1. Admin Console → Apps → Google Workspace → Gmail → Authenticate email
2. Generate a new record (choose 2048-bit key if available)
3. Copy the selector (usually google) and the TXT value
4. Add as TXT record at google._domainkey.yourcompany.com
5. Wait 48 hours, then click "Start authentication" in Admin Console

Microsoft 365:

1. Microsoft 365 Defender → Policies → DKIM
2. Select your domain → Enable
3. Microsoft provides two CNAME records (selector1 and selector2) to add
4. Add both CNAMEs
5. Return to Defender, click Enable

ColdRelay and similar cold email platforms: Each platform provides a DKIM record when you add a domain. Most require a CNAME pointing to their infrastructure (e.g., cr1._domainkey.yourcompany.com → cr1.dkim.coldrelay.com).

Multiple DKIM Selectors

You can (and should) have multiple DKIM records on the same domain if you send through multiple tools. Each tool uses its own selector. Google uses google, Microsoft uses selector1 and selector2, ColdRelay might use cr1, etc. They coexist peacefully.

DMARC — Domain-based Message Authentication

What It Does

DMARC is the policy layer on top of SPF and DKIM. It tells receiving servers:

1. What to do with messages that fail SPF and/or DKIM (reject, quarantine, or monitor)
2. Where to send reports about authentication results across all mail claiming to be from your domain

Without DMARC, a failed SPF or DKIM is ambiguous — the receiver has to guess whether to deliver. With DMARC, you've told them exactly what to do.

The DMARC Record Format

DMARC records live at _dmarc.yourcompany.com:

Host: _dmarc.yourcompany.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc@yourcompany.com; pct=100; adkim=r; aspf=r

Breaking it down:

• v=DMARC1 — version identifier
• p=none — policy (none = monitor only, don't act on failures)
• rua=mailto:dmarc@yourcompany.com — where to send aggregate reports
• pct=100 — apply policy to 100% of failing mail
• adkim=r — relaxed DKIM alignment (allows subdomains)
• aspf=r — relaxed SPF alignment (allows subdomains)

The Three Policy Levels

p=none — Monitor Log authentication failures and send reports, but don't change delivery. This is the starting policy. Run it for 2–4 weeks to confirm everything is authenticating correctly.

p=quarantine — Send to Spam Failing messages are delivered to the spam folder. Use this after you've verified (via aggregate reports) that all legitimate mail is passing.

p=reject — Reject Outright Failing messages are rejected at the server, never delivered. Use only after you're 100% confident in your authentication setup.

The Gmail/Yahoo Requirement (2024+)

For cold email senders targeting Gmail and Yahoo at scale, DMARC is required as of February 2024:

• Must have a DMARC record at _dmarc.yourdomain.com
• Policy must be at least p=none (monitoring level)
• Without DMARC, mail gets rejected with a permanent failure

Most cold email senders run p=none indefinitely. This satisfies the requirement without risking legitimate mail if authentication breaks.

The Setup Sequence — Exact Order to Follow

Authenticate in this order:

Step 1: SPF First

Add your SPF record before doing anything else. Without SPF, DKIM and DMARC mean less.

Verify: Use mxtoolbox.com/spf.aspx or dmarcian.com/spf-survey/ to check the record resolves correctly and stays under 10 lookups.

Step 2: DKIM Second

Configure DKIM for each provider sending mail from your domain. Add multiple selectors as needed.

Verify: Send a test email to a Gmail address, open in Gmail, click "Show original" — look for "DKIM: 'PASS'".

Step 3: DMARC Third — Start with p=none

Only add DMARC after SPF and DKIM are both passing for 7+ days. Start with monitoring policy:

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; pct=100

Verify: Wait 2–3 days, check your DMARC reports inbox — you should start receiving aggregate reports (XML files) from major providers.

Step 4: Ramp DMARC Policy

After 2–4 weeks of p=none with clean reports (no unauthenticated legitimate mail surfaces):

1. Move to p=quarantine with pct=25
2. After 2 weeks clean: p=quarantine with pct=100
3. After 4 weeks clean: p=reject with pct=25
4. After another 2 weeks: p=reject with pct=100

Never jump directly to p=reject. It's the fastest way to accidentally reject your own legitimate mail.

Common Misconfigurations That Break Everything

Misconfiguration 1: Multiple SPF Records

DNS allows multiple TXT records on the same host, but SPF spec says there can only be one SPF record per domain. Having two or more v=spf1 ... records at the root = all of them invalidate each other.

Fix: Consolidate into one record with multiple include: statements.

Misconfiguration 2: DKIM Selector Mismatch

You've set up DKIM on Google Workspace, but mail is being signed with a selector that doesn't have a matching DNS record. Happens when you forget to click "Start Authentication" after adding the DNS record.

Fix: Verify in provider admin panel that DKIM signing is actually enabled, not just configured.

Misconfiguration 3: DMARC Without Alignment Awareness

Mail is DKIM-signed by your sending tool (e.g., dkim.coldrelay.com), but the From address says sales@yourcompany.com. Without proper alignment configuration, DMARC sees the signing domain doesn't match and fails.

Fix: Ensure your sending tool uses CNAME-based DKIM that keeps signing aligned with your actual domain. Most reputable platforms handle this automatically.

Misconfiguration 4: Copying Records Wrong

The most common issue in practice. A single wrong character in a DKIM public key and verification fails for every email. A missing semicolon in SPF and the record doesn't parse.

Fix: Copy records directly from provider admin panels (don't retype). Use a DNS checker (mxtoolbox, dmarcian) to validate after every change.

Misconfiguration 5: Subdomain Mail Without Subdomain Authentication

You send from sales@outbound.yourcompany.com but SPF, DKIM, and DMARC are only configured on yourcompany.com. Subdomains inherit some things but not all — misconfigured subdomain mail lands in spam.

Fix: Authenticate each sending subdomain independently. Some records (like DMARC with sp=) can cover subdomains; others need explicit setup.

Misconfiguration 6: Using Spoofable Free Email Domains

Setting SPF/DKIM/DMARC on a domain you don't actually control (like trying to "authenticate" a @gmail.com sender). You can't. These protocols only work for domains you own and control DNS for.

Fix: Always send cold email from your own domain, never from a free email provider.

How to Verify Everything Is Working

Method 1: Send a Test, Read the Headers

Send an email from your cold email setup to a Gmail inbox you control. Open the message in Gmail, click the three-dot menu → "Show original". Look for:

SPF:      PASS with IP ...
DKIM:     'PASS' with domain yourcompany.com
DMARC:    'PASS'

All three should say PASS. If any say FAIL or NEUTRAL, fix before proceeding.

Method 2: Use an External Authentication Checker

Free tools that analyze your setup:

• mxtoolbox.com — SPF, DKIM, DMARC lookup + "Email Health" check
• dmarcian.com — DMARC analyzer and report parser
• mail-tester.com — sends a test email to a generated address, returns full authentication report + deliverability score
• glockapps.com — seed testing across Gmail, Outlook, Yahoo inbox folders

Method 3: Review DMARC Aggregate Reports

Once DMARC is set up, you'll receive XML reports from Google, Microsoft, etc. showing which IPs sent mail claiming to be from your domain and whether they passed authentication. Read these to catch unauthorized senders or misconfigurations.

Reports are dense XML — use a parser like dmarcian.com, postmark.com, or valimail.com to visualize.

The Bottom Line

SPF, DKIM, and DMARC are the baseline of cold email deliverability. Not advanced optimizations — the starting point. You can't skip this and expect inbox placement.

Setup takes 30–60 minutes if you do it carefully. It has a 48-hour DNS propagation window before everything activates. Then it keeps working indefinitely, protecting your sender reputation and ensuring your cold emails land in inboxes instead of spam folders.

The teams that treat authentication as "IT paperwork" and skip it are the same teams wondering why their open rates are 10% while the competition hits 50%. It's not the tools, the copy, or the lists — it's the DNS records nobody got around to setting up.

FAQ

Do I need SPF, DKIM, AND DMARC? Isn't one enough?

All three. SPF authorizes senders, DKIM signs messages, DMARC provides the policy layer tying them together. Gmail and Yahoo require all three at scale. Skipping any one breaks deliverability significantly.

Will wrong DMARC policy reject my legitimate emails?

Yes, if you jump to p=reject without verifying authentication first. That's why the sequence is: set up SPF → set up DKIM → start with DMARC p=none → ramp to quarantine → then reject, over weeks, watching reports.

I use multiple email tools — do I need separate records for each?

SPF: one consolidated record listing all senders. DKIM: separate selector record per tool. DMARC: one record per domain (multiple tools share it).

How long does DNS propagation take?

Most providers propagate within 1–4 hours. TTL (time-to-live) settings on your DNS can extend this. Wait 48 hours before concluding a record "isn't working" — often it's still propagating.

Can I use SPF/DKIM/DMARC on a shared domain?

Yes, but it's complicated. Hosted email domains (like @mycompany.shopify.com or @mycompany.freshdesk.com) may already have shared authentication configured. Ask your provider. For cold email, owned domains are always better.

What happens if my sending tool doesn't support DKIM?

Don't use that tool. In 2026, any legitimate email sending platform supports DKIM. Tools that don't are either scams or legacy systems that will fail in the current deliverability environment.

---

ColdRelay handles SPF, DKIM, and DMARC automatically for every domain you add — guided setup with DNS records pre-generated, validation built-in, and alerts if anything breaks. So you get the authentication foundation right on day one, without the DNS debugging.