Email Authentication: The Complete Guide (SPF, DKIM, DMARC and BIMI)
Published · updated
Figures as of 2026-07-28 · methodology v8. Aggregate census data across 276 million graded domains. This is the umbrella guide to the email-authentication stack; each protocol has its own deep-dive linked throughout. See how we grade.
Email authentication is three DNS-based protocols working as one system: SPF says which servers may send for your domain, DKIM signs each message so tampering shows, and DMARC ties both to the address a human actually sees — then tells the world’s mailboxes what to do when the check fails. A fourth, BIMI, is the visible reward at the end: your logo in the inbox. Deployed together and enforced, they make forged email from your domain bounce instead of land. Deployed partially — which is how most of the internet has done it — they change almost nothing. Across 276 million graded domains, 51.25% publish SPF, 25.81% publish any DMARC record, only 11.84% enforce it, and just 2.79% run the complete enforced stack. This guide covers what each protocol contributes, how they interlock, the order to deploy them, and what “done” actually means.
What each protocol contributes
The four standards are often presented as alternatives. They aren’t — each covers a gap the others leave open.
SPF authenticates the sending path. A single DNS TXT record lists the servers allowed to send mail for your domain; receivers check the connecting server against the list. It’s the oldest and easiest of the four, which is why it leads adoption at 51.25%. Its weakness: it checks a technical address (the envelope sender), not the “From” line a person reads — and it breaks when mail is forwarded. See What is SPF — and how do I fix it? for the full treatment.
DKIM authenticates the message itself. Your mail server signs each outgoing message with a private key; the matching public key sits in your DNS under a selector. Receivers verify the signature, proving the message came from a holder of your key and wasn’t altered in transit. Because the signature travels inside the message, DKIM survives forwarding where SPF fails. In the census, we observe DKIM selectors on -29.50% of graded domains.
DMARC is the policy layer that makes the other two mean something. On their own, SPF and DKIM only produce pass/fail results that receivers may quietly note. DMARC adds three things: alignment (the check must relate to the visible From domain — more below), a policy telling receivers what to do on failure (none, quarantine or reject), and reporting, so you can see who is sending as your domain. See What is DMARC? for the policy levels in detail.
BIMI is the trust signal on top. Once DMARC is enforced, you can publish a logo that Gmail, Apple Mail and Yahoo display next to your messages. It does nothing defensive by itself — it’s the visible certificate that the defensive work is finished. What is BIMI? covers eligibility and setup.
How they interlock: alignment is the whole game
Here is the piece most part-finished deployments miss. Every email carries two sender identities: the envelope sender (used for routing and bounces, invisible to the reader) and the header From (what the person sees). SPF checks the first. DKIM checks whatever domain signed the message. Neither, on its own, says anything about the From line — which is exactly the field an impersonator forges.
DMARC closes that gap with alignment: to pass DMARC, a message needs SPF or DKIM to pass for a domain that matches the visible From domain. A phisher can pass SPF trivially — by sending from their own server, with their own envelope domain, and putting your domain in the From line. Aligned DMARC is what makes that trick fail.
Two practical consequences:
- SPF and DKIM without DMARC is plumbing without a lock. The checks run, the results are noted, the forged mail is delivered anyway. 30.9% of all graded domains — 85,070,427 of them — publish SPF but no DMARC, the census’s most common half-finished state. See SPF without DMARC.
- You want both SPF and DKIM under DMARC, not one. DMARC needs only one aligned pass, but real mail flows break each of them in different ways — forwarding kills SPF, some mailing-list rewrites kill DKIM. Two independent paths to a pass is what lets you enforce without bouncing legitimate mail. When DMARC fails while SPF and DKIM both “pass”, misalignment is almost always the reason.
The deployment order, with a verification gate at each stage
The stack has a natural order — each layer is the safety net for tightening the one after it. Rushing the order is how legitimate mail gets bounced; never finishing it is how the internet ended up with 88.16% of DMARC-publishing domains stuck in monitoring. (Setting up a new domain from scratch? There’s a condensed checklist for that.)
- Inventory every legitimate sender. Mailbox provider, newsletter platform, CRM, helpdesk, invoicing tool — anything that sends as your domain. This list is your SPF record and your DKIM to-do list; incompleteness here surfaces as lost mail later. Verify: check each tool’s settings page for its documented SPF include and DKIM setup.
- Publish SPF — one record, ending
~all. A single TXT record with each sender’sinclude:. Start with softfail as the safety margin. Verify: confirm exactly one record exists (two SPF records is an automatic fail), you’re under the 10-DNS-lookup limit, and real mail from every sender passes. Then tighten to-all. - Enable DKIM on every sender. Turn on signing in each platform and publish the public keys they give you. Do this per-sender — for the big two mailbox providers, see the walkthroughs for Google Workspace and Microsoft 365. Verify: send a test to a Gmail account and use “Show original” — it displays SPF, DKIM and DMARC results per message, including the domain each check passed for (that’s the alignment view).
- Publish DMARC at
p=nonewith reporting. One TXT record at_dmarc.yourdomainwith arua=address. This changes nothing about delivery yet — it turns on the instruments. Let reports accumulate for a few weeks. Verify: aggregate reports arrive and show your known senders passing with alignment. Anything legitimate that’s failing is a stage-2 or stage-3 gap — fix it now, while the policy is stillnone. - Tighten to
p=quarantine, thenp=reject. This is the step that actually stops impersonation, and the step most domains never take: of the domains that publish DMARC, only 45.9% have reached enforcement. Move when reports show clean passes; usepct=for a gradual ramp if volume is high. The p=none to reject guide walks the ramp safely. Verify: reports keep flowing and legitimate mail keeps landing; forged mail now bounces or hits spam. - Optional: publish BIMI. With enforcement in place you qualify. SVG logo, a DNS record, and (for Gmail) a Verified Mark Certificate. Verify: send to a Gmail account and look for the logo.
Free throughout, except the optional BIMI certificate. The cost is care, not money.
Common failure modes
The census sees the same handful of mistakes at scale:
- Stopping after SPF. The most common state on the internet: 30.9% of domains have SPF and no DMARC. Fully spoofable.
- Parking at
p=noneforever. Monitoring mode requires nothing of anyone, so nothing pushes domains out of it — p=none is not protection. - Two SPF records. Merging tools’ instructions by adding a second
v=spf1record makes both invalid — two records equals none. - Blowing the 10-lookup limit. Too many
include:chains and SPF returns permerror and is ignored. - Unaligned “passes”. A newsletter platform sending with its own envelope domain and default DKIM signature passes both checks — for its domain, not yours — and your DMARC still fails. The fix is custom domain settings in the platform.
- Forgetting subdomains. DMARC covers them via
sp=, but SPF and DKIM are per-hostname; an unauthenticated sending subdomain is a side door.
What “done” looks like
Done is not “records exist”. Done is: forged mail from your domain is refused, and you’d know within days if that stopped being true. Concretely — one SPF record at -all that passes for every sender; DKIM signing on every platform; DMARC at quarantine or reject with aggregate reports still being read; and, if you want the inbox logo, BIMI on top. That end state is rare: 2.79% of graded domains — the fully protected few — run the complete enforced stack as of 2026-07-28.
Two forces are slowly making this the default cost of doing business by email: Google and Yahoo’s bulk-sender requirements already mandate authentication for volume senders, and deliverability increasingly rewards the authenticated. The domains that treat the four protocols as one system with one finish line — the Stage 6 mindset, where protection is maintained rather than installed — get there weeks after starting. The rest start, stall, and stay spoofable.
Frequently asked questions
Do I need SPF, DKIM and DMARC, or just one of them? All three. SPF and DKIM are the authentication mechanisms; DMARC is the policy that connects them to the visible From address and instructs receivers to act. Any one alone leaves the impersonation door open.
What order should I set them up in?
SPF first, DKIM second, DMARC at p=none third, then tighten DMARC to quarantine/reject once reports show legitimate mail passing. BIMI last, if wanted. Enforcing DMARC before SPF and DKIM are clean is how legitimate mail gets bounced.
How long does full deployment take? The DNS records take hours. The safe path to DMARC enforcement takes weeks — most of it waiting on monitoring reports to confirm every legitimate sender passes with alignment.
Does a domain that sends no email need this?
Yes — parked domains are the easiest to impersonate because no one is watching. The record set is short: SPF v=spf1 -all, an empty DKIM policy, and DMARC p=reject. See parked domains can be spoofed.
Is any of this expensive? No. Every record is a free DNS change; the only optional cost is BIMI’s Verified Mark Certificate. As of 2026-07-28, the gap between the 2.79% who finished and everyone else is effort and sequence, not budget.
Check your email authentication free
See your domain’s SPF, DKIM, DMARC and BIMI status in one scan — privately, and owner-only.
Check your domain → · Fix SPF → · Fix DKIM → · Fix DMARC → · How we grade → · Aggregate data only. Data stored and processed in the EU.