Email Authentication Explained: SPF, DKIM, DMARC, and BIMI
If your carefully written campaigns keep landing in spam, the cause is usually not your copy. It's authentication. Since Gmail and Yahoo's bulk-sender rules kicked in back in February 2024, and Microsoft followed in May 2025, unauthenticated email quietly stopped reaching inboxes at scale.
This guide explains the four protocols that decide whether your mail is trusted — SPF, DKIM, DMARC, and BIMI — without the DNS jargon. By the end you'll know what each one does, why each one matters, and the order to set them up.
Why authentication exists at all
Email was invented in the 1970s with no built-in way to verify who a message came from. Anyone could type any "From" address and send it. That hole is why spam and phishing work.
Authentication fixes the hole by letting domain owners publish public rules about who's allowed to send on their behalf, and letting inbox providers check those rules before deciding what to do with the message.
According to Email on Acid's 2025 survey, only 42.5% of senders could confirm they had DMARC configured, with another 38.8% unsure. That gap is exactly where phishing thrives — and exactly why Gmail, Yahoo, and Microsoft have turned authentication into a hard requirement rather than a suggestion.
SPF: the list of who's allowed to send for you
SPF stands for Sender Policy Framework. It's a short record you publish in your domain's DNS that lists which mail servers are permitted to send email on your domain's behalf.
Mailgun describes it well: think of SPF as a list of who's allowed to use your company letterhead. When a receiving server gets a message claiming to be from your domain, it checks your SPF record to see whether the sending server is on the approved list. If it's not on the list, the message is flagged — or dropped.
SPF only checks the server-level envelope sender, not the visible "From" address a human sees. That distinction matters. On its own, SPF isn't enough to stop modern phishing — a spoofed display name slips straight past it. That's DMARC's problem to solve.
The mistakes people make with SPF are usually invisible until something breaks. Hitting the 10-DNS-lookup limit silently invalidates the whole record. Adding a new sending service (a CRM, a transactional tool, a helpdesk) without updating SPF means that service's emails fail. And +all anywhere in the record effectively authorizes every server on the internet — which defeats the purpose entirely.
DKIM: the wax seal on every message
DKIM stands for DomainKeys Identified Mail. It adds a cryptographic signature to every outgoing email — the receiving server uses a public key published in your DNS to verify the signature matches.
Think of it as a wax seal on an envelope. If the seal is intact when the letter arrives, you know two things: it really came from the sender, and nobody tampered with it in transit. DKIM does the same job, but for email headers and body content.
Where DKIM falls short: it doesn't tell the receiving server what to do if the signature is missing or invalid. That's not DKIM's job. DKIM proves authenticity; DMARC decides what happens when authenticity fails.
A few things to get right from the start. Each sending service should have its own DKIM selector — don't reuse the same key across your marketing tool, your transactional email provider, and your CRM. Use 2048-bit keys (1024-bit is still tolerated but increasingly flagged). And rotate keys annually — it's a five-minute task that's easy to skip until it matters.
DMARC: the policy that ties SPF and DKIM together
DMARC stands for Domain-based Message Authentication, Reporting and Conformance. It does two things:
- Tells receiving servers what to do when a message fails SPF or DKIM alignment (deliver anyway, quarantine to spam, or reject outright)
- Sends you aggregate reports showing who is sending mail claiming to be from your domain
DMARC is the enforcement layer. Without it, SPF and DKIM results are just information receiving servers can choose to ignore.
The three DMARC policies
- p=none — monitor only; receivers take no action on failures
- p=quarantine — failures land in spam
- p=reject — failures are bounced
How to roll it out safely
Jumping straight to p=reject breaks legitimate mail you forgot about. The standard safe rollout, recommended across Email on Acid, Mailgun, and the DMARC specification itself:
- Publish p=none for 2–4 weeks and review the reports
- Fix any legitimate senders that fail alignment
- Move to p=quarantine for another 2–4 weeks
- Move to p=reject once you're confident nothing legitimate is failing
Skipping the monitoring phase is the single most common way businesses accidentally block their own invoices and order confirmations.
Why 2026 makes this urgent
Gmail and Yahoo require DMARC for any sender pushing more than 5,000 messages a day to their users. Microsoft has rolled out 550 5.7.515 rejections for high-volume DMARC failures. "We'll get to it later" is no longer a viable position for anyone running real email campaigns.
BIMI: the payoff for doing everything right
BIMI stands for Brand Indicators for Message Identification. It lets your verified brand logo appear next to your emails in supporting inboxes — Gmail, Apple Mail, Yahoo, and Fastmail all support it.
BIMI is the smallest of the four protocols in technical terms but the most visible to subscribers. A logo beside the sender name is an instant trust signal: the recipient knows at a glance that the message is really from you.
What it requires
- DMARC at p=quarantine or p=reject (monitoring only isn't enough)
- An SVG logo hosted publicly
- For most inbox providers, a Verified Mark Certificate (VMC) — essentially a trademarked-logo check from a certificate authority
What it doesn't do
BIMI doesn't improve deliverability on its own. It's a visual reward for the authentication work you've already done — not a shortcut.
The order to set them up
If you're starting from zero, work in this sequence:
- SPF first — takes minutes and is the baseline every receiver checks
- DKIM next — your email provider gives you the record; publish it
- DMARC at p=none — start collecting reports before enforcing anything
- Fix the reports — get every legitimate sender aligned
- DMARC at p=quarantine, then p=reject — escalate over weeks, not days
- BIMI last — only once DMARC is enforced and you have the logo assets
Skipping ahead breaks things. The sequence exists because each protocol builds on the previous one's signals.
Frequently asked questions
Do small senders really need all four?
SPF, DKIM, and DMARC — yes, regardless of volume. Gmail and Yahoo's bulk-sender thresholds only determine when enforcement kicks in for your domain, but unauthenticated mail looks suspicious to every inbox provider. BIMI is optional and most useful for brands whose recipients visually recognise them.
How long does DMARC take to implement safely?
Budget 6–8 weeks from first publishing p=none to reaching p=reject. Rushing it is the main cause of self-inflicted deliverability outages.
Can my email marketing tool handle this for me?
Most platforms handle SPF and DKIM automatically when you verify your sending domain. DMARC is almost always your responsibility because it's published at the domain level, not the per-tool level.
What's the difference between SPF and DKIM?
SPF checks whether the sending server is authorised. DKIM checks whether the message itself is intact and signed by your domain. Both can pass or fail independently — which is why DMARC requires at least one of them to align with the visible "From" address.
Is BIMI worth the cost of a Verified Mark Certificate?
For consumer-facing brands that rely on recognition in the inbox, usually yes. For small B2B senders or newsletters, the return is smaller. Get DMARC at p=reject first — the deliverability gains are much larger than the logo.
Final thoughts
Authentication isn't glamorous work. Nobody opens a DNS editor for fun. But in 2026 it's the difference between your emails getting opened and your emails quietly disappearing.
Start with SPF and DKIM this week. Publish DMARC at p=none next week. Read the reports. Everything else follows from there.