TL;DR
- SPF says who can send. DKIM signs what's sent. DMARC says what happens when either breaks. Three records. One goal: prove the email is really from you.
- Required since Feb 2024 for Gmail and Yahoo, and May 2025 for Microsoft Outlook — for any sender above 5,000 emails/day to consumer inboxes. Enforcement is tightening below that threshold too.
- Domains with all three authenticated reach the inbox roughly 2.7× more often than unauthenticated domains — the single biggest infrastructure lever on deliverability.
- Start DMARC at p=none, not p=reject. Monitor for 14 days. Fix failures. Move to p=quarantine. Only reach p=reject after clean reports — otherwise you will bounce legitimate calendar invites and transactional mail.
- Authentication is ~20% of the deliverability problem. Engagement, volume, copy, and list hygiene are the other 80%. Set up the records once, then move on.
Direct answer
SPF, DKIM, and DMARC are the three DNS records that prove a cold email is really from the domain it claims. SPF authorizes which IPs can send. DKIM cryptographically signs each message. DMARC tells receivers what to do when SPF or DKIM fail — monitor, quarantine, or reject. Gmail, Yahoo, and Microsoft now require all three on any domain sending above 5,000 emails per day, and enforcement below that threshold is getting stricter every quarter.
SPF, DKIM, DMARC in one paragraph a rep can remember
A rep gets a Slack message from their VP: "Ops says we need SPF, DKIM, and DMARC set up before you send another cold email." The rep Googles it, opens three tabs, each tab explains in cryptographic jargon what a "public key selector" is, and closes all three tabs. The cold email goes out anyway. Two weeks later, reply rate has cratered. Nobody connects the two.
Here is the version you can hold in your head. Email was built in 1982. It had no way to prove who sent a message. Anyone could type ceo@yourdomain.com as the sender and the mail server would believe it. SPF, DKIM, and DMARC are the three layers that patched that, 30 years later. They run on DNS, not in your inbox. Receiving servers check all three the instant a message lands. If checks pass, the message reaches the inbox. If they fail, the receiver follows your DMARC instruction — ignore, junk, or bounce.
A rep does not need to understand the cryptography. A rep needs to know four things: (1) whether the records exist on the sending domain, (2) whether every record passes in daily checks, (3) who owns the DNS panel, and (4) how to escalate when something breaks. That is the entire job. Everything in this guide is aimed at those four outcomes.
Why 2026 is different — Gmail, Yahoo, and Outlook rules
SPF was published in 2006. DKIM, in 2011. DMARC, in 2015. For the first decade of cold email, a rep could ignore all three and still land in the inbox most of the time. That ended in February 2024, when Google and Yahoo rolled out their new bulk-sender rules on the same day — an industry-first coordinated move. Microsoft followed in May 2025 with similar Outlook requirements for consumer inboxes (Outlook.com, Hotmail, Live).
The threshold is 5,000 messages per day to a single provider. That sounds high. In a growth-stage B2B startup with three reps each sending 40 personalized emails a day plus 500 marketing emails a week, the company hits 5,000 to Gmail inside a busy month. Once the threshold is crossed, non-compliant senders do not get a warning. Messages simply stop reaching the primary inbox.
| Provider | Enforcement start | Volume threshold | Auth required | Complaint ceiling | Unsubscribe |
|---|---|---|---|---|---|
| Google (Gmail) | Feb 2024 | 5,000/day to Gmail users | SPF + DKIM + DMARC (p=none min) | ≤ 0.3% (keep under 0.1%) | One-click List-Unsubscribe |
| Yahoo | Feb 2024 | 5,000/day to Yahoo users | SPF + DKIM + DMARC (p=none min) | ≤ 0.3% | One-click List-Unsubscribe |
| Microsoft (Outlook.com, Hotmail, Live) | May 2025 | 5,000/day to consumer inboxes | SPF + DKIM + DMARC (aligned) | Enforced via reputation signals | Functional unsubscribe required |
Auth gap in placement
2.7×
Authenticated senders reach the inbox 2.7× more often than unauthenticated ones. (Validity 2025 Benchmark Report)
Full auth inbox rate
89%
Average inbox placement for domains with SPF, DKIM, and DMARC set up correctly. (InboxKit, 2026)
p=reject adoption
2.5%
Of all domains globally run DMARC at full enforcement. Most stop at p=none. (EasyDMARC 2025 Adoption Report)
The rep takeaway: Gmail and Outlook are getting stricter every quarter. Authentication used to be optional, then became a best practice, then became a requirement for high-volume senders, and is now drifting down to every sender. Getting SPF, DKIM, and DMARC done once, correctly, is the cheapest and highest-leverage move a sales team can make.
SPF in plain English — the TXT record that authorizes your senders
SPF stands for Sender Policy Framework. One TXT record on your domain. It lists the servers allowed to send email on your behalf. When Gmail receives a message, it looks at the Return-Path domain, fetches the SPF record, and checks whether the sending IP is on the list. If it is, SPF passes. If not, SPF fails.
Here is what an SPF record looks like. You publish this as a single TXT record at your root domain (yourdomain.com):
v=spf1 include:_spf.google.com include:sendgrid.net include:mail.zendesk.com ~all
Reading left to right: v=spf1 is the version. Each include: adds another provider's authorized IPs — Google Workspace for your direct sends, SendGrid for transactional, Zendesk for support mail. ~all (soft fail) at the end tells receivers "if a sender is not on this list, treat it with suspicion." Most senders start at ~all (soft fail) and tighten to -all (hard fail) once confident the list is complete.
Two things trip up almost every new sender. First, SPF has a hard limit of 10 DNS lookups per record. Each include: counts as one, and some providers nest includes of their own. A domain with 11+ lookups fails SPF even if every service is legitimate. The fix is "SPF flattening" — tools like EasySPF, Valimail, or RedSift resolve every include into literal IPs, collapsing the record to one lookup. Second, many teams accidentally publish two SPF TXT records. RFC 7208 requires exactly one per domain. Two records means every check fails, silently. Audit with dig TXT yourdomain.com to confirm you have a single SPF record.
DKIM in plain English — the signature Gmail verifies on every send
DKIM stands for DomainKeys Identified Mail. It works like a tamper-proof wax seal. Your email service provider — Google Workspace, Outlook 365, SendGrid, Postmark, whoever — signs every outgoing email with a private cryptographic key. The matching public key lives on your domain as a TXT record. When Gmail receives the message, it pulls the public key, verifies the signature, and confirms two things: (1) the email actually came from a server your domain authorized, and (2) the body and headers were not modified in transit.
DKIM records are published at a selector — a subdomain your ESP gives you. For Google Workspace, it is usually google._domainkey.yourdomain.com. For SendGrid, it might be s1._domainkey.yourdomain.com and s2._domainkey.yourdomain.com. Multiple selectors let you run multiple senders (ESP + transactional + marketing) without collisions. The record itself is a long public key that looks like this:
v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDwXBl...
You do not generate this yourself. Your ESP does. In the admin panel — Google Admin for Workspace, Email API for SendGrid, domain settings for any modern cold-email tool — there is a "Set up DKIM" or "Authenticate domain" button. Click it. The provider spits out a selector and a TXT record value. Paste the value into your DNS panel at the selector subdomain. Wait for propagation. Send yourself a test email and check the headers for dkim=pass.
The part reps miss: every third-party tool sending on your behalf needs its own DKIM setup. If a rep uses Smartlead, Instantly, or Lemlist on top of Google Workspace, the cold-email tool needs DKIM authenticated against its own selector. Otherwise Gmail sees a signed email claiming to be from yourdomain.com where the DKIM signature does not match any published key. That email silently hits the spam folder. Testing per-tool is non-optional.
DMARC in plain English — the policy ladder from p=none to p=reject
DMARC is the instruction layer on top of SPF and DKIM. It says three things: (1) here is the policy for when SPF and DKIM fail — do nothing, quarantine to spam, or reject outright; (2) here is the email address where you should send daily aggregate reports so I can see what is failing; (3) here is how strictly to enforce alignment between the visible From domain and the authentication domains.
A DMARC record lives at a specific subdomain: _dmarc.yourdomain.com. The record is a TXT entry that looks like this:
v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; pct=100; adkim=r; aspf=r;
Translating: p=quarantine routes failing mail to spam. rua=mailto:... is the inbox that receives daily aggregate reports — your visibility into what is failing. pct=100 applies the policy to 100% of failing mail (you can ramp up from 10%). adkim=r and aspf=r set DKIM and SPF alignment to relaxed (the default; "s" is strict).
| Policy | What happens to failing mail | Risk to you | When to use it |
|---|---|---|---|
| p=none | Monitor only | Zero | First 2 weeks — read reports, fix failures |
| p=quarantine | Suspect mail → spam folder | Medium if DKIM or SPF misaligned on a legitimate sender | Weeks 2–6 — once every legit sender passes in reports |
| p=reject | Suspect mail bounced | High if any legit sender fails | Month 2+ — after 14 days of clean reports on p=quarantine |
The global data is sobering. Only 2.5% of all domains run DMARC at p=reject — the strictest enforcement — according to the EasyDMARC 2025 Adoption Report. Among Fortune 500 companies the number jumps to 62.7%, but most small teams stop at p=none and never progress. p=none is compliant with Gmail's baseline rule, but it does not protect against spoofing. Moving to p=quarantine is the realistic target for most sales teams.
DMARC alignment — the hidden rule that breaks most new senders
Alignment is the part every first-time setup gets wrong. Here is the gotcha: an email can pass SPF and still fail DMARC, because DMARC checks not just that SPF passed, but that SPF passed on the same domain as the visible From address. The same goes for DKIM.
A concrete failure. A rep sends a cold email with From: jen@yourdomain.com. The email actually routes through a third-party cold-email tool, and the tool's infrastructure uses its own Return-Path: bounce@smartlead-mailer.net. SPF passes — the IP is on Smartlead's SPF record. But alignment fails — the SPF domain (smartlead-mailer.net) does not match the From domain (yourdomain.com). DMARC reports it as a fail. Quarantine policy kicks in. The email lands in spam.
The fix is usually in the cold-email tool's domain settings. Every modern ESP supports "custom Return-Path" — you point a subdomain like bounce.yourdomain.com as a CNAME to the ESP's bounce host. Now the Return-Path domain aligns with your From domain. SPF passes, alignment passes, DMARC passes. DKIM alignment works the same way — the signing domain (d=yourdomain.com in the DKIM signature) must match the From domain.
Relaxed alignment (the default) means the sending subdomain and the From subdomain just need to share a root — mail.yourdomain.com aligns with sales.yourdomain.com. Strict alignment demands an exact match. Leave it relaxed until you have six months of clean reports and a reason to tighten.
Who actually sets this up — the rep's org chart for DNS
A rep is usually not the person with DNS access. That is a feature, not a bug — DNS changes affect every email the company sends, the website, the API, and every SaaS tool pointing at the domain. The rep's job is to know who owns DNS and how to get the records published fast.
The escalation path by company stage:
- Solo founder / 1–5 person team: you own DNS. It is probably in Cloudflare, Namecheap, GoDaddy, or Google Domains. Log in, add the records yourself, verify in 24 hours.
- 5–25 person company: the CTO or an engineer owns DNS. Send them the three records, a link to the Google sender rules, and ask for a 15-minute window. This is a 20-minute task for someone who knows DNS.
- 25–100 person company: IT or DevOps owns DNS. File a ticket. Attach the records, the rationale (Gmail bulk-sender compliance), and the deadline. Most teams treat this as a standard change request.
- 100+ person company: a security or platform team owns DNS, and change management applies. The deliverability or RevOps lead is your sponsor — they are the one who will greenlight the ticket. Expect a 1–2 week turnaround and a change window.
A copy-paste script for the rep: "Hey — Google and Outlook now require SPF, DKIM, and DMARC on the sending domain or inbox placement drops about 50 points. We're under 5,000/day today but we will cross it this quarter. Can we publish the three TXT records in the next two weeks? I have the exact values from our ESP. Happy to file a ticket." Most DNS owners respond well to concrete asks with business context.
The 20-minute SPF, DKIM, and DMARC setup walkthrough
The full setup, assuming Google Workspace as the primary sender. Swap the provider names for Outlook 365, SendGrid, or Mailgun as needed — the flow is identical.
- 1. Inventory every service sending as your domain. Google Workspace for direct sends. Your marketing tool (Mailchimp, HubSpot). Your transactional provider (Stripe, Postmark). Your cold-email tool (Smartlead, Instantly). Your help desk (Zendesk, Intercom). Each one needs a line in SPF and usually a DKIM selector of its own.
- 2. Publish SPF as a single TXT record on the root domain. Combine every service into one record:
If you exceed 10 DNS lookups, flatten with EasySPF or Valimail.v=spf1 include:_spf.google.com include:mailgun.org include:servers.mcsv.net ~all - 3. Enable DKIM in every sender's admin panel. Google Admin → Apps → Google Workspace → Gmail → Authenticate email. Copy the selector (
google._domainkey) and TXT value. Paste into DNS. Repeat for each other sender's selector (k1._domainkey,mg._domainkey, etc.). - 4. Publish DMARC at
_dmarc.yourdomain.com. Start at p=none:v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; pct=100; - 5. Set up a dedicated inbox for DMARC reports. Use a real mailbox you will actually read — or pipe it into a tool like dmarcian, Postmark DMARC, or EasyDMARC. Raw DMARC XML reports are unreadable without a dashboard.
- 6. Wait 24–48 hours for DNS propagation. Check status with
dig TXT yourdomain.comanddig TXT _dmarc.yourdomain.comfrom your terminal, or use a web tool like MXToolbox. - 7. Send yourself a test email. From your cold-sending setup to a personal Gmail. Open the message, click "Show original." Look for
SPF: PASS,DKIM: PASS,DMARC: PASS. If any fail, the Show Original page tells you which. - 8. Ramp DMARC in stages. Day 1–14 on p=none. Read reports, fix failing senders. Day 15–42 on p=quarantine. Day 42+ on p=reject if the business can absorb the risk. Most sales teams stop at p=quarantine — it satisfies Gmail and blocks spoofers without breaking anything legitimate.
