SPF, DKIM & DMARC for Cold Email: A Plain-English Setup Guide

Quick answer: SPF, DKIM, and DMARC are three DNS records that prove your email is legitimate. SPF lists which servers are allowed to send for your domain; DKIM cryptographically signs each message so it can't be tampered with; DMARC ties the two together and tells providers what to do if a message fails. Cold email needs all three passing — since 2024, Google and Yahoo effectively require them. Set them up in order: SPF, then DKIM, then DMARC.

These three acronyms scare people off, but the concepts are simple, and you only set them up once per domain. Get them right and you clear the single biggest deliverability hurdle. Get them wrong — or skip them — and no amount of clever copy will save you. Here's each one in plain English.

SPF — who's allowed to send for you

SPF (Sender Policy Framework) is a public list, published in your DNS, of the mail servers authorized to send email using your domain. When a provider receives your message, it checks whether the sending server is on that list. If it is, SPF passes; if not, the message looks like it could be spoofed.

In practice, SPF is a single TXT record. Your email provider (Google Workspace, Microsoft 365, Resend, etc.) gives you the exact value to publish. The most common mistakes: having more than one SPF record (you're only allowed one — merge them), or forgetting to include every service that sends on your behalf.

DKIM — proof the message wasn't tampered with

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every email you send. Your sending server signs the message with a private key; the matching public key lives in your DNS. The receiving provider uses the public key to verify the signature, confirming both that the message genuinely came from your domain and that nobody altered it in transit.

DKIM is also a DNS record (or two), and again your provider generates the keys and tells you what to publish. Once set, it works silently on every message. It's the strongest of the three signals because it's cryptographic — it can't be faked the way a 'From' address can.

DMARC — the policy that ties it together

DMARC (Domain-based Message Authentication, Reporting and Conformance) is the instruction layer. It tells receiving providers: 'If a message claiming to be from my domain fails SPF and DKIM, here's what to do' — do nothing (monitor), send it to spam (quarantine), or reject it outright. It also lets you receive reports on who's sending using your domain, which surfaces both misconfigurations and spoofing attempts.

Start DMARC in monitor mode (a policy of 'none') so you can watch the reports without risking legitimate mail, then tighten to quarantine once you've confirmed SPF and DKIM pass reliably. Jumping straight to 'reject' before everything is verified is how people accidentally block their own email.

Order matters: set up SPF first, then DKIM, confirm both PASS on a test email, then add DMARC in monitor mode. Tighten DMARC only after you've verified the first two are solid. Doing it out of order is how legitimate mail gets blocked.

How to set them up, step by step

1. Log in to your DNS provider (where your domain is registered or where its DNS is managed).
2. Get the exact SPF, DKIM, and DMARC values from your email sending service — every provider documents these.
3. Publish the SPF TXT record (only one, merged if you use multiple senders).
4. Publish the DKIM record(s) your provider generates.
5. Send a test email to a Gmail account, open 'Show original,' and confirm SPF and DKIM both PASS.
6. Add a DMARC record with policy 'none' (monitor) and an email address to receive reports.
7. After a week or two of clean reports, tighten DMARC to 'quarantine.'

Why this is non-negotiable now

This used to be a best practice. As of 2024 it's effectively a requirement: Google and Yahoo's sender guidelines expect SPF, DKIM, and DMARC for senders at volume, alongside one-click unsubscribe and a low complaint rate. Senders without proper authentication saw deliverability fall off a cliff. If you do nothing else for your cold email program, do this.

The managed alternative

If DNS records make your eyes glaze over, that's normal — and it's exactly why managed-domain platforms handle this for you. JYNI provisions cold-outreach domains with SPF, DKIM, and DMARC already configured and verified, so the authentication layer is done correctly from day one and you never have to touch a DNS console. However you get there, the destination is the same: all three records passing before you send a single cold email.

The mistakes that quietly break authentication

Most authentication failures aren't dramatic — they're small misconfigurations that pass unnoticed until deliverability tanks. The usual suspects: publishing two SPF records instead of merging them into one (which invalidates SPF entirely); forgetting to include a sending service you added later, like a new outreach tool or CRM; copying a DKIM key with a line break or missing character so the signature won't verify; or setting DMARC straight to 'reject' before SPF and DKIM reliably pass, which silently blocks your own mail. The fix for all of them is the same discipline: change one record at a time, send a test to Gmail, and confirm 'Show original' still shows all three passing before moving on. Re-test whenever you add a new tool that sends on your behalf, because each new sender has to be accounted for in SPF and ideally signed with DKIM.

Authentication is the foundation everything else sits on — warmup, volume, content. Get SPF, DKIM, and DMARC passing first, and every other deliverability effort you make will actually have a chance to work.