How to Set Up SPF, DKIM, and DMARC for Cold Email (2026 Guide)

To authenticate a cold email domain you need three DNS records on that domain: one SPF TXT record listing your sending provider (v=spf1 include:_spf.google.com -all for Google Workspace, include:spf.protection.outlook.com for Microsoft 365), one DKIM record generated inside your mailbox provider's admin console, and one DMARC TXT record at _dmarc.yourdomain.com starting at p=none with a working rua= address. Every sending domain needs its own set. Authentication does not inherit from your main brand domain, and a cold email domain with only SPF configured will fail DMARC at Gmail and Outlook.

The rest of this guide is the part most tutorials skip: which records go on which domain, why SPF passing doesn't mean DMARC passing, why you almost certainly should not add Instantly or Smartlead to your SPF record, and how to verify all three are actually passing on a real message rather than trusting a green checkmark in a DNS tool.

What do SPF, DKIM, and DMARC actually do?

All three answer the same underlying question, "is this message really from this domain?", but they check different things, and the differences matter when you're troubleshooting.

That last concept, alignment, is the single most common thing people get wrong. A message can show spf=pass and dkim=pass in its headers and still get dmarc=fail, because the SPF pass belonged to your ESP's bounce domain and the DKIM signature was applied by onmicrosoft.com rather than your domain. Always read the domain next to each result, not just the word "pass."

For cold email specifically, authentication is the entry requirement, not a deliverability strategy. Google's published bulk sender requirements mandate SPF, DKIM, DMARC, one-click unsubscribe, and a spam complaint rate under 0.3% for senders above 5,000 messages a day to Gmail, and Microsoft has rolled out equivalent requirements for Outlook.com. Below those volume thresholds the records aren't formally mandatory, but filters treat unauthenticated cold mail as a strong negative signal regardless of volume. Getting all three right buys you a fair evaluation. It doesn't buy you the inbox. That comes from list quality, volume discipline, and content.

What DNS records do I need on every cold email domain?

Assume you've bought getacmehq.com as a sending domain alongside your real acme.com. Here is the complete record set for that sending domain:

Your primary brand domain (acme.com) needs its own separate, correctly configured set. If you own domains you never send from, publish v=spf1 -all and v=DMARC1; p=reject; on them so nobody can spoof them.

How do I set up SPF for a cold email domain?

Add a single TXT record at the root of the domain (host @, or blank, depending on your registrar; some auto-append the domain, so entering getacmehq.com can produce getacmehq.com.getacmehq.com).

Google Workspace: v=spf1 include:_spf.google.com ~all
Microsoft 365: v=spf1 include:spf.protection.outlook.com ~all

Three rules that cover most SPF failures:

How do I set up DKIM on Google Workspace?

DKIM is not on by default for custom domains in Google Workspace. New domains sign with a Google-owned key until you generate your own, which means DKIM alignment fails and you're relying on SPF alone.

How do I set up DKIM on Microsoft 365?

Until you complete that last toggle, Microsoft signs your outbound mail with its onmicrosoft.com tenant domain. That produces dkim=pass in the headers, for the wrong domain, so it fails DMARC alignment. It's a genuinely deceptive failure mode and worth checking explicitly on every M365 sending domain you own.

What DMARC policy should I use for cold email?

Publish a TXT record at host _dmarc:

v=DMARC1; p=none; rua=mailto:[email protected]; fo=1; adkim=r; aspf=r

What the tags mean and how to choose:

The detail almost everyone misses: if your rua= address is at a different domain than the one publishing the record, say sending from getacmehq.com but collecting reports at acme.com, the receiving domain must publish an authorization record, or compliant reporters will silently drop your reports. Add this TXT record on the reporting domain:

Host: getacmehq.com._report._dmarc at acme.com, Value: v=DMARC1

With twenty sending domains pointing at one mailbox, that's twenty authorization records. Most managed DNS tooling handles this automatically; hand-built setups usually don't, which is why so many operators conclude "DMARC reports don't work."

Do I need to add Instantly or Smartlead to my SPF record?

Almost always no, and adding them is a common, avoidable mistake.

When you connect a Google Workspace or Microsoft 365 mailbox to a sending tool via OAuth or SMTP, that tool doesn't send the message itself. It hands the message to Google or Microsoft, which sends it from their own IPs, signs it with your DKIM key, and sets the Return-Path to your domain. SPF is evaluated against Google's or Microsoft's infrastructure, already covered by include:_spf.google.com. Adding include: entries for your sending tool authorizes IPs that will never send your mail, consumes DNS lookups against the limit of ten, and gains nothing.

