SPF, DKIM, DMARC for Cold Email: Step-by-Step Setup Guide

If your DNS records are wrong, nothing else matters. Your subject lines, your copy, your offer, your targeting. All of it is irrelevant if the receiving server cannot verify that you are who you claim to be. The email goes to spam, or it gets rejected outright, and you never know it happened.

I have been running cold email since 2016 and founded Alchemail in 2022. We manage authentication across hundreds of sending domains and have generated over $55M in pipeline for our clients. The single most common root cause when a new client comes to us with deliverability problems is not bad copy or poor lists. It is misconfigured DNS records.

This guide covers SPF, DKIM, and DMARC setup with exact DNS records, provider-specific instructions, and practitioner-level detail. If you are building cold email infrastructure from scratch, start with our infrastructure setup guide. For a broader view of deliverability, see our deliverability guide.

What SPF, DKIM, and DMARC Actually Do

Email authentication via DNS is relatively new. SPF was formalized around 2014, DKIM around 2010, and DMARC around 2015. Before these protocols existed, any server could send email claiming to be from any domain with no verification. These three standards changed that.

SPF (Sender Policy Framework) tells the world which servers are allowed to send email on behalf of your domain. When a receiving server gets an email from you@yourdomain.com, it checks a DNS record to see if the sending server is on the approved list. If not, the email fails SPF.

DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to every outgoing email. Your sending server signs each message with a private key. The receiving server looks up your public key in DNS and verifies the email was not tampered with in transit.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) ties SPF and DKIM together. It specifies which authentication method your domain uses, tells the receiving server what to do if verification fails (nothing, quarantine, or reject), and designates an address where reports should be sent.

SPF says who is allowed to send. DKIM proves the message is authentic. DMARC tells the receiving server what to do with the results and sends you a report card.

SPF Setup

What the Record Looks Like

An SPF record is a DNS TXT record published at the root of your domain. It lists every server authorized to send email on your behalf. Here is a basic example for Google Workspace:

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

Breaking this down:

• v=spf1 declares this is an SPF record
• include:_spf.google.com authorizes Google's mail servers to send for your domain
• ~all is the policy for everyone else. The tilde means softfail: unauthorized servers are flagged but not outright rejected

For Microsoft 365, the record uses a different include:

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

If you send through multiple services, you combine them into a single record. For example, Google Workspace plus a sending tool that uses SendGrid:

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

How to Add It to Your DNS

