How to set up SPF, DKIM and DMARC for cold email

Authentication is the cheapest part of cold email and the most common reason it fails. Setup takes about twenty minutes per domain. But when you run 10 or 30 sending domains, one typo, a duplicate SPF record or a DKIM key that was never activated will quietly send a whole domain to spam. Nobody notices until replies stop.

Gmail, Yahoo and Microsoft now require all three records from bulk senders (see the 2026 sender rules). Here is the setup for each record, with real values for both major inbox providers.

What each record actually does

SPF: one record, under 10 lookups

Google Workspace (Google):

Type: TXT   Host: @
v=spf1 include:_spf.google.com ~all

Microsoft 365 (Microsoft Learn):

Type: TXT   Host: @
v=spf1 include:spf.protection.outlook.com -all

Google recommends ~all (soft fail). Microsoft recommends -all (hard fail) because DMARC acts on the result. Either works for cold email if DKIM and DMARC are correct. Follow your provider's advice.

Two rules break more domains than anything else:

1. One SPF record per domain. RFC 7208 says a domain "MUST NOT have multiple records," and receivers return permerror if they find two. If your sending tool tells you to "add an SPF record," add its include: to your existing record instead.
2. No more than 10 DNS lookups. Each include, a, mx, exists and redirect counts, and so do the includes nested inside them. Go over 10 and SPF fails with permerror (Microsoft). ip4: and ip6: don't count.

Combined example, Workspace plus one other sender:

v=spf1 include:_spf.google.com include:servers.example-sender.com ~all

Cold email domains should be boring: one inbox provider, maybe one other tool, and nothing else. If you're near 10 lookups on a sending domain, something on it doesn't belong there.

DKIM: 2048-bit keys, actually switched on

Google Workspace. In the Admin console go to Apps > Google Workspace > Gmail > Authenticate email. Generate a record with the 2048-bit key length and the default selector prefix google, publish it, then click Start authentication (Google). The record looks like this:

Type: TXT   Host: google._domainkey
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...

Google says DKIM can take up to 48 hours to start working after you add the key. On a brand-new Workspace you may have to wait 24 to 72 hours before you can generate the key at all.

Microsoft 365. You publish two CNAMEs, then enable signing in the Defender portal or with PowerShell. The current format for custom domains is (Microsoft Learn):

Type: CNAME   Host: selector1._domainkey
selector1-yourdomain-com._domainkey.yourtenant.n-v1.dkim.mail.microsoft

Type: CNAME   Host: selector2._domainkey
selector2-yourdomain-com._domainkey.yourtenant.n-v1.dkim.mail.microsoft

The partition letter (n in this example) varies, and older domains may show ...yourtenant.onmicrosoft.com targets instead. Copy the exact values the Defender portal shows you, not the ones above. Microsoft's default key size is 1024 bits. To move to 2048, run Rotate-DkimSigningConfig -Identity yourdomain.com -KeySize 2048. The new size applies to the next selector that becomes active.

Why 2048? Google requires at least 1024 bits and recommends 2048 where your DNS host supports it (Google). There's no reason to use less.

DMARC: set p=none first, then tighten

Google's recommended rollout (Google) is to set up SPF and DKIM at least 48 hours before DMARC, then start in monitor mode:

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

rua is where receivers send daily aggregate reports. Use a mailbox you actually read, or a DMARC report service. After about a week of clean reports, meaning every legitimate source passes with alignment, tighten the policy:

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

A note on the pct tag: Google's guide suggests ramping up with something like pct=5. DMARC's updated standard, RFC 9989 (May 2026), removed pct and added a t= test-mode flag in its place. Receivers ignore tags they don't recognize, so pct is now unreliable. For a small sending domain with one or two sources, go straight from none to quarantine once reports are clean.

Is p=reject worth it? Not on cold email domains. Gmail, Yahoo and Microsoft all accept p=none for compliance, and quarantine already protects you from spoofing. Your primary brand domain is a different story.

Alignment, explained simply

DMARC passes only if SPF or DKIM passes for the same domain your prospect sees in the From line.

• SPF alignment: the Return-Path domain matches the From domain. Inbox providers usually handle this for mail sent through their own servers.
• DKIM alignment: the d= domain in the DKIM signature matches the From domain. This is why you sign with your own domain's key and not your provider's default.

"Relaxed" alignment, which is the default and which Yahoo explicitly accepts, means subdomains count. mail.yourdomain.com aligns with yourdomain.com.

Use a custom tracking domain

If you track opens or clicks, your sending tool rewrites links through a tracking host. On a shared default host, your links sit next to every other customer's links, including the bad ones. Filters look at link domains, so their reputation becomes yours.

A custom tracking domain fixes that. It's a CNAME on a subdomain of your sending domain that points to your tool's tracking host:

Type: CNAME   Host: track
track.yourdomain.com -> the hostname your sending tool gives you

Your links then use your own domain, which also aligns with the From address. Many operators turn off open tracking completely on cold campaigns, and clicks matter more than opens anyway. If you track, use your own domain.

How to verify everything works

Start by querying DNS directly. You should see exactly one v=spf1 line, your DKIM key or CNAME, and one v=DMARC1 line:

dig TXT yourdomain.com +short
dig TXT google._domainkey.yourdomain.com +short
dig CNAME selector1._domainkey.yourdomain.com +short
dig TXT _dmarc.yourdomain.com +short

Then:

1. Send a test to a Gmail account and open Show original. You want SPF: PASS, DKIM: PASS and DMARC: PASS, with the DKIM domain matching your From domain.
2. Read your first DMARC reports after 24 to 48 hours and confirm that no unknown sources are sending as you.
3. Recheck monthly. DNS changes, expired keys and new tools added to SPF are how domains that once worked start failing.

Zylar checks SPF, DKIM, DMARC, the custom tracking domain and MX the moment you connect a domain. It tells you exactly what to fix and gives you the record to paste. Until then, use the free checker:

Free SPF / DKIM / DMARC checkerCheck any domain in seconds. No signup.Check now

Once the records pass, the next steps are warm-up and the rest of the infrastructure checklist. More tools are on our free tools page.

FAQ

Can I have two SPF records if I use two sending tools?

No. Two SPF records cause a permerror, and SPF fails for every message. Merge them into one record with both include: mechanisms, and keep the total under 10 DNS lookups.

Should I use ~all or -all for cold email?

Either works when DKIM and DMARC are set up correctly. Google recommends ~all for Workspace and Microsoft recommends -all for Microsoft 365. Use what your inbox provider documents.

Do I need DMARC if I send under 5,000 emails a day?

Gmail and Yahoo only strictly require DMARC from bulk senders, but Gmail counts volume across your whole primary domain, and DMARC reports are the only way to see who is sending as you. Publish it on every sending domain.

Is 1024-bit DKIM still acceptable?

Google accepts 1024 bits as the minimum and recommends 2048 where your DNS host supports it. Microsoft 365 defaults to 1024, so rotate to 2048 after you enable signing.

How long until new records take effect?

DNS changes often show up within minutes, but Google says SPF and DKIM can take up to 48 hours to start working. Wait for passing results in a test message before you start warm-up.

Does the custom tracking domain need its own SPF or DKIM?

No. It's just a CNAME used for links, not for sending mail. It needs to resolve and serve HTTPS through your sending tool.