SPF, DKIM, and DMARC for Cold Email in 2026: The Complete Setup Guide

Updated June 2026 · 18 min read · By Marwene Amor

If your cold email is landing in spam and you've never set up email authentication, this is almost certainly why. SPF, DKIM, and DMARC are the three DNS records that prove to Gmail, Outlook, and Yahoo that you are who you say you are. In 2026 they aren't a nice-to-have. The major mailbox providers formally require them, and an unauthenticated sending domain doesn't get the benefit of the doubt. No amount of clever copy or careful warmup compensates for failing authentication.

The good news: setting them up is a one-time job that takes an afternoon, and this guide walks through all three in plain language, with the exact order to do them in, how to verify each one, and the mistakes that quietly break authentication even when you think it's configured. No jargon you don't need, and no DNS records copied blindly from a tutorial, which is itself one of the most common ways people get this wrong.

You can read any of the three records live: SPF, DKIM, DMARC. Each page reads the record in your browser and explains what it found.

If you want to see how often this goes wrong in practice, we read the live records of 156 B2B lead generation agencies in August 2026: 56% carry a real defect, four of them publish two SPF records, and only 19% enforce DMARC.

Try Instantly Free →

Why SPF, DKIM, and DMARC are mandatory in 2026

Email authentication used to be something only large senders worried about. That changed. Gmail and Yahoo rolled out sender requirements that make SPF, DKIM, and DMARC effectively mandatory for anyone sending more than a small daily volume, and Microsoft has tightened Outlook's enforcement in step. The logic is simple from the provider's side: spam and spoofing exploded, and the cheapest way to filter bad senders is to distrust anyone who can't prove their identity. Authentication is that proof.

For cold email specifically, this matters double. You're a new or low-reputation sender by definition, so you start with no trust to spend. Authentication is the one signal you can put fully in place before you send a single email, and skipping it guarantees a hard start. The three records work together: SPF and DKIM each prove a piece of your identity, and DMARC ties them together and tells providers what to do when something doesn't check out. Get all three right and you've cleared the first and most binary deliverability gate. For where this fits in the full picture, see our cold email deliverability checklist.

SPF: Sender Policy Framework

What it is: SPF is a single DNS TXT record that lists which mail servers are allowed to send email for your domain. When a mailbox provider receives your email, it looks up your SPF record and checks whether the server that sent the message is on the authorized list. If it is, SPF passes. If not, it fails.

How to set it up: your sending platform (Google Workspace, Microsoft 365, or whatever you send through) publishes the exact SPF string to use in its documentation. You add that string as a TXT record on your sending domain through your DNS provider. A Google Workspace record, for example, looks like v=spf1 include:_spf.google.com ~all. Don't write your own from memory: get the current string from your provider, because the include mechanism is what authorizes their servers.

The two mistakes that break SPF:

• Multiple SPF records. A domain must have exactly one SPF record. If you have two (a common result of adding a new service without merging), SPF fails entirely. Merge all your sending services into a single v=spf1 record with multiple include statements.
• The 10-lookup limit. SPF allows a maximum of 10 DNS lookups when it evaluates includes. Stack too many services and SPF fails with a permerror. Keep the record lean, and remove includes for services you no longer use.

End your record with ~all (softfail) while testing and you can move to -all (hardfail) once you're confident only authorized servers send for the domain.

DKIM: DomainKeys Identified Mail

What it is: DKIM attaches a cryptographic signature to every email you send. Your sending platform signs the message with a private key, and the matching public key is published in your DNS. The receiving provider verifies the signature against that public key, which proves two things: the message actually came from your domain, and it wasn't tampered with in transit.

How to set it up: enable DKIM inside your sending platform, which generates a public key, then publish that key as a TXT (or CNAME, depending on the provider) record on a specific subdomain, usually something like selector._domainkey.yourdomain.com. In Google Workspace you generate the key in the Admin console under Apps, Google Workspace, Gmail, Authenticate email, then add the record it gives you and click Start authentication. Microsoft 365 uses CNAME records you enable in the Defender or Exchange admin center. The exact selector and value come from your provider.

The mistake that breaks DKIM: generating the key but never publishing the DNS record, or publishing it and forgetting to flip the switch that turns signing on. DKIM has two halves, the DNS record and the platform setting, and both must be done. Verify with a tool like MXToolbox that the public key resolves, then send a test to confirm messages are actually signed.

DMARC: Domain-based Message Authentication, Reporting and Conformance

What it is: DMARC ties SPF and DKIM together. It's a TXT record at _dmarc.yourdomain.com that tells receiving providers two things: what to do with mail that fails authentication, and where to send reports about it. DMARC also enforces alignment, meaning the domain in your visible From address has to match the domain that passed SPF or DKIM, which is what actually stops spoofing.

The policy progression: DMARC has three policy levels, and you move through them in order rather than jumping to the strictest.

