SPF, DKIM, DMARC: Why Each One Exists (and How to Verify Your Setup)

SPF, DKIM and DMARC are the three protocols that authenticate who sent an email — and each one exists because attackers broke the one before it. SPF decides which servers may send for a domain. DKIM proves a domain signed a message and it wasn't altered. DMARC binds both of them to the domain your recipients actually see — and tells receivers what to do when the binding fails.

Most guides treat these as three checkboxes on a setup page. They make a lot more sense as what they really are: forty years of an arms race, compressed into DNS records. Understand the attacks, and the configuration becomes obvious.

Why was email built without authentication?

Because in 1982, there was no one to defend against. SMTP (RFC 821) was designed for ARPANET — a small network of universities and research labs where everyone knew everyone. The protocol took every claim at face value: any server could declare any MAIL FROM, write anything in the From header, and the rest of the network played along. Open relays — servers that forward anyone's mail anywhere — weren't a vulnerability. They were considered good citizenship.

Then the internet got big, and strangers arrived. The same openness that made email spread made it the perfect channel for spam and, later, phishing: send as anyone, from anywhere, at zero cost. Every authentication protocol since has been a patch on email's original sin — it was designed for a world where everyone was trusted.

SPF: who may send for this domain?

The first abuse to get out of hand was bare-faced envelope forgery: a spammer connects to a mail server and claims to be sending for any domain they like. By the early 2000s this was industrial-scale.

SPF (formalized around 2003–2004, now RFC 7208) was the first answer: let the domain owner publish, in DNS, the list of servers allowed to send for that domain. SPF answers one question: is this IP allowed to send for the domain in the bounce address? Connect claiming to be a bank from a botnet IP, and the receiver can now check the bank's list and see you're not on it.

Two loopholes remained. First, SPF checks the return-path — the invisible bounce address — not the From header humans read. A phisher can pass SPF with their own domain while the visible From still says your brand. Second, forwarding breaks it: when a mailbox forwards your mail, it arrives from a server your SPF record never heard of. The first wall was real, but it guarded a door nobody looked at.

DKIM: can a domain prove it stands behind this message?

The next move came from cryptography. DKIM — short for DomainKeys Identified Mail, a mid-2000s merger of Yahoo's DomainKeys and Cisco's Identified Internet Mail (now RFC 6376) — puts a digital signature on the message itself — over the headers and body — tied to a signing domain. The receiver fetches the public key from that domain's DNS and verifies. DKIM answers a different question: did this domain actually sign this message, and did it arrive unaltered?

That solved two of SPF's problems at once. A signature travels with the message, so forwarding doesn't break it. And tampering with the content breaks the math.

But one loophole remained, and it's the one that still burns senders today: the signing domain can be anything. DKIM proves that some domain took responsibility — it says nothing about whether that domain is the one your recipient sees. An attacker's message signed with the attacker's own domain passes DKIM perfectly. So does your marketing platform's shared domain, which is less dramatic but matters more to you.

DMARC: does the sender own the name the recipient sees?

By 2011 the mailbox providers — the ISPs — had had enough. Gmail, Microsoft, Yahoo, AOL and a group of banks and payment companies sat down and built DMARC (published 2012, standardized as RFC 7489 — the same document that defines the reports — Pt. 1 is the field-by-field guide to reading DMARC reports).

DMARC adds the three things SPF and DKIM never had:

1. Alignment — the passing domain must match the From domain the recipient sees. Not "some domain passed" — your visible name must be the one that passed.
2. Policy — the domain owner tells receivers what to do when alignment fails: none (just watch), quarantine (spam folder), reject (drop it at the door).
3. Reporting — receivers report back what they saw, daily. Authentication stopped being write-only.

Here's why this mattered more than it looks: alignment is what makes a domain identifiable at the receiver. Before DMARC, a receiver couldn't reliably tie incoming mail to the brand domain you see — so reputation had to attach to IP addresses. DMARC is the layer that made domain reputation possible. Identity first, reputation second — that's Pt. 3.

What changed in 2024: the rules became mandatory

For a decade, all three were "best practice" — which in practice meant optional. In February 2024, Gmail and Yahoo made SPF, DKIM and DMARC mandatory for anyone sending more than ~5,000 messages a day, alongside one-click unsubscribe and a spam-rate ceiling. What the ecosystem couldn't get by asking, it got by requiring. That's how the arms race ends when the receivers win: not by deleting spam, but by making identity non-negotiable.

