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

Every cold email deliverability conversation eventually lands on the same three acronyms. SPF, DKIM, DMARC. Most guides explain them like you're building an email service provider from scratch. You're not. You're trying to send 50 emails a day from a domain you bought six weeks ago, and you want to know exactly which DNS records to add and how to confirm they work.

That's what this is. No RFC quotes, no diagrams of the SMTP handshake. Just what each record does, how to set it up on the mailbox providers you're actually using, and the specific ways people break these without noticing.

First, the honest framing: authentication does not get you into the inbox. It gets you *eligible* for the inbox. Gmail and Microsoft will happily send a perfectly authenticated email to spam if the content is bad, the domain has no reputation, or you're blasting 400 messages a day from a mailbox that was created last Tuesday. Authentication is the price of admission, not the show. But without it, since the February 2024 bulk sender rules from Google and Yahoo — and Microsoft's own tightening in 2025 — you're not getting through the door at all.

What each record actually does

Think of it as three separate questions a receiving mail server asks about your message.

SPF answers: is this server allowed to send for this domain? You publish a list of IP addresses and services permitted to send mail using your domain in the envelope sender. The receiver checks the connecting IP against that list. Pass or fail.

DKIM answers: was this message tampered with, and does the domain vouch for it? Your sending server signs the message with a private key. You publish the matching public key in DNS. The receiver verifies the signature. If it validates, the domain owner cryptographically stands behind that message.

DMARC answers: what should I do when SPF and DKIM disagree with the From address? This is the part people miss. SPF and DKIM check domains that the recipient never sees. DMARC ties them to the visible From header — that's called alignment — and tells the receiver what to do on failure: nothing, quarantine, or reject. It also gives you reports so you can see who's sending as you.

You need all three. Two out of three is a fail in 2026.

Setting up SPF

SPF is a single TXT record on your root domain. It looks like this:

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

That's it for a Google Workspace domain. For Microsoft 365 it's include:spf.protection.outlook.com. If you send through a third-party SMTP provider too, you add their include mechanism alongside.

Four rules that matter:

• One SPF record per domain. Two TXT records starting with v=spf1 is a permanent error and everything fails. If you're adding a service, merge the include into the existing record — never publish a second one.
• Stay under 10 DNS lookups. Every include: costs at least one lookup, and includes can nest. Blow past ten and you get a permerror, which most receivers treat as a fail. If you have five or six services stacked in there, you have a problem.
• Use ~all (softfail) or -all (hardfail), never +all. ~all is the safe default while you're setting things up. -all is stricter and slightly better for reputation once you're confident the record is complete.
• SPF breaks on forwarding. When someone auto-forwards your email, the connecting IP changes and SPF fails. This is exactly why DKIM and DMARC exist — DKIM survives forwarding, SPF doesn't.

Note that SPF checks the Return-Path domain, not the From address you see in the client. For cold email this usually aligns automatically because you're sending from your own mailbox on your own domain. It only gets weird when a platform rewrites the Return-Path to its own domain — which is one reason Sendvanta sends through your mailboxes directly rather than proxying through shared infrastructure.

Setting up DKIM

DKIM is where most people stall, because it's not on by default everywhere.

Google Workspace: Admin console → Apps → Google Workspace → Gmail → Authenticate email. Generate a new record (choose 2048-bit if offered), copy the TXT record it gives you, add it to DNS at the selector host it specifies — usually google._domainkey — wait for propagation, then come back and click Start Authentication. That last click is the step everyone forgets. Publishing the DNS record alone does nothing until you turn signing on in the admin console.

Microsoft 365: Defender portal → Email & collaboration → Policies & rules → Threat policies → Email authentication settings → DKIM. You'll be told to publish two CNAME records (selector1 and selector2) pointing at Microsoft's key hosts. Publish both, then flip the toggle to enable signing for the domain. Microsoft rotates keys behind those CNAMEs, which is why they're CNAMEs and not TXT records.