1. Log into your DNS provider (Cloudflare, Namecheap, Route53, GoDaddy, etc.).
2. Navigate to DNS management for your domain.
3. Add a TXT record with @ as the host and your SPF string as the value.
4. Set TTL to 3600 (or your provider's default).

One critical rule: you can only have one SPF TXT record per domain. If you create a second SPF record instead of combining includes into one, both are invalidated and SPF fails for all email. This is the most common SPF mistake we see.

The 10-Lookup Limit

SPF has a hard limit of 10 DNS lookups per record. Every include: counts as at least one lookup, and nested includes count toward the total:

• include:_spf.google.com triggers 3 lookups (Google nests additional includes)
• include:spf.protection.outlook.com triggers 2 lookups
• include:sendgrid.net triggers 1 lookup
• include:servers.mcsv.net (Mailchimp) triggers 1 lookup
• include:_spf.salesforce.com triggers 2 lookups

Four services and you are at 7-9 lookups. Exceed 10 and SPF returns a permerror, failing silently. You may not notice for weeks.

Solutions:

• SPF flattening. Tools like AutoSPF or dmarcly convert include: directives into hardcoded IP addresses, which do not count as lookups. Good flattening tools auto-update when providers change their IP ranges.
• Subdomains. Each subdomain gets its own SPF record with its own 10-lookup budget. Route cold email through outreach.yourdomain.com and transactional email through mail.yourdomain.com.
• Consolidate services. If you only use a third-party sender for a single campaign, route through your primary provider instead.

Common SPF Includes Reference

Provider	SPF Include
Google Workspace	include:_spf.google.com
Microsoft 365	include:spf.protection.outlook.com
SendGrid	include:sendgrid.net
Mailchimp	include:servers.mcsv.net
Salesforce	include:_spf.salesforce.com
Amazon SES	include:amazonses.com
Zoho	include:zoho.com

Testing Your SPF Record

Go to MXToolbox SPF Checker and enter your domain. Confirm that exactly one SPF record exists, all sending services are included, total DNS lookups are 10 or fewer, and the record ends with ~all or -all.

For cold email, ~all (softfail) is the standard recommendation. It flags unauthorized senders without outright rejecting messages if you forgot to include a legitimate source. Some practitioners prefer -all (hardfail), but this leaves no margin for error.

DKIM Setup

How DKIM Signing Works

DKIM uses public-key cryptography. Your email provider generates a key pair: a private key (kept on the sending server) and a public key (published in DNS). When you send an email, the server signs the message headers and body with the private key. The receiving server looks up the public key via DNS, verifies the signature, and confirms two things: the email came from an authorized server and was not modified in transit.

SPF verifies the sending server. DKIM verifies the message itself.

Setup for Google Workspace

1. Log into the Google Admin Console.
2. Navigate to Apps > Google Workspace > Gmail.
3. Click Authenticate email.
4. Select your domain.
5. Click Generate new record.
6. Select 2048-bit key length. This is critical. Google may default to 1024-bit, which is weaker and increasingly flagged by receiving servers. Always choose 2048.
7. Leave the selector prefix as google (default) or change it if needed.
8. Google displays a TXT record value. Copy the full value.
9. In your DNS provider, add a TXT record:

Field	Value
Type	TXT
Name/Host	google._domainkey
Value	The full key value from the Admin Console
TTL	3600

10. Wait 24-48 hours for DNS propagation.
11. Return to the Google Admin Console and click Start authentication.

Google-specific note: Do not click "Start authentication" before DNS has propagated. If the public key is not yet available, activation fails silently and you will need to retry. Give it a full 24 hours to be safe.

Setup for Microsoft 365

Microsoft uses CNAME records that point to their key servers instead of TXT records with the actual public key. This allows Microsoft to rotate DKIM keys automatically without requiring DNS updates.

1. Go to the Microsoft 365 Defender portal.
2. Navigate to Email & collaboration > Policies & rules > Threat policies > Email authentication settings > DKIM.
3. Select your domain.
4. Microsoft displays two CNAME records to add to your DNS:

Field	Value
Type	CNAME
Name/Host	selector1._domainkey
Value	selector1-yourdomain-com._domainkey.yourdomain.onmicrosoft.com

Field	Value
Type	CNAME
Name/Host	selector2._domainkey
Value	selector2-yourdomain-com._domainkey.yourdomain.onmicrosoft.com

5. Add both CNAME records in your DNS provider.
6. Wait for DNS propagation (up to 48 hours).
7. Return to the Defender portal and toggle Sign messages for this domain with DKIM signatures to enabled.

Microsoft-specific note: DKIM is not enabled by default in Microsoft 365. You must manually enable it after adding the CNAME records. The auto-rotation of keys is a significant advantage over Google Workspace, where rotation is manual.

Verifying DKIM Is Working

1. Send a test email from your domain to a Gmail address.
2. Open the email in Gmail and click the three dots menu, then Show original.
3. Look for: dkim=pass header.d=yourdomain.com.
4. If it shows dkim=fail, verify that your DNS record matches exactly what your provider generated and that enough time has passed for propagation.

You can also use MXToolbox DKIM Lookup. Enter your domain and selector (google for Google Workspace, selector1 for Microsoft 365).

DMARC Setup

Start with p=none (Monitor Mode)

DMARC is published as a TXT record at _dmarc.yourdomain.com. The simplest starting configuration:

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

This tells receiving servers: check SPF and DKIM alignment, do not take any enforcement action on failures, and send aggregate reports to the specified email address.

Always start with p=none. This is monitor mode. It lets you collect data on who is sending email on behalf of your domain and whether authentication is passing or failing, without risking the delivery of legitimate email. Replace dmarc-reports@yourdomain.com with an address you control.

Add this record in your DNS provider:

Field	Value
Type	TXT
Name/Host	_dmarc
Value	v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com
TTL	3600

Progress to Quarantine and Reject

After 2-4 weeks of monitoring with clean reports (all legitimate sources passing authentication), tighten the policy:

Phase 2: Quarantine

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

This sends emails that fail authentication to the spam folder instead of letting them through.

Phase 3: Reject

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

This rejects emails that fail authentication entirely. They are never delivered.

For most cold email operations, p=quarantine is the practical long-term setting. Move to p=reject only once you are certain every legitimate source is authenticated. A forgotten sending source under a reject policy means silently dropped email you will never know about.

Setting Up Aggregate Reports (rua)

The rua tag specifies where aggregate reports are sent. Reports arrive as XML files that are not human-readable in raw form, so use a parsing tool:

• Postmark DMARC: Free weekly digest. Excellent for getting started.
• DMARCian: Comprehensive monitoring and reporting.
• DMARC Analyzer: Detailed forensic and aggregate analysis.

These tools show which IPs are sending on behalf of your domain, whether they pass SPF and DKIM, and which sources are failing.

Reading DMARC Reports

Aggregate reports tell you three things: who is sending as your domain (every IP that sent email claiming to be from your domain), authentication results per source (SPF pass/fail, DKIM pass/fail, alignment status), and volume per source.

Review reports weekly when you first enable DMARC. Look for legitimate sending sources that are failing alignment (fix these before tightening your policy) and unauthorized sources that may be spoofing your domain.

Common Alignment Issues

DMARC does not just check whether SPF or DKIM passed. It checks alignment: the authenticated domain must match the From header domain. SPF can pass for sendingtool.com and DKIM can pass for sendingtool.com, but if the From header says yourdomain.com, neither is aligned and DMARC fails. This is the most misunderstood aspect of DMARC.

The fix: ensure at least one of SPF or DKIM authenticates using your domain. If your sending tool connects to Google Workspace via OAuth or SMTP and Google signs the DKIM, alignment passes because Google signs with d=yourdomain.com. If the tool signs with its own domain, alignment fails.

Managing DNS Across 100+ Domains

Why Automation Matters at Scale

Setting up SPF, DKIM, and DMARC takes about 15 minutes per domain manually. At 5 domains, that is manageable. At 100+, manual setup is a liability. Human error at scale means misconfigured records that silently break authentication on domains you thought were ready. For a breakdown of how many domains you need, see our domain planning guide.

Vendor-Handled DNS

Domain resellers like Zapmail, Lunatro, and Alphoric handle DNS setup automatically. When you purchase domains through them, SPF, DKIM, and DMARC records are configured without manual intervention. The tradeoff is less control over custom configurations, but for standard cold email infrastructure where each domain sends through a single provider, the automation eliminates an entire category of setup errors.

Bulk DNS Management with Cloudflare API

If you manage your own DNS, Cloudflare's API is the most common tool for bulk record management. The workflow: register domains, point nameservers to Cloudflare, then use the API to programmatically add TXT and CNAME records across all domains. Run verification scripts to check each domain's records against expected values.

This scales well but requires development time upfront and ongoing maintenance when you add sending services, update DMARC policies, or rotate keys.

Verification Checklist for Each New Domain

Whether you set up DNS manually, through a vendor, or via API, verify every domain before sending:

1. SPF record exists and includes all sending services
2. SPF lookup count is 10 or fewer
3. DKIM record exists for each email provider on the domain
4. DKIM key length is 2048-bit
5. DMARC record exists at _dmarc.yourdomain.com
6. DMARC rua address is configured
7. MX records are correct for the email provider
8. Test email from the domain shows spf=pass, dkim=pass, dmarc=pass in headers

Do not skip the test email. DNS records can be syntactically correct and still fail in practice due to propagation delays, copy-paste errors, or provider-specific formatting requirements.

Troubleshooting Common Issues

SPF Exceeding 10 Lookups

Symptom: SPF returns permerror in email headers. MXToolbox shows more than 10 DNS lookups.

Fix: Flatten your SPF record using AutoSPF or a similar tool, consolidate sending services, or split sending across subdomains. Each subdomain gets its own 10-lookup budget.

DKIM Alignment Failures

Symptom: DKIM shows pass in email headers but DMARC still fails. The dkim=pass line shows header.d=sendingtool.com instead of header.d=yourdomain.com.

Fix: Your sending tool is signing with its own DKIM key instead of yours. Configure the tool to send through your email provider (via SMTP or OAuth) so your provider signs the message. If the tool must sign with its own key, add the tool's DKIM selector to your DNS and ensure the d= value matches your domain.

Domains Showing as "Unauthenticated"

Symptom: Gmail shows a red question mark next to the sender name. Email headers show authentication failures.

Fix: Check all three records (SPF, DKIM, DMARC) with MXToolbox. The most common causes are a missing DKIM record (you added SPF and DMARC but forgot to enable DKIM signing), an SPF record with the wrong include, or DNS records that have not finished propagating.

Hard Bounces After Moving Domains Between Providers

Symptom: A domain previously on Google Workspace is disconnected and reconnected to Microsoft 365 (or vice versa). Emails to Gmail inboxes start hard bouncing.

Fix: When you move a domain between providers, old DNS records (MX, SPF includes, DKIM selectors) from the previous provider must be completely removed before adding the new provider's records. Stale MX records cause routing failures. Stale SPF includes authorize wrong servers. Stale DKIM selectors reference nonexistent keys. Verify that every DNS record belongs to the current provider, remove anything from the previous one, then wait 24-48 hours for propagation before sending.

Using MXToolbox for Diagnostics

MXToolbox is the single most useful diagnostic tool. It validates SPF syntax and lookup counts, verifies DKIM public keys, confirms DMARC formatting, and has an email header analyzer that breaks down authentication results step by step. When something is not working, MXToolbox is the first place to look.

Testing Your Setup

Send Test Emails Before Going Live

Never launch a campaign on untested infrastructure. Send test emails from every inbox on every domain to at least two different providers (Gmail and Outlook at minimum). This catches authentication problems before they affect real prospects.

Check Email Headers for Authentication Results

In Gmail, open a test email and click the three dots menu, then Show original. Look for these three lines in the authentication results:

spf=pass
dkim=pass
dmarc=pass

All three must show pass. If any shows fail, softfail, or none, go back to the corresponding section of this guide and fix the record before proceeding.

Use mail-tester.com for Quick Scoring

mail-tester.com provides a temporary email address. Send a message to it, then check the results page. It scores your email on authentication, content, and blacklist status. A score of 9/10 or above means your authentication is clean. Anything below 7 indicates a problem that needs to be fixed.

Monitor Inbox Placement in the First Week

After launching, track bounce rates, reply rates, and open rates across domains. A sudden spike in bounces or a drop in opens often indicates an authentication issue that did not surface in testing. Catching problems in the first week prevents weeks of wasted volume on broken infrastructure.

Conclusion

DNS authentication takes 15 minutes per domain to set up correctly. Skipping it costs you months of deliverability. Every email that fails authentication never had a chance to be read.

SPF declares your authorized senders. DKIM proves your messages are authentic. DMARC ties them together and gives you reporting. Configure all three, verify with MXToolbox and test emails, and you have a foundation that supports everything you build on top of it.

If you are building or scaling cold email infrastructure, our infrastructure setup guide covers the full stack from domains to sending tools. For the strategic view of deliverability beyond DNS, see our complete deliverability guide.

Get the DNS right first. Everything else follows.