DMARC, SPF, DKIM explained: the cold email setup that nobody understands

Email authentication is the most tedious and most important part of cold email infrastructure. Get it wrong by a single character and Gmail filters everything to spam, silently. Get it right and you've built the foundation that all your future deliverability rests on.

This post is the technical guide to SPF, DKIM, and DMARC for cold email senders. Written for founders and operators who need to understand what these records do and how to set them up properly.

The 30-second summary

Email authentication is a chain of three DNS records that prove you're allowed to send email from your domain. Without them, modern inbox providers (Gmail, Outlook, Yahoo) treat your email as suspicious and either filter it to spam or reject it entirely.

• SPF says "these IP addresses are allowed to send email on behalf of my domain"
• DKIM cryptographically signs outgoing emails to prove they came from you and weren't tampered with
• DMARC tells receiving servers what to do when SPF or DKIM checks fail

All three are required as of Gmail's February 2024 enforcement update. Skipping any of them means your emails will get filtered.

SPF: the IP whitelist

SPF (Sender Policy Framework) is a TXT DNS record that lists which servers are authorized to send email for your domain. When a receiving server gets an email claiming to come from [email protected], it checks the SPF record at knkoutbound.com to see if the sending IP is on the approved list.

What an SPF record looks like

A typical SPF record for a cold email setup using Google Workspace + Instantly:

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

Breaking it down:

• v=spf1: SPF version 1
• include:_spf.google.com: trust Google's mail servers
• include:spf.instantly.ai: trust Instantly's mail servers
• ~all: soft-fail any other senders (use -all for strict, but ~all is safer during initial setup)

The SPF mistakes that break things

1. Multiple SPF records on the same domain: only one SPF record is allowed per domain. If you have two, neither works. Always combine into a single record.
2. Too many include: statements: SPF has a 10-lookup limit. If you stack too many includes, the record breaks silently. Watch this if you're using multiple sending tools.
3. Wrong syntax: a missing space or extra character invalidates the entire record. Always use a tool like MXToolbox to verify after editing.

DKIM: the cryptographic signature

DKIM (DomainKeys Identified Mail) is a public-key cryptography system. Your sending tool signs each email with a private key. The receiving server fetches your public key from your DNS (also a TXT record), verifies the signature, and confirms the email wasn't tampered with in transit.

What DKIM setup looks like

DKIM uses a "selector" — a name that identifies which key to use. A typical setup might create a record at google._domainkey.knkoutbound.com with the public key as the value.

Your sending tool gives you the exact record to add. For Google Workspace:

• Type: TXT
• Name/Host: google._domainkey
• Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqh... (a long string)

For each additional sending tool (Instantly, Smartlead, etc.), you'll add additional DKIM records with different selectors.

The DKIM mistakes that break things

1. Truncating the public key: DKIM values are long. Some DNS providers truncate them to 255 characters. Make sure your full key is preserved.
2. Wrong selector: each sending tool uses a specific selector name. Using the wrong one means the receiving server can't find the key.
3. Activating in your sending tool but not actually adding to DNS: surprisingly common. Your tool says "DKIM enabled," but the DNS record isn't there. Always verify.

DMARC: the policy enforcer

DMARC (Domain-based Message Authentication, Reporting & Conformance) is the policy layer. It tells receiving servers: "If SPF or DKIM checks fail for emails claiming to be from my domain, here's what to do."

What a DMARC record looks like

A typical DMARC record for a cold email setup:

v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]; pct=100; sp=none; aspf=r;

The critical part is p= — the policy. Three options:

• p=none: monitor only, don't enforce. Safe for initial setup. Receive reports but don't reject any email.
• p=quarantine: emails that fail authentication go to spam folder. Reasonable next step after monitoring.
• p=reject: emails that fail authentication are rejected entirely. Maximum security. Risky if your authentication isn't 100% clean.

The DMARC progression

The right way to deploy DMARC:

1. Week 1-4: Deploy with p=none. Receive reports. Verify SPF and DKIM are passing for legitimate email.
2. Week 4-8: Move to p=quarantine. Monitor for false positives.
3. Week 8+: Move to p=reject if you're confident in your authentication.

Most senders never move past p=none. That's fine for cold email purposes. The stricter policies matter more for transactional senders trying to prevent phishing impersonation.

The Gmail/Yahoo enforcement that changed everything

In February 2024, Google and Yahoo started enforcing strict authentication for any sender doing more than 5,000 emails per day to their users. The rules:

• SPF must be present and pass
• DKIM must be present and pass
• DMARC must be present (even if just p=none)
• Spam complaint rate must stay below 0.3%
• One-click unsubscribe must be present in marketing emails

Senders not meeting these requirements get throttled or filtered to spam at high rates. The 5,000-email threshold sounds high but easy to hit with a multi-mailbox cold email setup.

How to verify your authentication is actually working

Don't trust your sending tool's "authentication enabled" indicator. Verify directly.

Tools for verification

• MXToolbox: free SPF, DKIM, DMARC checker. Run your domain through it.
• Mail-Tester: send a test email and get a detailed authentication and content report.
• Google Postmaster Tools: free Google account that shows you authentication pass rates for emails sent to Gmail addresses. Critical for monitoring at scale.
• GlockApps: paid, but the most comprehensive deliverability testing tool.

The minimum monthly verification

At least once a month, run:

1. MXToolbox SPF/DKIM/DMARC check on each sending domain
2. Mail-Tester on a sample email from each mailbox
3. Review Google Postmaster Tools for authentication pass rate

This 15-minute monthly check catches issues before they cost you weeks of bad delivery.

The DMARC report problem

If you set up rua=mailto:[email protected], you'll start receiving DMARC reports. These are XML files sent by major email providers reporting on emails they received claiming to be from your domain.

The XML is unreadable for humans. Two solutions:

• Free: route DMARC reports to a tool like Postmark's free DMARC monitor or Dmarcian's free tier. They parse and visualize the reports.
• Paid: dedicated DMARC monitoring services like Dmarcian, MxToolbox Pro, or Valimail. Worth it if you're doing high-volume sending.

The setup checklist

Use this when configuring a new sending domain:

1. Buy domain. Don't use your primary domain for cold email.
2. Add SPF record (single record with all needed includes)
3. Generate DKIM keys in Google Workspace, add the TXT record
4. Add DMARC record with p=none initially
5. Wait 24-48 hours for DNS propagation
6. Verify with MXToolbox
7. Send test email to Mail-Tester, verify all three pass
8. Connect domain to Instantly or your sending tool
9. Add tool-specific DKIM record if required
10. Verify again with MXToolbox
11. Begin warmup

Skipping any step leaves authentication broken. Verify after each step before proceeding to the next.

For more on this, see warmup protocol.