Custom SMTP/IMAP: your provider gives you a selector and a public key. Publish it as a TXT record at selector._domainkey.yourdomain.com. Enable signing on the server side.

To verify: send yourself a message at a Gmail address, open it, click the three dots, and choose "Show original." You want to see SPF: PASS, DKIM: PASS, DMARC: PASS. If DKIM says "neutral" or is missing entirely, signing isn't actually enabled.

Setting up DMARC

DMARC is a TXT record at _dmarc.yourdomain.com. Start here:

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

p=none means "don't change anything, just send me reports." It satisfies the Google and Yahoo bulk sender requirement and it gives you visibility without risking legitimate mail. Leave it there for two to four weeks and read the aggregate reports. They're XML, so use a free parser or a reporting service unless you enjoy pain.

Once the reports show your legitimate mail passing consistently, move to p=quarantine, and later p=reject if you want the strongest protection against spoofing. Cold senders on a dedicated outbound domain can usually go to p=reject fairly quickly, because there's only one sending source to account for.

Two settings worth knowing:

• pct= lets you roll out gradually — p=quarantine; pct=25 applies the policy to a quarter of failing mail. Useful on a domain with lots of sending sources.
• aspf= and adkim= control alignment strictness. Default is relaxed (r), which allows subdomains to align with the root domain. Strict (s) requires an exact match. Relaxed is right for almost everyone.

Also add a BIMI-adjacent nicety while you're in there: nothing required, but p=quarantine or stricter is a prerequisite if you ever want your logo showing in Gmail.

The five mistakes that quietly break all of this

These are the ones that show up over and over in audits.

• Two SPF records. Usually because someone added a new tool and pasted a second record instead of merging. Instant permanent failure.
• DKIM published but not enabled. The DNS record is there, the admin toggle isn't flipped. Header check says "dkim=none."
• Testing on the wrong domain. You set up records on yourcompany.com but you're sending from get-yourcompany.com. Check the records on the exact domain in your From address.
• DMARC with no alignment. SPF and DKIM both pass, but against a different domain than the From header, so DMARC fails anyway. This happens when a sending platform uses its own Return-Path and its own DKIM signing domain.
• Forgetting the sending domain entirely. People set up authentication on their primary domain, then buy three lookalike domains for outbound and configure none of them. Every new sending domain needs its own full set.

Order of operations for a new sending domain

If you're standing up a fresh outbound domain this week:

• Day 1: buy the domain, set up mailboxes, publish SPF, DKIM, and DMARC at p=none. Add an MX record even if you don't read the inbox — no MX is a spam signal.
• Day 1: send a test to a Gmail address and confirm all three pass in Show original.
• Days 2–21: warm up. Authentication is table stakes; reputation takes weeks. See how long to warm up a new email account for realistic timelines.
• Week 3–4: read your first DMARC aggregate reports. Confirm nothing unexpected is sending as you.
• Week 4+: begin real sending at conservative volume, and tighten DMARC to quarantine once reports are clean.

If your emails are still landing in spam with all three passing, the problem is elsewhere — volume, content, list quality, or domain age. We covered the full list in why cold emails go to spam.

Where Sendvanta fits

Sendvanta sends through your own Gmail, Microsoft 365, or SMTP mailboxes, so your existing SPF and DKIM setup applies directly — no shared IPs, no rewritten Return-Path, no alignment surprises. The deliverability health score checks authentication at the mailbox, domain, DKIM, and IP layer continuously, and slows or pauses sending automatically when something drifts out of spec, including a DKIM key that stopped signing after a provider change.

Paid plans can also register a sending domain for a one-time $20 with records configured correctly from the start, and add managed mailboxes at $4/mo each. Connecting your own mailboxes is free on every plan, including the free tier — $0 forever, 1,000 active leads, 3,000 emails a month, up to 10 of your own SMTP mailboxes. Plenty to validate a domain setup before you commit to anything. More on how the health scoring works on the features page.

Get these three records right once per domain and they'll keep working for years. Get one of them wrong and you'll spend three months blaming your subject lines.