Updated · 10 min read
SPF, DKIM, and DMARC explained for lifecycle marketers
You don't need a DNS engineer to run lifecycle. You do need to understand the three records that decide whether Gmail trusts you. Since 2024, SPF, DKIM, and DMARC are table stakes for any sender over 5,000 messages a day — miss one and deliverability degrades quietly for weeks before anyone notices the revenue dip. Here's the honest version in practitioner language: what each record does, how they interact, and the configuration order that actually works.
By Justin Williames
Founder, Orbit · 10+ years in lifecycle marketing
What each record actually does
SPF (Sender Policy Framework) publishes the servers allowed to send mail on behalf of your domain. One TXT record on your DNS, listing your approved sending IPs and services. When a receiving server gets mail claiming to come from you, it checks SPF and either accepts or treats the mail 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)cryptographically signs the body and headers of every outgoing message. The receiver uses a public key published in your DNS to verify the mail wasn't modified in transit. DKIM doesn't prove you're trustworthy. It proves that if a message is signed as you, it actually came from you.
DMARC (Domain-based Message Authentication, Reporting and Conformance) tells receivers what to do when SPF or DKIM fail. Three policy options: p=none (report only, don't act), p=quarantine (send to spam), p=reject(bounce outright). DMARC also emits daily reports of who's sending mail as you, which is the first time most teams discover there are three services mailing their customers that nobody in the room knew about.
Yes, you need all three. That's been true since Gmail and Yahoo moved the goalposts in 2024 for any sender over 5,000 messages per day. Before then you could probably get away with two. Not anymore.
How the three work together
DMARC is the escalation layer. SPF and DKIM are the evidence layers. Publishing DMARC without fixing SPF and DKIM first is how teams accidentally block their own sends.
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 with the visible From address. That alignment bit is where most teams trip — an ESP can happily sign your mail with DKIM but use its own domain in the signature, which passes DKIM but fails DMARC alignment. Congratulations, your mail is cryptographically valid and also going to spam.
Walk the actual flow. The receiving server gets your message, checks SPF (is the source IP allowed?), checks DKIM (is the signature valid?), checks alignment (does the authenticated domain match the visible From?), then consults DMARC to decide what happens on any failure. Most bulk-sending problems are alignment failures, not signature failures. Every ESP supports custom-domain DKIM — it's the step most teams skip during setup because the default works "well enough" in the wrong sense of the phrase.
Setup order that doesn't break production
3
DNS records to publish: SPF (TXT), DKIM (TXT), DMARC (TXT).
p=none
Always start DMARC in monitoring mode. Only move to quarantine after reports look clean for 2–4 weeks.
2024
Year Gmail and Yahoo made all three mandatory for bulk senders. The grace period is over.
Step 1 — SPF. List every service that sends mail as your domain: your ESP (Braze, Iterable, whoever), your transactional provider (Postmark, SendGrid), Google Workspace if corporate runs on Gmail, and any marketing tools that email users directly. Miss one and mail from that service fails SPF. Keep the record under 10 lookups — SPF has a hard limit and blowing past it silently breaks authentication for every recipient that hits an ambitious resolver.
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. Add each key as a TXT record on a unique selector (e.g. braze._domainkey.mail.yourbrand.com). Verify each service signs with its own selector before you touch anything else. Rotate keys annually as hygiene.
Step 3 — DMARC, in monitoring only. Start with v=DMARC1; p=none; rua=mailto:dmarc@yourbrand.com. Read the reports for 2–4 weeks. Fix whichever services are misaligned. Move to p=quarantine; pct=25 for partial enforcement. Only then 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.
The subdomain strategy that saves you
The single most useful architectural decision in email authentication is splitting sending by subdomain. Marketing on mail.yourbrand.com, transactional on notify.yourbrand.com, corporate human mail on the root yourbrand.com. Each subdomain gets its own SPF, DKIM, and DMARC configuration. Reputation tracks independently.
Here's why this matters the one time it matters. A marketing campaign triggers a complaint spike. Reputation damage stays confined to the marketing subdomain. Corporate email (people-to-people) keeps delivering cleanly. Without the split, a bad campaign week can poison your CEO's ability to get mail to clients — which is exactly the kind of second-order damage nobody models when they're picking an ESP.
Common mistakes and what they cause
SPF too long. The 10-lookup limit trips easily once you've added three or four services. Fix by using include:mechanisms sparingly, flattening nested includes into direct IP ranges where necessary, or consolidating sending services. It's boring work. It's also why 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. 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 reputation scores through Google's eyes. It's free. It's the single best monitoring tool for Gmail deliverability, bar none. Microsoft SNDS covers Outlook and Hotmail on the same basis.Source · GooglePostmaster ToolsFree Google service for monitoring Gmail sender reputation, spam rate, authentication results, and delivery errors.postmaster.google.com
One more worth mentioning because people ask: BIMI. Brand Indicators for Message Identification — displays your logo next to messages in the inbox, needs a Verified Mark Certificate (~$1,500/year) and DMARC at p=quarantine or p=reject. Worth it for brands where inbox recognition meaningfully drives opens. Skip until you're already at DMARC enforcement; there's no use buying the certificate if your DMARC is still in monitoring mode.
Frequently asked questions
- What's the difference between SPF, DKIM, and DMARC?
- SPF declares which IPs are authorised to send mail for your domain (DNS TXT record). DKIM cryptographically signs each outgoing message so receivers can verify it wasn't altered in transit (DNS TXT record with public key). DMARC is the policy layer — it tells receivers how strictly to check SPF/DKIM alignment with the displayed From address, what to do with failures (monitor, quarantine, reject), and sends aggregate reports back. SPF alone proves "these IPs sent it." DKIM proves "this wasn't altered and came from our signing infrastructure." DMARC ties them both to the displayed sender and gives you enforcement.
- Do I need all three of SPF, DKIM, and DMARC?
- Yes, for any serious sender. Since February 2024, Gmail and Yahoo require all three for any sender exceeding 5,000 messages per day to their domains. DMARC at p=none (monitor only) is the minimum; most programs should be at p=quarantine or p=reject once legitimate senders are confirmed in aggregate reports.
- What does DMARC p=reject do?
- DMARC p=reject instructs receiving servers to outright reject any message that fails SPF OR DKIM alignment with the From address. It's the strongest anti-phishing policy a domain can publish — no spoofed mail from your domain will reach inboxes. Prerequisites: DMARC in p=none for 30-60 days first to find legitimate senders failing alignment (billing, ticketing, marketing automation), fix those, escalate through p=quarantine, then p=reject. Jumping straight to p=reject without this audit breaks legitimate mail.
- How do I set up DMARC reporting?
- Add rua=mailto:dmarc-reports@yourdomain.com to the DMARC DNS record. Receiving servers send daily aggregate XML reports on every message they processed from your domain, with pass/fail rates per source IP. Parsing raw DMARC XML is impractical — use a reporting service (Postmark DMARC, Valimail, EasyDMARC, dmarcian) to visualise the data. The reports are how you discover legitimate third-party senders failing authentication before you tighten policy.
- What's a common SPF mistake?
- Too many include: lookups. SPF has a 10-lookup limit — every include: in the record counts, and many SaaS tools chain their own includes that resolve to multiple more. Exceed 10, and SPF fails globally with a permerror. Use an SPF flattener or SPF macro service to consolidate. Another common mistake: forgetting third-party senders (billing platforms, support ticketing, survey tools) that send as your domain — they fail SPF silently and land in spam.
This guide is backed by an Orbit skill
Related guides
Browse allBIMI: the logo-in-the-inbox feature, and whether it's worth the effort
BIMI puts your logo next to emails in Gmail, Apple Mail, and Yahoo. The setup is a slog and the performance lift is modest. Here's what's actually required, what it costs, and whether your program is a candidate for it or not.
Email deliverability — the practitioner's guide
Deliverability isn't a setting. It's the running total of every send decision you've made since you bought the domain. Four pillars hold it up. Break one and the whole program starts leaking.
The unsubscribe page is the most important page in your lifecycle program
The page every lifecycle team ignores is the one quietly deciding sender reputation, suppression-list quality, and the fate of next quarter's deliverability. A short defence of why it deserves the ten-minute rebuild.
Dedicated vs shared IP: the real decision
Every ESP sales conversation pitches the dedicated IP as an upgrade. For most lifecycle programs it isn't — it's a trade, and often a losing one. Here's the volume threshold that actually justifies dedicated, the risks most teams don't anticipate, and when the shared pool is genuinely the better call.
List hygiene: the six-rule policy
List hygiene isn't cleanup; it's a continuous policy that runs automatically. Here's the six-rule policy every lifecycle program should have written down, each tied to a specific deliverability outcome.
Bounce rate management: the thresholds and the fix order
Bounce rate is the easiest deliverability metric to read and the easiest to misread. Here's what each bounce type actually means, the thresholds that trigger real problems, and the fix order when your rate climbs.
Found this useful? Share it with your team.
Use this in Claude
Run this methodology inside your Claude sessions.
Orbit turns every guide on this site into an executable Claude skill — 54 lifecycle methodologies, 55 MCP tools, native Braze integration. Pay what it's worth.