SPF, DKIM, and DMARC explained for lifecycle marketers

Before the acronyms, the picture. Email was built in the 1980s on the assumption that anyone claiming to be you, was you. Spam happened. Phishing happened. Three patches got bolted on over the years to fix that — and they all answer different questions.

SPF answers "is this server allowed to send mail for this domain?" — the equivalent of a guest list of approved sending machines. DKIM answers "was this message actually written by who it claims, and untouched in transit?" — a tamper-evident wax seal on the envelope. DMARC answers "what should I do if either of those two checks fails?" — the standing instruction the bouncer follows when something doesn't add up.

The three live as TXT records — small chunks of text — published in your domain's DNS, the public address book that tells the internet where your domain lives. When Gmail receives a message claiming to be from you, it looks them up, runs the checks, and decides whether your mail goes to the inbox, to spam, or nowhere at all.

SPF (Sender Policy Framework) is the guest list. One TXT record on your DNS, listing every server and service approved to send mail on your behalf — your ESP (email service provider — the platform you send marketing campaigns from, e.g. Braze, Iterable), your transactional sender, your support tool, anything that emails your customers. Receiving server gets mail claiming to come from you, checks SPF, and either accepts it or treats it as suspect. Simple idea, fiddly execution.Source · GoogleEmail sender requirementsGoogle's 2024 requirements mandating SPF, DKIM, and DMARC for bulk senders above the complaint threshold.support.google.com/a/answer/81126

DKIM (DomainKeys Identified Mail)is the wax seal. Every outgoing message gets cryptographically signed using a private key your ESP holds; the matching public key sits in your DNS for receivers to verify against. If a single character of the message changed in transit, the seal breaks and DKIM fails. Worth being precise about what DKIM proves and what it doesn't — it doesn't prove you're a trustworthy sender. It only proves that if a message is signed as you, it really came from your sending infrastructure and arrived intact.

