SPF, DKIM, DMARC, and BIMI Made Simple
Email authentication sounds scary and is actually a one-time setup. Get these four records right and inbox providers start trusting your mail.
- Diagnose the deliverability risk described in this lesson
- Apply the appropriate prevention or recovery steps
No prior lesson required.
Authentication establishes whether the systems sending mail for your brand are authorized to do so. It is a prerequisite for dependable delivery, but it does not by itself guarantee inbox placement or revenue. Use the records and verification workflow generated by your sending platform; never paste generic DNS examples into a live domain.
Confirm the platform-generated SPF/DKIM and domain-verification setup, then configure DMARC with a monitored rollout before tightening policy. BIMI is optional and has additional mailbox, logo, and certificate requirements; it is not a promised inbox-logo treatment. Authentication improves identity and policy alignment, while list quality and engagement still determine delivery outcomes.
What do SPF, DKIM, DMARC, and BIMI actually do?
SPF and DKIM provide authentication signals, DMARC publishes an alignment and policy framework, and BIMI can enable logo display in supporting mailbox environments. Exact behavior varies by sender setup, recipient mailbox, and platform.
Skip the DNS jargon. Here is the plain-English version of what these four records do and why you care.
| Record | What it does | Why it matters |
|---|---|---|
| SPF | Publishes authorized sending infrastructure | Helps recipient systems evaluate whether a sender is authorized. |
| DKIM | Adds a cryptographic signature to messages | Lets recipient systems validate signed message handling and domain association. |
| DMARC | Publishes alignment and policy instructions | Helps domain owners monitor and govern unauthenticated mail claiming their domain. |
| BIMI | Publishes brand-indicator information | May support logo display where mailbox and certificate requirements are met. |
Think of it as a chain. SPF and DKIM prove who you are. DMARC decides what happens to anything that fails the check. BIMI is the reward you earn once the first three are solid.
Here is what happens to a single email on its way to a Gmail inbox.
What do SPF, DKIM, DMARC, and BIMI actually do
- 01Your platform sends
Klaviyo (or whatever you use) sends a campaign from your sending subdomain, claiming to be you.
- 02Gmail checks SPF
Is this server on your allowed list? On the list: pass. Unknown server: fail.
- 03Gmail verifies DKIM
Does the signature match? Intact: pass, nothing was altered in transit. Broken: fail.
- 04DMARC applies your policy
Both checks pass: the email moves on toward the inbox. Fail: your policy tells Gmail to reject it.
- 05BIMI renders your logo
With everything passing, your verified logo shows next to the email before anyone opens it.
Structured from the canonical article steps for responsive reading and presenter mode.
What order should you set up SPF, DKIM, DMARC, and BIMI?
Follow the order and exact DNS records your sending platform documents for the sending domain. In practice, verify the platform’s authentication setup first, monitor DMARC before enforcing a stricter policy, and evaluate BIMI only after the underlying authentication and brand-indicator requirements are met. The safe sequence is verification-led, not a generic copy-and-paste recipe.
Do these in sequence. Each one builds on the last, and skipping ahead breaks things.
What order should you set up SPF, DKIM, DMARC, and BIMI
- 01Generate the platform records
Use the active sending platform’s branded-domain or authentication workflow; do not reuse records from a different account or provider.
- 02Publish and verify
Add the exact generated records, wait for DNS propagation, and confirm the platform reports the domain as verified.
- 03Monitor DMARC before tightening
Review alignment and legitimate send sources before moving beyond a monitoring policy.
- 04Evaluate BIMI separately
Confirm current mailbox, logo, and certificate requirements before treating BIMI as a deliverability or branding lever.
Platform-verified workflow, with policy decisions made only after legitimate sending sources are understood.
DMARC has three modes: none (monitor only), quarantine, and reject. If you set it to reject before SPF and DKIM are passing cleanly, you can block your own legitimate email. Run it in monitor mode first, read the reports it sends you, confirm everything passes, then tighten. Rushing this step is how people accidentally take their own mail offline.
Does email authentication really affect deliverability?
Authentication matters because mailbox-provider sender requirements and DMARC alignment depend on it. Google’s bulk-sender guidance includes authentication requirements, but the delivery result still depends on recipient response, content, volume, and list quality. Treat authentication as a prerequisite and verify it after every platform or domain-routing change.
BIMI should be evaluated as a separate brand-indicator implementation. Do not promise logo display or use it as a substitute for authentication, list hygiene, or deliverability monitoring.
What are the most common email authentication mistakes?
The five that break setups most often: publishing two SPF records instead of one, forgetting to republish DKIM after a platform switch, setting DMARC to reject on day one, authenticating the root domain instead of the sending subdomain, and never testing. Each one quietly fails your mail. Here is how to avoid them.
- Publishing contradictory DNS records. Follow the platform’s record generator and resolve conflicts with the domain owner before activation.
- Leaving a platform switch unverified. A new ESP, domain, or routing configuration can change the required records. Re-run the platform verification workflow after the change.
- Enforcing DMARC before mapping legitimate senders. Start with monitoring and review reports before tightening policy.
- Authenticating the wrong send path. Verify the exact branded sending domain and routing configuration the platform is using rather than assuming the root domain is sufficient.
- Never testing the live configuration. Confirm the platform status, send controlled tests, and keep monitoring deliverability after activation.
Get Expert Help
Getting these four records right is a one-time job, and doing it wrong quietly costs you revenue every day it sits broken. Our team sets up and verifies your full authentication stack so your mail lands where it should.
Need help implementing this?
We build and manage complete email & SMS programs for DTC brands. Get a custom plan for your brand.
Apply Now