Email authentication protocols: SPF, DKIM, DMARC, ARC and BIMI in one map

SPF: first drafted in the early 2000s, standardized as RFC 7208 in 2014. DKIM: RFC 6376, 2011, merging two earlier signing schemes. DMARC: RFC 7489, 2015, replaced in May 2026 by RFC 9989 and two companion reporting RFCs. ARC: RFC 8617, 2019, still formally experimental. BIMI: a working-group draft that mailbox providers adopted ahead of standardization. That short ledger is the entire protocol surface of email authentication, and the dates matter, because each protocol exists to patch a gap the previous ones left open.

This guide is the inventory: what each protocol proves, what it cannot prove, which ones mailbox providers now require, and how the five fit together into a single chain of custody for your domain name. For the story of why SMTP needed patching at all, start with email authentication; for a setup-order walkthrough of the core three, see SPF, DKIM and DMARC explained. This page is the reference layer above both.

SPF: authorizing servers

SPF is a TXT record listing the servers allowed to send mail for a domain. A receiving server takes the connecting IP, looks up the SPF record of the domain in the envelope sender, and checks whether that IP is on the list. The record's final qualifier declares how strongly to treat everything not listed, which is where results like softfail come from.

What SPF proves is narrow: this IP was authorized by that domain. Its two structural weaknesses drove the protocols that followed. It breaks on forwarding, because the forwarder's IP is not in your record. And it checks the envelope domain, which recipients never see, so a passing SPF says nothing about the From line in the mail client. The protocol also carries an internal budget, a ten-DNS-lookup limit that overgrown records exceed, and a hard failure mode, permerror, for records that cannot be parsed at all. The SPF checker evaluates all of this in one pass.

DKIM: signing messages

DKIM takes the opposite approach: instead of authorizing machines, it signs messages. The sending server computes a cryptographic signature over the message body and selected headers, and publishes the public key in DNS under a selector. Any receiver can fetch the key and verify that the message was signed by the domain and not altered since.

Because the signature travels inside the message, DKIM survives forwarding, which SPF cannot. Its blind spot is the mirror image of SPF's: the signing domain (d=) lives in a technical header, and nothing in DKIM alone requires it to match the From address a human reads. A message can carry a valid DKIM signature from a domain that has nothing to do with its visible sender. Verify a domain's keys with the DKIM checker.

DMARC: connecting proof to the visible sender

DMARC is the protocol that closes both blind spots at once. It adds a single question on top of SPF and DKIM: does the domain that passed authentication align with the domain in the From header? SPF pass with SPF alignment, or DKIM pass with DKIM alignment, yields a DMARC pass. Neither aligned, and the domain's published policy tells receivers what to do: nothing (p=none), spam-folder it (quarantine), or refuse it (reject).

DMARC also gives the domain owner eyes: aggregate reports from receivers showing every source sending under the domain's name and how each fared. That reporting loop is what makes safe policy tightening possible, and it is the working method in how to set up DMARC. Inspect any domain's current record with the DMARC checker or build one with the DMARC generator.

ARC: preserving results through intermediaries

DMARC created a new casualty: legitimate intermediaries. A mailing list that adds a footer breaks the DKIM signature; a forwarder breaks SPF. The final receiver sees a DMARC failure on mail the original sender authenticated perfectly, a failure shape unpacked in DMARC fail.

ARC (Authenticated Received Chain, RFC 8617) is the patch for that. Each intermediary records the authentication results it observed on arrival, seals them with its own signature, and passes the chain along. The final receiver, finding DMARC broken, can consult the chain and see that the message authenticated cleanly before the mailing list touched it, then decide to honor that original result. Two things keep ARC in a different category from the core three. It is trust-based: an ARC seal is only as good as the receiver's opinion of the sealer, since any intermediary can attest to anything. And it is implemented by large providers rather than configured by senders. There is nothing to publish in your DNS for ARC; it matters to you mainly as the reason forwarded mail through major providers fails DMARC less often than it otherwise would.

BIMI: the visible reward