The exception is a tool that sends over its own SMTP infrastructure on your behalf (a dedicated SMTP relay or transactional ESP). In that case follow that provider's SPF and DKIM instructions exactly, because the sending IPs genuinely change. If you're unsure which case you're in, send yourself a test and check the Return-Path header. It tells you unambiguously who handed the message off.

How do I verify SPF, DKIM, and DMARC are actually passing?

DNS lookup tools confirm that records exist. Only a real message confirms they work. Do both.

Check the records resolve:

Check a real message: send from the configured mailbox to a personal Gmail address, open the message, and choose Show original. Gmail displays SPF, DKIM, and DMARC results at the top. You want three passes, and you want the DKIM domain to read getacmehq.com, not onmicrosoft.com and not your sending tool's domain. In the raw headers, confirm Authentication-Results shows dmarc=pass header.from=getacmehq.com. That one line is the whole test.

Tools like mail-tester.com are a useful second opinion because they also flag blocklist hits, missing PTR records, and spam-trigger content. Treat the score as a diagnostic, not a target. Optimizing a test score is not the same as reaching inboxes.

Do this on every sending domain, not a sample. With thirty domains, a single one where DKIM authentication was generated but never switched on will quietly fail DMARC for months.

What are the most common mistakes that break authentication?

What's the right setup order and how long does it take?

Per domain, the DNS work is roughly 15–20 minutes once you've done it a few times. The waiting is the long part.

Alongside this, keep volume conservative. Roughly two to three mailboxes per domain and a modest daily send per mailbox is the widely used pattern. Perfect authentication on a domain sending 200 cold emails a day will not save you.

Should I configure this manually or use managed infrastructure?

Manual setup is entirely doable and this guide contains everything you need. It's the right choice when you're running a handful of domains and want to understand the machinery, which is worth doing at least once regardless of what you use afterward.

It stops scaling around the point where you're managing dozens of domains: DKIM enabled per domain per tenant, one SPF record each, DMARC plus per-domain report authorization records, MX, tracking CNAMEs, redirects, and a re-verification pass every time anything changes. That's a few hundred DNS records maintained by hand, where one missed toggle is invisible until deliverability drops.

This is where Inboxlogy is genuinely the answer rather than a plug: it provisions authorized Google Workspace and Microsoft 365 mailboxes, real tenants on the real platforms rather than SMTP resellers or workarounds, with SPF, DKIM, and DMARC configured automatically on every domain, on dedicated US or EU IPs. You get 100% ownership and full admin access to the tenants, so nothing here is a black box: you can open the Admin console, inspect the DKIM settings, and change any record described in this article yourself. Everything is also available through a full API if you're provisioning programmatically. Pricing starts at $2.80 per mailbox per month, $0 setup, billed monthly.

One thing Inboxlogy deliberately does not do is warm up your mailboxes. Warmup happens in your connected sending tool, whether that's Instantly, Smartlead, or ReachInbox, where your sequences and sending schedules already live. Infrastructure and campaign execution are separate jobs, and anyone claiming to do both from the DNS layer is describing something else.

Frequently asked questions

Can I use my main company domain for cold email if it already has SPF, DKIM, and DMARC?

Technically yes, but it's a bad trade. Cold email generates spam complaints, and complaints attach to the sending domain's reputation. If that's the domain your invoices, contracts, and support replies go out on, one bad campaign degrades mail your business depends on. Use separate sending domains with their own full record set and treat them as expendable.

Why does my email show SPF pass and DKIM pass but DMARC fail?

Alignment. DMARC requires the domain that passed SPF or DKIM to match your visible From: domain. The usual causes are a Return-Path belonging to your ESP's bounce domain and a DKIM signature applied by onmicrosoft.com because DKIM was never enabled for your custom domain. Read the domain next to each result in the Authentication-Results header. That identifies which of the two is misaligned.

Does a stronger DMARC policy improve inbox placement?

Not directly. Gmail and Outlook require a DMARC record to exist for bulk senders; they do not reward p=reject over p=none with better placement. What a strict policy buys you is protection against spoofing of your domain, which protects reputation over time. Placement comes from engagement, complaint rate, volume ramp, and list quality.

How often do I need to rotate DKIM keys?

There's no fixed requirement, and for most cold email operations the answer is rarely. A 2048-bit key rotated annually is comfortable practice. What matters more is rotating immediately if a key is ever exposed, and re-verifying after any tenant migration, since Microsoft's selector CNAMEs point at tenant-specific hosts and will break when the domain moves.