SPF, DKIM, DMARC Setup for Cold Email

SPF, DKIM, and DMARC setup for cold email is the part everyone rushes and almost everyone gets subtly wrong. These three DNS records decide whether a receiving server treats your message as a legitimate sender or as an unverified stranger, and since Google and Yahoo made authentication mandatory for bulk senders in February 2024, getting them wrong is no longer a soft penalty. This guide covers exactly what each record does, how to publish it, how to confirm it passes, and the five mistakes that break authentication without ever showing you an error.

We set this up constantly. Our parent agency, Referral Program Pros, has run over 4,000 outbound campaigns and booked more than 7,000 meetings, and correct authentication is part of the setup for every single one of them. It is also why GTM Bud can carry a reply-rate guarantee of 5 percent positive replies on LinkedIn or 1.5 percent on email, with a full refund if we miss it. You cannot promise reply rates on infrastructure you have not verified.

The three records at a glance

Record	What it proves	Where it lives	Example value	How to verify
SPF	Which servers may send mail using your domain	One TXT record at your root domain	v=spf1 include:_spf.google.com ~all	dig txt yourdomain.com +short
DKIM	The message was signed by your domain and not altered	TXT or CNAME at selector._domainkey.yourdomain.com	v=DKIM1; k=rsa; p=MIIBIjANBg...	dig txt google._domainkey.yourdomain.com +short
DMARC	What receivers should do when SPF and DKIM both fail	One TXT record at _dmarc.yourdomain.com	v=DMARC1; p=none; rua=mailto:[email protected]	dig txt _dmarc.yourdomain.com +short

Publish them in that order. SPF and DKIM are the identity proofs. DMARC is the instruction that only becomes meaningful once the first two are working.

What do SPF, DKIM, and DMARC actually do?

SPF, DKIM, and DMARC are three DNS records that together prove a cold email really came from your domain. SPF is a published list of the servers allowed to send mail using your domain name. DKIM is a cryptographic signature added to every outgoing message, checked against a public key you publish in DNS. DMARC is the policy that tells a receiving server what to do when a message fails both checks, and it is the only one of the three that also requires the visible From address to match the domain that passed SPF or DKIM. That last part is called alignment, and it is why a message can pass SPF on paper and still fail DMARC. Receivers run all three checks in milliseconds, before any spam filter looks at your subject line. Fail them and your copy never gets a hearing.

The order matters because each record depends on the one before it. A DMARC policy on a domain with no working DKIM is an instruction to enforce a rule you cannot pass.

Step 1: Publish exactly one SPF record

Your domain gets one SPF record. Not one per service, one total. It is a TXT record on the root domain that starts with v=spf1, lists every source authorized to send on your behalf, and ends with a catch-all mechanism.

For a domain sending through Google Workspace:

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

For Microsoft 365:

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

If you send through more than one service, combine them into a single record rather than publishing a second one:

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

The ending mechanism sets the failure mode. ~all is a soft fail, meaning unauthorized mail is marked suspicious but still accepted. -all is a hard fail, telling receivers to reject anything not on the list. Hard fail is stricter and better once your record is complete, but it punishes you the moment you forget to include a legitimate sender. Start with ~all while you are still adding services, then move to -all once your DMARC reports confirm nothing legitimate is missing.

One constraint governs everything about SPF records: evaluating a single SPF record must not trigger more than 10 DNS lookups, a limit defined in RFC 7208, section 4.6.4. Every include, a, mx, ptr, exists, and redirect mechanism costs a lookup, and the budget is cumulative across nested includes rather than resetting inside each one. Exceed it and receivers return a permanent error, which is functionally the same as having no SPF at all.

Step 2: Enable DKIM in your provider, then publish the key

DKIM is the step people publish and forget to switch on. Your email provider generates the key pair. You publish the public half in DNS. Then you go back into the provider and turn signing on. Skipping that last action leaves you with a valid DNS record and completely unsigned mail.

Google Workspace

Generate the key from the Admin console under the Gmail app settings, where you will find the option to authenticate email. Google defaults to a 2048-bit RSA key with the selector google, which produces a TXT record at google._domainkey.yourdomain.com. Publish that record at your DNS host, wait for it to resolve, then return to the Admin console and choose Start authentication. Until you click that, Google generates the key but does not sign anything with it.

Microsoft 365

Microsoft handles this with two CNAME records instead of one TXT record, so it can rotate keys automatically without asking you to touch DNS again. You publish selector1._domainkey and selector2._domainkey pointing at Microsoft-hosted targets, then open the Defender portal, find the email authentication settings for your custom domain rather than the default onmicrosoft.com entry, and turn on signing for that domain. Publishing one selector and forgetting the second is the classic Microsoft 365 failure, because signing will not enable until both records resolve.

