SPF, DKIM, and DMARC for Cold Email: The Minimum You Must Configure in 2026

For cold email you need three DNS records on every sending domain: one SPF record listing the services allowed to send for you, a DKIM key (2048-bit) so receivers can verify your messages were not altered, and a DMARC record starting at p=none that ties both to the domain in your From address. Since February 2024, Gmail and Yahoo require SPF or DKIM from every sender, and senders of 5,000 or more messages a day must also publish DMARC with alignment. Set up all three anyway: it takes about 20 minutes with DNS access and removes the most common reason cold email lands in spam.

Below: what each record does, the exact values for Google Workspace and Microsoft 365, the alignment rule that trips up senders who use a third-party platform, and how to verify it all.

The minimum setup at a glance

What Gmail and Yahoo require

The February 2024 rules split senders in two. Every sender must authenticate with SPF or DKIM. Senders of 5,000 or more messages a day to Gmail must also publish a DMARC record (p=none is enough), align it with the From domain, offer one-click unsubscribe on marketing mail, and keep the spam rate reported in Postmaster Tools under 0.3%. Most cold senders stay far below 5,000 a day per domain, but meeting the full bulk list costs nothing extra and makes your domain look like every other legitimate sender.

SPF: who is allowed to send

SPF (Sender Policy Framework) is a TXT record at the root of your domain listing the servers and services allowed to send mail for it. Receivers check the connecting server against the list. For a domain that sends only through Google Workspace:

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

For Microsoft 365 the include is spf.protection.outlook.com. If a sending platform sends from its own servers using your domain, add its include too; your provider's documentation gives the exact value. The rules that matter:

• Exactly one SPF record per domain. Two records is an automatic failure, however correct each one is. Merge them into one.
• No more than 10 DNS lookups. Each include, a, mx and redirect counts, including nested includes inside them. Past 10, SPF returns an error and fails.
• End with ~all (soft fail) while you are setting up, then consider -all once you are sure every sender is listed. Never use +all, which authorises anyone.
• Each sending domain needs its own record. A record on your main domain does nothing for the separate domains you use for cold outreach.

DKIM: a signature receivers can verify

DKIM (DomainKeys Identified Mail) signs every outgoing message with a private key held by your mail provider. Receivers fetch the matching public key from DNS at a selector, such as google._domainkey.yourdomain.com, and check the signature. A pass proves the message came through your provider and was not changed on the way.

• Google Workspace: Admin console, Apps, Google Workspace, Gmail, Authenticate email. Generate a 2048-bit key, publish the TXT record at google._domainkey, wait for DNS, then click Start authentication. Forgetting that last click is the most common DKIM failure.
• Microsoft 365: DKIM uses two CNAME records (selector1._domainkey and selector2._domainkey) pointing at Microsoft; publish both, then enable signing for the domain in the Defender portal.
• Other platforms: if a sending tool offers a custom DKIM key on your domain, use it. Signing with the platform's own domain passes DKIM but does not align with your From address.

Use 2048-bit keys. Some DNS hosts split long TXT values into several quoted strings; that is fine as long as the provider's value is pasted in full.

DMARC: the policy that ties it together

DMARC does two jobs. It tells receivers what to do with mail that fails authentication, and it sends you daily aggregate reports showing every server sending as your domain. Publish it as a TXT record at _dmarc.yourdomain.com. A sensible starting record:

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

p=none means monitor only: nothing is blocked while you check the reports. Once the reports show only your real services passing for a few weeks, move to p=quarantine and later p=reject if you want protection against spoofing. For a cold outreach domain, p=none with working reports already meets the bulk sender rules; tightening the policy protects the domain from spoofing more than it improves placement. Make sure the rua mailbox exists. Aggregate reports arrive as XML attachments, and a report reader makes them far easier to use.

Alignment: the part most guides skip

DMARC passes only if SPF or DKIM passes and the passing domain matches the domain in your visible From address. By default the match is relaxed, so a subdomain counts. The trap is third-party senders: if a platform sends with its own bounce domain (SPF passes for them, not you) and signs with its own DKIM key, both checks pass but neither aligns, and DMARC fails. The fix is a custom DKIM key or custom return-path domain on your own domain in that platform.

A 20-minute setup order

1. List every service that sends mail as the domain: your mailbox provider, any sending platform, your CRM, your helpdesk.
2. Publish one SPF record containing all of them, and count the lookups.
3. Enable DKIM in each service that supports a custom key, with 2048-bit keys, and switch signing on.
4. Publish DMARC at p=none with a rua address you read.
5. Wait for DNS to propagate (usually minutes, sometimes a few hours), then verify.
6. Start warmup only after all three pass. Warming a domain with broken authentication wastes the weeks it takes.

How to verify it works

Send a message to a Gmail address you control, open it and choose Show original from the three-dot menu. You want SPF: PASS, DKIM: PASS and DMARC: PASS, with your own domain shown next to each. If DKIM passes for a platform domain rather than yours, alignment is not set up. Repeat for an Outlook address, or run the domain through a checker that reads all three records at once.

Separate domains for cold outreach

Most cold senders send from separate domains (for example a variant of the brand name) rather than the main company domain, so a reputation problem from outreach never touches invoices, support replies or password resets. Each of those domains needs its own SPF, DKIM and DMARC records; nothing is inherited from the main domain. Point the website of each sending domain at your real site so a recipient who checks it finds you, and keep the number of mailboxes per domain small, typically two or three.

MTA-STS and TLS-RPT: optional extras

MTA-STS tells other servers to deliver mail to your domain only over TLS, and TLS-RPT gives them an address to report TLS problems. Neither is part of the Gmail and Yahoo sender rules, and neither changes placement much by itself, but they are a sign of a well-run domain. If you add MTA-STS, publish the policy in testing mode first.

Keeping it working

Authentication breaks quietly. Someone adds a new tool and a second SPF record, a DNS migration drops the DKIM key, or a domain renewal lapses. Mail keeps sending, but it starts failing checks and sliding into spam, and your campaign tool still reports it as sent. Re-check records after every DNS or vendor change, and read the DMARC reports.

Warmerly checks SPF, DKIM, DMARC and MTA-STS on every connected domain daily and alerts you with fix instructions when something breaks, alongside warmup with spam-folder rescue every 10 minutes and placement tests across five providers. The free plan covers one mailbox with no card; Starter is $19/month for 5 mailboxes, with a 7-day trial and no charge until day 8.