Policy	What it does	When to use it
p=none	Monitor only, no effect on delivery	Start here. Watch reports to confirm SPF and DKIM pass on real mail.
p=quarantine	Failing mail goes to spam	After one to two weeks of clean reports at p=none.
p=reject	Failing mail is rejected outright	Once you're confident every legitimate source is authenticated.

A starting record looks like v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com, where the rua address receives aggregate reports. For a dedicated cold email domain that only ever sends outbound, you can progress to p=reject fairly quickly, because there are few legitimate sending sources to account for. Publish DMARC only after SPF and DKIM are passing, since a strict policy on top of broken authentication will quarantine your own legitimate mail.

The right order to set them up

Order matters, and doing it backwards is a common self-inflicted wound. The sequence:

1. SPF first. Publish the single TXT record, verify it resolves.
2. DKIM second. Generate the key, publish the DNS record, turn on signing, verify it passes.
3. DMARC last, at p=none. Only once SPF and DKIM both pass. Watch the reports.
4. Tighten DMARC to quarantine, then reject, over the following weeks.

The reason DMARC comes last is that it depends on the other two. A DMARC policy of quarantine or reject published before SPF and DKIM are passing will treat your own legitimate mail as unauthenticated and send it to spam or bounce it. Authentication first, enforcement second.

How to verify everything is working

Never assume authentication is set just because you added the records. Verify with three independent checks:

• MXToolbox checks each DNS record individually. Use its SPF, DKIM, and DMARC lookups to confirm each record exists and is syntactically valid.
• Mail-tester.com gives you an address to send a test email to, then scores the message and flags any authentication failure in plain language. A score near 10 with all three passing is what you want.
• The Gmail test. Send yourself a message at a Gmail address, open it, click the three-dot menu, and choose Show original. Gmail displays PASS or FAIL for SPF, DKIM, and DMARC directly. This is the closest thing to seeing your mail through a provider's eyes.

Run all three before your first real campaign. If any one fails, fix it before sending, because a single failing record can route otherwise-perfect email to spam.

The custom tracking domain (the fourth piece)

Authentication is three records, but there's a closely related fourth setup worth doing at the same time: a custom tracking domain. Most cold email tools default to a shared tracking domain for open and click tracking, which pools reputation across every user of that tool. If other senders on the shared domain are spammy, your tracking inherits the penalty. The fix is a CNAME record pointing a subdomain of your sending domain at your tool's tracking host, which your sender documents. It's not part of SPF, DKIM, or DMARC, but it's the same kind of DNS-level reputation hygiene, and the moment you're configuring DNS for authentication is the natural time to add it.

Setting it up on Google Workspace, start to finish

Since most cold email inboxes run on Google Workspace, here's the full path in one place. First, SPF: in your DNS provider, add a TXT record on the root domain with the value v=spf1 include:_spf.google.com ~all. Second, DKIM: in the Google Admin console, go to Apps, Google Workspace, Gmail, Authenticate email, select your domain, and generate a new record. Copy the TXT record it produces (the host is usually google._domainkey) into your DNS, wait for it to propagate, then return to the console and click Start authentication. Third, DMARC: add a TXT record at _dmarc.yourdomain.com with v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. Give DNS up to a few hours to propagate, then verify all three with a test to a Gmail address. After a week or two of clean DMARC reports, raise the policy to quarantine and then reject.

Setting it up on Microsoft 365

Microsoft 365 follows the same three records with platform-specific steps. SPF is a TXT record with v=spf1 include:spf.protection.outlook.com -all. DKIM is enabled in the Microsoft Defender portal under Email and collaboration, Policies, Email authentication settings, DKIM: select your domain, and Microsoft gives you two CNAME records to publish (selector1 and selector2), after which you toggle DKIM signing on. DMARC is the same _dmarc TXT record as anywhere else, starting at p=none. The one Microsoft quirk worth knowing: DKIM uses two CNAME records rather than one TXT record, and both must be published before you enable signing, or the toggle fails.

What about BIMI and brand indicators?

You may see BIMI mentioned alongside the big three. BIMI (Brand Indicators for Message Identification) displays your logo next to your emails in supporting clients, but it sits on top of authentication: it only works once DMARC is at quarantine or reject, and it often requires a verified mark certificate, which is an added cost. For cold email specifically, BIMI is optional and low-priority. It's a branding nicety for established senders, not a deliverability requirement. Get SPF, DKIM, and DMARC right first, and treat BIMI as something to consider much later, if at all, for your main brand domain rather than your cold sending domains.

Authentication across multiple sending domains

Operators running cold email at volume use several sending domains and rotate across them, and authentication is per domain, so each one needs its own full set of records. There's no shortcut that authenticates them all at once. The good news is that the records are identical in shape per domain (same SPF include for the same provider, same DKIM setup, same DMARC progression), so once you've done one, the rest are quick repetition. Build a small checklist and run each new domain through the same three steps and the same Gmail verification before it ever sends. Skipping authentication on even one domain in a rotation means that domain's mail fails while the others pass, which is exactly the kind of silent, partial breakage that's hard to diagnose later.