Note that Google and Yahoo both require a DKIM key of at least 1024 bits for mail sent to personal inboxes, per Google’s Gmail sender guidelines. Both major providers now default to 2048-bit keys, so this only bites you if you are reusing an old key from a legacy setup.

Step 3: Start DMARC at p=none, then tighten deliberately

Publish DMARC in monitoring mode first. A DMARC record is a single TXT record at _dmarc.yourdomain.com, and the starting version looks like this:

v=DMARC1; p=none; rua=mailto:[email protected]

The p tag is the policy, and it has exactly three values. p=none takes no action on failing mail but sends you reports, which is why it is the correct starting point. p=quarantine asks receivers to route failing mail to the spam folder. p=reject asks receivers to refuse it outright. The rua tag is where daily aggregate reports get sent, and without it you are enforcing a policy blind. Those three values are the entire decision surface, so anyone selling you a more complicated DMARC strategy is selling reporting, not policy. DMARC itself moved onto the IETF standards track in 2026, when the updated specification known as DMARCbis replaced the original RFC 7489 from 2015, per DMARC monitoring vendors tracking the change. The policy values did not change. What changed is that DMARC is now a Proposed Standard rather than an informational document, and the updated text explicitly discourages p=reject for domains whose mail regularly passes through mailing lists.

For a cold sending domain, the practical sequence is: run p=none for two to four weeks, read the aggregate reports until every legitimate source shows as passing, move to p=quarantine, watch for another two weeks, then go to p=reject. Cold sending domains are strong candidates for p=reject eventually, because they should have exactly one sending source and no mailing-list traffic to break.

How do you verify each record is actually passing?

The fastest check takes 30 seconds. Send a test message from your sending mailbox to a Gmail address you control, open it, click the three-dot menu, and choose Show original. Gmail displays SPF, DKIM, and DMARC on separate lines, each reading PASS or FAIL. That single view confirms all three at once, in production conditions, which no DNS lookup tool can do.

For record-level checks before you send anything, query DNS directly:

dig txt yourdomain.com +short
dig txt google._domainkey.yourdomain.com +short
dig txt _dmarc.yourdomain.com +short

Each should return exactly one relevant record. If the SPF query returns two lines starting with v=spf1, you have already found your problem. Free lookup tools from MXToolbox and the major DMARC vendors do the same job in a browser and will also count your SPF lookups for you, which is worth doing before you assume a long include chain is fine.

The signal that a record is published but not working is a PASS on the DNS lookup and a FAIL in Show original. That gap almost always means DKIM signing was never enabled in the provider, or the From address does not align with the authenticated domain.

The 5 mistakes that silently break authentication

None of these produce an error message. They produce a quiet drop in inbox placement that looks like a copy problem.

1. Two SPF records on one domain. The specification allows exactly one. Publishing a second when you add a new sending service invalidates both, and the receiving server treats the domain as having no SPF policy. Merge every include into one record.

2. Exceeding the 10 DNS lookup limit. Each include in your SPF record can pull in further includes, and the total across the whole evaluation is capped at 10 per RFC 7208. Marketing platforms, help desks, and CRMs each add one or more. The fix is to remove services that no longer send from your domain, or to flatten the record into explicit IP ranges and accept the maintenance burden that comes with it.

3. Publishing the DKIM key without enabling signing. Both Google Workspace and Microsoft 365 require a separate action in the admin interface after the DNS record resolves. The record checks out, the mail goes unsigned, and DMARC fails on every message.

4. Jumping straight to p=reject. Going to enforcement before reading aggregate reports means any sending source you forgot about, including your CRM or invoicing tool, gets refused by receivers. Move through p=none and p=quarantine in sequence.

5. Passing SPF while failing alignment. DMARC requires the visible From domain to match the domain that passed SPF or DKIM. If a sending platform uses its own bounce domain in the Return-Path, SPF passes for that platform’s domain rather than yours, and DMARC fails despite a green SPF check. This is the most common failure for teams using a third-party sender, and the fix is configuring a custom return path or relying on properly aligned DKIM.

What Google, Yahoo, and Microsoft require in 2026