BIMI (Brand Indicators for Message Identification) is not an authentication protocol so much as authentication's prize: a DNS record pointing to your logo, which participating mailbox providers display next to your messages. The catch is the entry requirement. BIMI only activates for domains with DMARC at an enforcement policy, quarantine or reject, and major providers additionally require a mark certificate attesting to your rights in the logo (Gmail accepts Verified Mark Certificates and, more recently, Common Mark Certificates). That gating is deliberate: the logo is meant to be unforgeable precisely because everything under it is enforced. If your DMARC work is done, the BIMI checker shows whether a record is valid.

Which of these you actually need

The requirements stopped being optional in 2024. Google and Yahoo require SPF or DKIM from every sender, and all three of SPF, DKIM and DMARC (minimum p=none) from bulk senders, with an aligned From domain. The enforced details, thresholds and error codes are kept current on our Gmail, Yahoo and Outlook requirement pages.

So the practical tiering looks like this:

1. SPF + DKIM: mandatory. Both, not either, in practice, since each covers the other's failure modes.
2. DMARC: mandatory for bulk senders, advisable for everyone, because it is the only protocol that protects the address your recipients actually see.
3. ARC: nothing to configure. Provider-side machinery.
4. BIMI: optional, a branding layer you earn after DMARC enforcement, with a certificate cost attached.

One run of the email authentication checker shows where a domain stands on all of it, and the email deliverability score folds authentication into the wider setup picture.

What authentication does and does not buy

Worth stating plainly, because vendors blur it: these protocols prove identity, not virtue. A spammer with a fresh domain can pass all three core protocols in an afternoon. What authentication buys is attribution: your mail is provably yours, so the reputation it earns attaches to your domain and compounds, and nobody else can spend that reputation or burn it in your name. Placement itself is then decided by how recipients receive your mail, which is the territory of why emails go to spam.

Related guides

• SPF, DKIM and DMARC explained — the setup-order walkthrough of the core three
• Email authentication — why SMTP needed this repair stack at all
• How to set up DMARC — the monitoring-first rollout method
• Email authentication checker — one-pass verdict on SPF, DKIM and DMARC for any domain
• Gmail sender requirements — which protocols are enforced, at what volume
• DMARC fail — reading the failure that ARC exists to soften

About this guide

Written by InboxRatio Editorial. Protocol mechanics are drawn from the specifications themselves (RFC 7208, RFC 6376, RFC 9989, RFC 8617 and the BIMI drafts); provider requirements from Google's and Yahoo's published sender documentation. No vendor sponsorship influences it.

Methodology

InboxRatio's benchmark sends real campaigns through the platforms we review to a controlled seed list and records where each message lands. This guide draws on published specifications and provider documentation rather than our measurements; the testing protocol is documented in how we test and our source rules in sources.

Last updated

10 September 2026. Protocol status and provider requirements reviewed quarterly.

Frequently asked questions

What are the main email authentication protocols? Three core protocols: SPF (authorizes sending servers by IP), DKIM (cryptographically signs messages) and DMARC (requires one of them to align with the visible From domain and sets policy for failures). ARC preserves authentication results across forwarders, and BIMI displays a verified logo for domains with enforced DMARC.

Do I need all of SPF, DKIM and DMARC? For bulk sending to Gmail and Yahoo, yes, all three are required with an aligned From domain. Below bulk thresholds the letter of the requirement is SPF or DKIM, but running all three is the practical standard, since each protocol covers failure modes the others miss.

What is ARC in email authentication? Authenticated Received Chain (RFC 8617): a mechanism letting each forwarding hop seal the authentication results it observed, so the final receiver can honor a message's original SPF/DKIM/DMARC status after forwarding broke it. It is implemented by mailbox providers; senders configure nothing.

What is BIMI and is it worth it? A DNS record that lets participating providers show your logo next to authenticated mail. It requires DMARC at quarantine or reject, and Gmail additionally requires a paid mark certificate. It changes nothing about filtering; treat it as branding earned by finished authentication work.

Does passing authentication stop mail going to spam? No. Authentication establishes who you are; placement is decided by reputation and recipient response built on top of that identity. Authenticated mail from a distrusted sender still lands in spam, which is why the diagnostic order starts at authentication but never ends there.

How do I check which protocols my domain has? Run the domain through the email authentication checker for SPF, DKIM and DMARC in one pass, then send a message to a mailbox you control and read the Authentication-Results header with the email header analyzer to see a real receiver's verdict.

Five protocols, one job: making your domain name mean something to machines. Start by finding out which ones your domain already speaks, with the email authentication checker.