Common authentication mistakes

• Two SPF records. The most common break. One record only, merge your services.
• Exceeding the SPF 10-lookup limit. Too many includes makes SPF fail. Keep it lean.
• DKIM generated but not published, or published but not switched on. Both halves are required.
• DMARC set to quarantine or reject before SPF and DKIM pass. This quarantines your own mail. Start at p=none.
• Authenticating only one of several sending domains. Each dedicated domain needs its own records.
• Copying records blindly from a tutorial. The include mechanisms, selectors, and keys are specific to your provider. Always use the strings your platform gives you.
• Setting it and never checking reports. DMARC aggregate reports tell you if something starts failing. Glance at them, especially in the first weeks.

How sending tools help with authentication

You still own the DNS records, but a good sending tool reduces the chance of getting them wrong. When you connect a mailbox, tools like Instantly run an authentication check during onboarding and flag missing or failing SPF, DKIM, or DMARC before you launch a campaign, which catches the most common silent cause of spam placement. That doesn't replace setting the records up correctly, but it's a useful safety net that stops you from sending on a misconfigured domain. We cover how senders handle this in the best cold email software guide and in detail in the Instantly review.

Frequently asked questions

Do I need SPF, DKIM, and DMARC for cold email?

Yes, all three. As of 2026 Gmail and Yahoo formally require SPF, DKIM, and DMARC for senders doing more than a small handful of emails a day, and Outlook's enforcement keeps tightening. Without them, your cold email is far more likely to land in spam or be rejected outright regardless of how good your copy and list are. They are the precondition for everything else in deliverability.

What order should I set up SPF, DKIM, and DMARC?

Set up SPF and DKIM first, verify both are passing, then add DMARC. DMARC depends on SPF and DKIM to function, so publishing a DMARC policy before the other two pass can cause legitimate mail to be quarantined or rejected. Start DMARC on a monitoring policy of p=none, watch the reports for one to two weeks, then tighten to quarantine and eventually reject.

Can I have more than one SPF record?

No. A domain must have exactly one SPF record, a single TXT record starting with v=spf1. Two SPF records is a common and serious mistake that causes SPF to fail entirely. If you send through multiple services, merge their include mechanisms into one record. Also watch the 10-DNS-lookup limit: too many include statements makes SPF fail, so keep the record lean.

What DMARC policy should I use for cold email?

Start at p=none, which monitors without affecting delivery, so you can confirm SPF and DKIM pass on your real mail. After one to two weeks of clean reports, move to p=quarantine, and eventually to p=reject. For a dedicated cold email domain that only sends outbound, you can reach p=reject relatively quickly since there are few legitimate sending sources to account for.

How do I check if SPF, DKIM, and DMARC are working?

Use a free tool. MXToolbox checks each DNS record individually. Mail-tester.com gives you a score after you send it a test email and flags any authentication failures. And sending a test to a Gmail account, then opening Show original, displays PASS or FAIL for SPF, DKIM, and DMARC directly. Verify all three pass before you send any real cold email.

Does each sending domain need its own SPF, DKIM, and DMARC?

Yes. Authentication is per domain, so every dedicated sending domain you use for cold email needs its own records configured for whatever service sends its mail. If you run several sending domains for rotation, each one is authenticated separately. The records are quick to add per domain, and skipping any domain leaves that domain's mail failing authentication.

What if authentication breaks later?

Authentication is mostly set-and-forget, but it can break silently. The usual causes: someone edits DNS and removes or duplicates a record, you add a new sending service and push SPF past the 10-lookup limit, or a provider rotates a DKIM key. The symptom is a sudden, unexplained drop in deliverability. This is exactly why the DMARC rua reports matter: they're your early-warning system, flagging authentication failures before they tank a campaign. Glance at them periodically, and re-run the Gmail Show-original check any time you change your sending setup or deliverability dips for no obvious reason.

Bottom line

SPF, DKIM, and DMARC are the non-negotiable foundation of cold email deliverability in 2026. They're a one-time setup, they take an afternoon, and getting them right is the single highest-certainty thing you can do to keep your email out of spam. Set up SPF and DKIM first, verify both pass, then layer DMARC on top starting at p=none and tightening over a couple of weeks. Use one SPF record, get every string from your provider, and verify with a real test to Gmail before you send.

Authentication is step one, not the whole job. Once your records pass, the rest of deliverability, warmup, list quality, volume, and copy, still has to be right. Work through the full deliverability checklist next, and the domain warmup playbook for the step that comes right after authentication.

Try Instantly Free →

Related Reviews & Guides

Other deep dives on EmailToolsHub that pair well with this one.

Browse all reviews →