---
title: "SPF, DKIM, DMARC: 2026 Setup Guide"
description: "The three email-auth records every cold sender needs in 2026, set up correctly - with the DMARC policy that actually passes enforcement."
date: "2026-06-12"
tags: "email-deliverability, spf, dkim, dmarc, authentication"
readTime: "11 min read"
author: "FirstSales Team"
slug: "spf-dkim-dmarc-setup-2026"
canonical: "https://firstsales.io/blog/spf-dkim-dmarc-setup-2026/"
---

<!-- IMG cover: DIAGRAM - Three-layer email authentication stack: SPF, DKIM, DMARC with enforcement arrows pointing to Gmail and Outlook logos -->

**TL;DR:** SPF tells receiving servers which IPs can send on your behalf. DKIM signs the message so it can't be tampered in transit. DMARC tells Gmail and Outlook what to do when the first two fail - and in 2026, "reject" means a hard 550 bounce with no retry. Set all three up before you send a single cold email. This guide shows you exactly how.

## Table of Contents

- [Why This Matters More in 2026](#why-this-matters-more-in-2026)
- [SPF: The Sender Whitelist](#spf-the-sender-whitelist)
- [DKIM: The Cryptographic Signature](#dkim-the-cryptographic-signature)
- [DMARC: The Policy That Ties Them Together](#dmarc-the-policy-that-ties-them-together)
- [DMARC Policy Progression: none to reject](#dmarc-policy-progression-none-to-reject)
- [DMARC Alignment - The Part Most People Miss](#dmarc-alignment-the-part-most-people-miss)
- [Verifying Your Setup](#verifying-your-setup)
- [The Cold Email Infra Reality Check](#the-cold-email-infra-reality-check)
- [FAQs](#faqs)
- [Conclusion](#conclusion)

---

## Why This Matters More in 2026

In early 2024, Google and Yahoo announced bulk-sender authentication requirements for anyone sending over 5,000 emails per day. Microsoft followed with its own equivalent rules enforced from May 2025. By late 2025, the grace period ended: Gmail moved from throttling unauthenticated senders to issuing permanent 550 rejections. Microsoft started returning `550 5.7.15` - a hard failure with no retry path.

The practical effect landed hard in June 2026. Practitioners reported that ".info domains got completely nuked, Azure inboxes took a hit - the cheap abused meta is dead." The senders who got hurt were not all fly-by-night spammers. Many were legitimate outbound teams who skipped proper auth because they assumed their ESP handled it. Some ESPs do handle it. Many do not handle it completely. You need to verify this yourself, every time, for every sending domain.

If your [email deliverability](/blog/email-deliverability/) foundation is shaky, SPF, DKIM, and DMARC are the first things to fix - before you look at warmup schedules, sequence timing, or copy quality. Authentication is the floor, not an advanced topic.

---

## SPF: The Sender Whitelist

**What it does:** SPF (Sender Policy Framework) is a DNS TXT record that lists every mail server authorized to send email from your domain. When Gmail receives a message from you, it looks up your SPF record and checks whether the sending IP is on the list. If it is not, SPF fails.

**The DNS record:**

```
v=spf1 include:_spf.google.com include:sendgrid.net ~all
```

Breaking this down:

- `v=spf1` - declares this is an SPF record
- `include:_spf.google.com` - authorizes Google Workspace's sending IPs
- `include:sendgrid.net` - authorizes SendGrid's sending IPs (replace with your actual ESP)
- `~all` - softfail for anything not listed (use `-all` for hard fail once you are confident)

**Rules to follow:**

1. One SPF record per domain. Multiple SPF records cause lookup failures.
2. Stay under 10 DNS lookups. Every `include:` that resolves to another include counts toward this limit. Go over 10 and SPF fails with a PermerError.
3. List every service that sends on your behalf: your ESP, your CRM, transactional email providers, and any sales tools.

**Common mistake:** Adding SPF for your primary domain but forgetting your sending subdomains or secondary cold-email domains. Each domain needs its own SPF record.

<!-- IMG spf-dns: DIAGRAM - DNS lookup flow showing IP check against SPF include chain, 10-lookup limit highlighted in red -->

---

## DKIM: The Cryptographic Signature

**What it does:** DKIM (DomainKeys Identified Mail) adds a cryptographic signature to each outgoing message. The receiving server fetches your public key from DNS and uses it to verify that the message body and key headers have not been altered in transit. It also proves the message genuinely came from someone with access to your private key.

**The DNS record format:**

```
selector._domainkey.yourdomain.com  IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSq..."
```

Where:
- `selector` is a label you or your ESP chooses (often `google`, `s1`, `k1`, or similar)
- `p=` contains your base64-encoded public key (generated by your ESP or mail server)

**You do not generate the DKIM record manually in most cases.** Your ESP (Google Workspace, Microsoft 365, SendGrid, Mailgun, Instantly, Smartlead, or similar) generates the key pair and gives you the exact DNS record to add. Your job is to add it to your DNS zone and verify that it passes.

**Key requirements for 2026:**

- Use RSA-2048 or ECDSA P-256 at minimum. RSA-1024 is now rejected by several providers.
- If you rotate keys (recommended annually or after any suspected compromise), add the new selector record before removing the old one. There is a propagation delay.
- Verify DKIM passes via a tool like mail-tester.com or mxtoolbox.com/dkim before you start sending.

**Per-sending-domain requirement:** Just like SPF, each domain you use for cold outbound needs its own DKIM setup. This is where teams get caught: they set up auth on their primary domain and forget the five secondary cold-email domains they purchased.

---

## DMARC: The Policy That Ties Them Together

**What it does:** DMARC (Domain-based Message Authentication, Reporting and Conformance) builds on SPF and DKIM. It tells receiving servers what to do when a message fails authentication - and it adds reporting so you can see who is sending email that claims to be from your domain.

**A minimal DMARC record:**

```
_dmarc.yourdomain.com  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com"
```

Fields:

- `v=DMARC1` - version declaration
- `p=none` - policy (none, quarantine, or reject)
- `rua=` - aggregate report destination (daily XML digests)
- `ruf=` - forensic/failure report destination (optional, individual failure samples)

**Adding subdomain policy:**

```
"v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc-reports@yourdomain.com; adkim=s; aspf=s"
```

- `sp=reject` - applies the same policy to all subdomains
- `adkim=s` - strict DKIM alignment
- `aspf=s` - strict SPF alignment

For most cold-email senders, `adkim=r; aspf=r` (relaxed alignment) is the safe starting point.

---

## DMARC Policy Progression: none to reject

This is the progression every cold sender should follow. Rushing to `p=reject` before you have confirmed all your sending sources are authenticated will silently drop legitimate mail.

<!-- IMG dmarc-progression: DIAGRAM - Three-stage DMARC progression timeline: p=none (weeks 1-4), p=quarantine (weeks 5-8), p=reject (week 9+) with decision checkpoints -->

### Stage 1: p=none (weeks 1 to 4)

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

None policy means: monitor only, take no action. Gmail and Outlook still deliver the message regardless of auth failures, but they send you aggregate reports showing pass/fail rates across every sending source.

What to do during this stage: read the reports (or use a DMARC report reader like Dmarcian, Valimail, or Google Postmaster Tools) and identify any sources that are failing SPF or DKIM. Fix them before moving on.

### Stage 2: p=quarantine (weeks 5 to 8)

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

Quarantine means: route failing messages to spam rather than the inbox. Start with `pct=20` (applies to 20% of failing messages) and ramp up as you gain confidence. This is the 2026 safe baseline recommended by most deliverability practitioners - you get real enforcement without the hard-bounce risk of reject.

Watch your aggregate reports closely during this stage. Any spike in quarantine volume indicates a sending source you missed.

### Stage 3: p=reject (week 9 and beyond)

```
"v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com"
```

Reject means: hard fail. Any message that fails DMARC gets dropped with a 550 bounce. This is the strongest setting and the one that provides the most protection against domain spoofing and phishing. For cold-email senders, reach this stage for your primary brand domain. For secondary cold-email domains, `p=quarantine` is acceptable once you have confirmed clean auth.

**Do not skip stages.** Teams that jump straight to `p=reject` because they read it was the "right" setting sometimes discover an overlooked sending source - their CRM, a marketing tool, a third-party enrichment platform - that was sending on their behalf and now starts bouncing.

---

## DMARC Alignment - The Part Most People Miss

DMARC passes only when SPF or DKIM *aligns* with the `From:` header domain. Alignment is what trips up most cold-email setups.

**SPF alignment:** The domain in your `Return-Path` (the envelope sender) must match the `From:` header domain. If you send from `user@yourdomain.com` but your ESP's bounce-handling address is `bounces@esp-subdomain.com`, SPF may pass but DMARC alignment fails on SPF.

**DKIM alignment:** The `d=` value in your DKIM signature must match the `From:` header domain. If your ESP signs with `d=mailgun.org` instead of `d=yourdomain.com`, DKIM passes but DMARC alignment fails on DKIM.

**Solution:** Configure your ESP to sign outgoing messages with your own domain's DKIM key (using a custom sending domain), and verify that your Return-Path resolves to your domain or a subdomain. Most quality ESPs support this. If yours does not, switch.

For cold email specifically, if you are using a sending tool that routes through shared infrastructure, always verify DMARC alignment with a test send before you start your sequences. The [cold email deliverability checklist](/blog/cold-email-deliverability-checklist/) is a good companion reference for this verification step.

---

## Verifying Your Setup

Once you have published all three records, verify them before sending:

**SPF check:**
```
nslookup -type=txt yourdomain.com
```
Look for the record starting with `v=spf1`. Verify all your sending sources are included.

**DKIM check:**
Use your ESP's built-in verification tool, or query DNS directly:
```
nslookup -type=txt selector._domainkey.yourdomain.com
```
You should see a record starting with `v=DKIM1`.

**DMARC check:**
```
nslookup -type=txt _dmarc.yourdomain.com
```
Look for the record starting with `v=DMARC1`.

**End-to-end test:** Send a test message to mail-tester.com or use Google's postmaster tools. You want to see SPF pass, DKIM pass, and DMARC pass in the message headers. In Gmail, open the message, click the three-dot menu, select "Show original," and look for the Authentication-Results header:

```
Authentication-Results: mx.google.com;
  dkim=pass header.i=@yourdomain.com;
  spf=pass (google.com: domain of user@yourdomain.com designates 1.2.3.4 as permitted sender);
  dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=yourdomain.com
```

All three should show `pass`. If any shows `fail` or `softfail`, do not start sending at volume.

---

## The Cold Email Infra Reality Check

Authentication solves the identity problem. It does not solve the reputation problem. You still need to [warm up your sending domain](/blog/how-to-warm-up-an-email/) before ramping volume, keep your [spam complaint rate](/blog/why-cold-emails-land-in-spam/) well under 0.1%, and respect the volume limits your inbox provider imposes.

The June 2026 deliverability hit that swept through the cold outbound community affected senders across the board - not just those missing auth. The [Gmail enforcement shift](/blog/gmail-permanent-rejection-2026/) and the [Outlook bulk-sender rules](/blog/outlook-5000-sender-rules-2026/) both require auth as a floor, but they use complaint rates, sending volume, and domain age as the inputs that decide where your authenticated mail actually lands.

Think of SPF, DKIM, and DMARC as the entry ticket. They get you in the door. Everything else - your list quality, your copy relevance, your warmup discipline - determines whether you get to stay.

If you want a tool that handles the drafting side while keeping a human in the approval loop (so you are never sending AI slop at scale and tanking your complaint rate), that is exactly what [FirstSales](https://firstsales.io) is built for. AI drafts a personalized email for each prospect, you read it, approve it, and it sends. The quality check happens before the send, not after the complaint.

---

## FAQs

### Do I need SPF, DKIM, and DMARC even if I only send a few hundred emails per day?

Yes. Google and Microsoft's 5,000/day threshold applies to bulk marketing mail, but cold outbound senders report deliverability problems at much lower volumes when auth is missing. Authentication is also a prerequisite for domain warmup to work properly - unauthenticated warm sends build no meaningful reputation.

### What happens if SPF passes but DKIM fails?

DMARC can still pass if at least one of SPF or DKIM passes AND aligns with your From domain. But relying on only one is risky. If your ESP rotates IPs and your SPF lookup times out, you have no fallback. Set up both.

### Can I use a subdomain for cold email and leave my main domain clean?

Yes, and this is common practice. Use `outreach.yourdomain.com` or a separate domain entirely for cold sends. Each domain still needs its own SPF, DKIM, and DMARC records. The main domain stays protected by its own DMARC policy.

### How long does it take for DNS changes to propagate?

Typically 15 minutes to a few hours for most DNS providers, though the official TTL can be up to 48 hours. Check propagation with a tool like dnschecker.org before you assume the record is live globally.

### What is the difference between DMARC p=quarantine and p=reject?

Quarantine routes failing messages to the recipient's spam folder. Reject drops them entirely with a 550 error - no delivery, no retry. For your primary brand domain, aim for reject. For newer cold-email domains still in warmup, quarantine is an acceptable intermediate step.

### My ESP says they handle authentication - do I still need to check?

Always verify. Some ESPs publish DKIM with their own domain by default, not yours. That means DMARC alignment fails even though DKIM technically passes. Log into your DNS provider and confirm your own records are present. Then do a test send and read the Authentication-Results header.

---

## Conclusion

SPF, DKIM, and DMARC are not a one-time setup you configure and forget. They are the infrastructure layer your entire outbound program depends on. In 2026, both Gmail and Outlook issue hard rejections for senders who skip them - and the cold email community felt that enforcement land in real time in June.

The setup itself is not complicated. Publish an SPF record that lists every sending source. Add DKIM for each domain you send from, using your own domain's key. Start DMARC at `p=none`, read the reports for a few weeks, fix any misaligned sources, then step up to `p=quarantine` and eventually `p=reject`. Verify alignment, not just pass/fail.

Once auth is solid, the next bottleneck is usually message quality - writing personalized emails that feel human and earn a reply rather than a spam report. That is where [FirstSales](https://firstsales.io) comes in. The AI drafts a personalized cold email for each prospect on your list. You review and approve it. It sends. The human checkpoint is what keeps complaint rates low and reply rates real.

Start for $1 and see the draft queue in action before you commit.

<!-- fs:related:start -->

## Keep reading

- [ARC Email Authentication: The Layer After SPF and DMARC](/blog/arc-email-authentication/)
- [DMARC Quarantine Policy: Moving From p=none Safely](/blog/dmarc-quarantine-policy/)

<!-- fs:related:end -->