The whole chain in one table

Or in one breath: SPF says who may send. DKIM says a domain stands behind this message. DMARC says that domain must be the name the recipient sees — here's what to do when it isn't, and I'll report back what happened.

How do you verify your own setup? (the 20-minute audit)

History lesson over — now the practical part. In most audits I run, the sender opens with "our authentication is fine — everything passes." By the end, we've usually found something that passes without being aligned. This is the exact sequence I use; it takes about twenty minutes.

One bit of vocabulary before we start, because everyone mixes these up: your ESP is your email service provider — the platform that sends for you (Klaviyo, SendGrid, Braze). The ISPs are the other side of the table — the mailbox providers (Gmail, Yahoo, Microsoft) who decide where your mail lands.

Step 1: Pull your DNS records (2 minutes)

If you've ever used an online DMARC checker, this is all it does behind the page — three DNS lookups. Running them yourself takes the same two minutes and tells you more: you see the raw records instead of a green badge.

What you're looking for:

• One SPF record, not two. Two v=spf1 records = SPF breaks entirely. Multiple ESPs → merge them into one record.
• Count your lookups. SPF allows 10 DNS lookups total (include:, a, mx each count, chained includes stack). Over 10 = permerror, and SPF fails for everything.
• DMARC has rua=. Without a reporting address you're flying blind. p=none without rua is a monitor that isn't plugged in.

Step 2: The Gmail "Show original" walkthrough (5 minutes)

DNS records are configuration. What matters is what actually arrives. Send yourself a real campaign — an actual marketing email, not a test from your ESP's editor — open it in Gmail, three-dot menu → Show original.

The summary at the top shows SPF / DKIM / DMARC. Most people stop here if all three say PASS. Don't. Scroll into the raw headers and find three fields:

Now the two alignment questions:

1. SPF alignment: is the Return-Path domain the same as (or a subdomain of) your From domain? In this example: no — it's the ESP's shared bounce domain. SPF passes, SPF alignment fails.
2. DKIM alignment: is the d= domain your From domain? Here: no — the ESP signed with its own domain. DKIM passes, DKIM alignment fails.

DMARC only needs one of the two legs, so this setup can still show "DMARC PASS" — while being one ESP infrastructure change away from total failure. (You just saw why, in the history above: pass and aligned are different checks, because the protocols were built to answer different questions.)

Step 3: Fix what's misaligned

Fix SPF alignment — set up a custom bounce domain. Every major ESP supports this (Klaviyo, SendGrid, Braze, Customer.io all document it). You delegate a subdomain like bounce.yourdomain.com, the ESP uses it as the Return-Path, and SPF alignment snaps into place. Ten minutes of DNS, permanently better.

Fix DKIM alignment — sign with your own domain. In your ESP's settings there's almost always a "custom DKIM" or "branded sending domain" option: they give you 1–3 CNAME/TXT records to publish, and afterwards d=yourdomain.com. If your ESP doesn't offer this, that alone is a reason to reconsider the ESP.

Fix DMARC visibility, then enforce. Minimum viable record:

And here's where I disagree with most setup guides: you don't need weeks of monitoring or a pct= ramp. The cadence I run with clients — day 1 publish the record, day 2 read the first reports and fix any legitimate sender that's failing (usually a platform that was never authenticated), day 3 go straight to p=reject. The reports tell you who your senders are; that's the whole point of learning to read DMARC reports. Once you can see, enforce. Move at that pace and you're ahead of most of the industry: in a check of 34 top-traffic brands' real mail, only 57% enforce p=reject.

Step 4: Repeat for every sending source

Your marketing ESP is one sender. Also check: your transactional sender (order confirmations often run through a different service), your support desk (Zendesk/Intercom/Gorgias), review tools, loyalty platforms, regional storefronts. Each one sends as you; each needs its own SPF include and DKIM alignment. The forgotten ones are the shadow senders that DMARC reports exist to surface.

The checklist

If all six boxes are ticked, your authentication is genuinely fine — better than most senders I audit.

Authenticated — so why aren't you in the inbox yet?

Everything above gets you identified. It says nothing about whether Gmail trusts you. Identification is binary — the name checks out or it doesn't. Trust is earned over weeks, from complaint rates and engagement, and it's tracked as your domain reputation. That's the next layer, and the next part: how Gmail scores your domain, and how to climb back. And if what brought you here is a Gmail open rate that's already sliding, skip ahead to the step-by-step diagnostic workflow.

FAQ