DMARC (Domain-based Message Authentication, Reporting and Conformance) is the standing instruction. It tells receivers what to do when the SPF or DKIM checks fail, and it asks them to send back a daily report of who tried to send mail as you. Three policy options, in increasing strictness: p=none (just report, don't act), p=quarantine (drop failures into spam), p=reject (bounce them outright). The reports are usually how teams discover for the first time that there are three or four services mailing their customers nobody in the room knew about.

Yes, you need all three. Has been true since Gmail and Yahoo moved the goalposts in February 2024 for any sender over 5,000 messages per day to their domains. Before then, two out of three was survivable. Not anymore.

The three records run in sequence, and the gotcha lives in step three. SPF verifies the sending server. DKIM verifies the message contents. DMARC checks that at least one of them passed AND that the authenticated domain aligns — i.e. matches — the visible From address the recipient actually sees. That alignment bit is where most teams trip.

Worked example: an ESP can happily sign your mail with DKIM but use its own domain (esp-tracking.com) in the signature instead of yours. The signature is mathematically valid. DKIM passes. The recipient sees hello@yourbrand.com, the signed domain says esp-tracking.com, DMARC alignment fails. Your mail is cryptographically valid and going to spam. Congratulations.

Walk the actual flow once. The receiving server gets your message, checks SPF (is the source IP on the guest list?), checks DKIM (is the seal intact?), checks alignment (does the sealed domain match the visible From?), then consults DMARC for the verdict on any failure. Most bulk-sending problems are alignment failures, not signature failures. Every ESP supports custom-domain DKIM — signing with your domain rather than theirs — and it's the step most teams skip during setup because the default works "well enough" in the wrong sense of the phrase.

Do this in order. The order matters because each record builds on the last, and a confident DMARC policy on top of a half-finished SPF will silently bin your own mail.

Step 1 — SPF.List every service that sends mail as your domain: your ESP (Braze, Iterable, Klaviyo — whoever), your transactional provider (Postmark, SendGrid), Google Workspace if corporate runs on Gmail, and any marketing tools that email users directly (survey platforms, ticketing, billing). Miss one and mail from that service fails SPF, lands in spam, and nobody finds out until the support team asks why customers aren't getting receipts. Keep the record under 10 DNS lookups — SPF has a hard limit there, and going past it silently breaks authentication for every recipient whose mail server enforces the limit (most of them do).

Step 2 — DKIM. Each service publishes its own DKIM public key. Braze gives you yours through the sending-domain configuration; Google Workspace has a separate flow; Postmark generates one per server. Add each key as a TXT record on a unique selector — a label that lets multiple keys coexist on the same domain — for example braze._domainkey.mail.yourbrand.com. Verify each service signs with its own selector before touching anything else. Rotate keys annually as basic hygiene.

Step 3 — DMARC, monitoring only. Start with v=DMARC1; p=none; rua=mailto:dmarc@yourbrand.com. The rua tag is where Gmail, Yahoo and the rest send their daily aggregate reports. Read the reports for 2–4 weeks. Find every legitimate sender that's currently failing alignment and fix it. Move to p=quarantine; pct=25 for partial enforcement on a quarter of failing mail. Only after a clean week there, escalate to p=reject. Do not hot-swap p=none to p=reject. That's the version of this project where you block the CEO's mail to the board on a Thursday afternoon. Don't be the person who did that.

The single most useful architectural decision in email authentication is splitting your sending by subdomain. Marketing on mail.yourbrand.com, transactional (receipts, password resets) on notify.yourbrand.com, corporate human mail on the root yourbrand.com. Each subdomain gets its own SPF, DKIM, and DMARC. Sender reputation — the score mailbox providers keep on every sending domain, basically your credit rating with Gmail — tracks independently per subdomain.

Here's why this matters the one time it matters. A marketing campaign goes out and triggers a complaint spike — too many recipients hitting "mark as spam". Reputation damage stays confined to mail.yourbrand.com. Corporate email — your CEO emailing a client, your support team replying to a ticket — keeps delivering cleanly because it's a different sending identity entirely. Without the split, one bad campaign week can poison the CEO's ability to get mail to the board. That's the kind of second-order damage nobody models when they're picking an ESP, and exactly the kind your CRO will care about loudly when it happens.

Four. Not three, not five. These are the ones that come up on every audit:

SPF too long. The 10-lookup limit trips easily once you've added three or four services — many SaaS tools chain their own include: mechanisms which resolve to multiple more behind the scenes. Fix by using include:sparingly, flattening nested includes into direct IP ranges, or consolidating sending services. Boring work. Also the reason half the programs in your peer group are quietly failing auth on a fraction of their mail and don't know it.

DKIM signing with the ESP's domain instead of yours. Passes DKIM. Fails DMARC alignment. Quiet disaster — the worst kind, because everything looks fine until you check the DMARC reports and realise the failure rate has been 40% for six months. Every ESP supports custom-domain DKIM; the step is in the sending-domain setup and it takes ten minutes.

DMARC p=reject on day one. Don't. Always p=none first. The Deliverability Management skill walks the full reputation and authentication story end to end if you want the deeper version.

Forgetting Google Postmaster Tools.Once auth is set up, register your sending domain with Postmaster Tools to see your sender reputation through Google's own eyes — spam rate, IP reputation, domain reputation, authentication pass rates. Free. The single best monitoring tool for Gmail deliverability, bar none. Microsoft SNDS (Smart Network Data Services) does the same job for Outlook and Hotmail.Source · GooglePostmaster ToolsFree Google service for monitoring Gmail sender reputation, spam rate, authentication results, and delivery errors.postmaster.google.com

One bonus thing worth mentioning because it comes up: BIMI — Brand Indicators for Message Identification. The bit of plumbing that displays your brand logo next to your messages in supported inboxes. Needs a Verified Mark Certificate (around $1,500/year) and DMARC at p=quarantine or p=reject as a prerequisite. Worth it for brands where inbox recognition meaningfully drives opens. Skip until you're already at DMARC enforcement — there's no point buying the certificate while DMARC is still in monitoring mode, because BIMI won't render anyway.

If you have nothing in place: publish SPF this week, DKIM next week, DMARC at p=none the week after. Don't go faster — the reports from each step inform the next.

If you have all three but haven't looked at DMARC reports in six months: pull the last fortnight, find the senders failing alignment, fix them, then move to p=quarantine; pct=25. If you're still on p=none after a year of reports, you're running an auth posture that gives you the reporting upside with none of the protection. Move it on.

If you're sending marketing from your root domain: split it. mail.yourbrand.com for campaigns, this quarter, before the next big send. The day a campaign drags your CEO's mail into spam is the day you wish you'd done it last quarter.

And register Postmaster Tools today. It's a five-minute job and you can't fix what you can't see.