All three major providers now demand the same authentication baseline, and they apply their strictest rules at the same threshold. Google’s Gmail sender guidelines and Yahoo’s Sender Hub define a bulk sender as anyone sending roughly 5,000 or more messages per day to their users, and Microsoft applied the same 5,000-per-day mark when its high-volume sender requirements took effect on May 5, 2025 for consumer domains including Outlook.com and Hotmail.com. Bulk senders must authenticate with SPF and DKIM, publish a DMARC record with a minimum policy of p=none, pass alignment on at least one of SPF or DKIM, and keep the spam complaint rate reported in Google Postmaster Tools below 0.10 percent, never reaching 0.30 percent. Non-compliant mail is increasingly rejected at the SMTP level with a permanent error rather than quietly filtered into a junk folder, which means the sender sees a bounce instead of silence.

Most cold email operations run several mailboxes at modest daily volumes and sit well under the 5,000-per-day bulk threshold, which means the one-click unsubscribe requirement is not strictly mandatory for them. The authentication requirements are a different matter. Providers evaluate SPF, DKIM, and DMARC on every message regardless of your volume, so a small sender with broken authentication gets filtered exactly like a large one. Meeting the bulk-sender bar is the sane default even when the rules technically do not apply to you. If you are choosing tooling around this, our roundup of cold email infrastructure tools covers what handles DNS provisioning for you.

Authentication is the entry ticket, not the whole game. Once your records pass, reputation takes over, which is covered in our cold email deliverability guide and the ramp schedule in our email warmup guide for cold outreach.

Frequently asked questions about SPF, DKIM, and DMARC setup

Do I need SPF, DKIM, and DMARC on every sending domain?

Yes. Authentication is published per domain, so every sending domain needs its own SPF record, its own DKIM key, and its own DMARC record. A record on acme.com does nothing for getacme.com. Teams running cold email across several lookalike domains have to repeat the full setup on each one, which is the most common reason a single domain in a rotation quietly underperforms. A cold email automation tool that provisions domains and records together removes most of that repetition.

How long do SPF, DKIM, and DMARC records take to work after I add them?

Most records resolve within an hour, though DNS changes can take up to 48 hours to fully propagate depending on the TTL your registrar sets. DKIM often feels slower because publishing the key is only half the job. You still have to switch signing on inside your provider, and mail sent before you flip that switch stays unsigned. Wait at least 30 minutes before testing, then confirm with a DNS lookup instead of assuming.

Do subdomains need their own SPF and DMARC records?

A subdomain does not inherit the root domain SPF record, so any subdomain that sends mail needs its own SPF TXT record. DMARC behaves differently: a policy at the root domain applies to subdomains unless you override it with the sp tag or publish a separate DMARC record on the subdomain. If you send cold email from a subdomain, publish SPF there explicitly and set the subdomain policy deliberately.

What is a DMARC aggregate report and do I have to read it?

A DMARC aggregate report is a daily XML file that receiving providers send to the address in your rua tag, listing every IP that sent mail claiming to be your domain and whether it passed SPF, DKIM, and alignment. Raw XML is close to unreadable, so most senders point rua at a DMARC reporting service that renders it as a dashboard. You do not need to read every report, but you do need the summary before tightening your policy.

Do BIMI or MTA-STS matter for cold email?

Not for cold email. BIMI shows your logo next to messages in supporting inboxes and requires DMARC at quarantine or reject first, which mostly benefits marketing mail to people who already recognize you. MTA-STS enforces encrypted delivery between mail servers. Both are reasonable additions to a primary brand domain eventually. Neither moves inbox placement on a cold sending domain.

Will SPF, DKIM, and DMARC alone keep me out of spam?

No. Authentication proves who you are, not that people want your email. Passing all three means your message gets evaluated on its merits rather than refused at the door. Reputation still comes from complaint rate, bounce rate, engagement, and volume. Treat authentication as the entry requirement, and warmup, list hygiene, and targeting as the work that earns the inbox. Agencies running this across multiple client domains can see how we structure it in our guide to cold email for agencies.

Get authenticated once, then go book meetings

SPF, DKIM, and DMARC setup for cold email is a one-afternoon job per domain that pays for itself on every campaign afterward. Publish one SPF record and keep it under the 10-lookup limit. Enable DKIM in your provider and confirm signing is actually on. Start DMARC at p=none, read the reports, and tighten to quarantine and then reject once nothing legitimate is failing. Verify with Show original in Gmail rather than trusting the DNS panel. That is the whole job.

Or skip the DNS homework entirely. GTM Bud sets up authenticated sending domains as part of onboarding, which is how most teams running outbound email for startups get sending without touching a DNS panel. Pricing is a flat monthly rate per connected sending account: $150 per month per email sending account covering 600 sends per month, or $350 per month per LinkedIn account covering up to 1,200 leads contacted per month, with a 7-day trial and no per-lead or per-campaign charges. If you would rather hand off the entire motion, our done-for-you outbound service runs research, copy, and sending on the same playbook our agency used to book those 7,000 meetings.