Email authentication: what to set up, in what order

Four protocols decide whether mail claiming your domain gets believed: SPF, DKIM, DMARC, and, for a logo rather than for delivery, BIMI. Three of them are effectively mandatory now. Gmail has required authentication from bulk senders since February 2024 and moved to outright 550 rejections of unauthenticated mail in November 2025; Microsoft began rejecting non-compliant bulk mail to its consumer inboxes in May 2025. This article is the map of the series: what each protocol proves, which ones you need at your size, and the order that avoids breaking your own mail.

Authentication is the entry fee, not the whole game; complaint rates, list hygiene, and volume ramps live in our email deliverability handbook. But it is the part with hard cutoffs and error codes, so it comes first.

The four protocols in one table

The one-paragraph versions, each with its full article:

SPF publishes the list of servers allowed to send for your domain. It is one TXT record with a hard 10-DNS-lookup budget, and it checks the hidden envelope sender rather than the From address your reader sees. It also fails on every forwarded message by design, which is why it can never be the only check.

DKIM signs each message with a private key and publishes the public key in DNS under a named selector. The signature travels inside the message, so it verifies after forwarding, which makes it the sturdiest protocol of the four. Use 2048-bit keys in 2026.

DMARC is the enforcement layer: it requires SPF or DKIM to align with the visible From domain, publishes your policy for failures (none, quarantine, or reject), and sends you reports about everyone claiming to be you. Run the none-to-reject progression as a staged project; the linked guide has exit criteria for each phase.

How the first three interlock, including the alignment concept and a full worked DNS example, is the subject of SPF, DKIM, and DMARC as one system. If you read one piece of the series, read that one.

BIMI, honestly

BIMI (Brand Indicators for Message Identification) displays your logo next to your messages in supporting inboxes, Gmail and Yahoo among them. It is the only protocol here that does nothing for delivery. It is a brand-impersonation defense and a vanity layer, in that order, and the prerequisites are steep:

• A DMARC policy at enforcement: quarantine (at 100%) or reject. p=none disqualifies you.
• Your logo in SVG Tiny PS format, published at a default._bimi TXT record.
• For Gmail to show the logo, a certificate: a Verified Mark Certificate (VMC), which requires your logo to be a registered trademark, or the newer Common Mark Certificate (CMC) for logos with 12+ months of prior use. The BIMI Group's issuer page still names two authorities, DigiCert and Entrust, but Entrust stopped issuing mark certificates in May 2025 after selling its public certificate business to Sectigo, so DigiCert is the practical choice. Its listed price is $1,416 per certificate per year (digicert.com, July 2026).

Our position: BIMI is worth it for consumer brands that are heavily phished, because the missing logo becomes a spoofing tell, and for everyone else it is a line item that buys a small avatar. Do not spend certificate money before your DMARC reports are clean at p=reject. The enforcement requirement means BIMI's real gift to the ecosystem is bribing brands into finishing their DMARC rollout, which is a decent trade.

What to set up, at what size

Two notes on that table. The 5,000/day threshold is Gmail's definition of a bulk sender, and it decides when the extra requirements (one-click List-Unsubscribe, the 0.3% spam-complaint ceiling) become mandatory. It is not the point where authentication starts to matter: the November 2025 rejections apply to unauthenticated mail generally, and we follow the full bulk-sender rulebook while sending dozens of messages a day, because the habits are free and retrofitting them is not. Second, the order inside the first row is deliberate. DKIM before SPF because signing takes effect per-provider with no interactions; SPF second because it is one record with sharp edges; DMARC at p=none only after both exist, so its reports describe a system that is already trying to pass.

The part nobody staffs: monitoring

Authentication fails silently. A rejected message does not bounce back to a mailbox anyone reads; a broken selector or an over-limit SPF record just changes verdicts at the receiver. In June 2026 Gmail was rejecting 73% of the mail we forwarded to an archive, and the first symptom was an absence: messages that simply never appeared. Nothing errored on our side.

That incident is why our own workspace now sends a canary probe through the full production inbound path (DNS, routing, parsing, storage) every two hours, and emails the owner only when a round-trip fails. You do not need that machinery on day one, but you need its cheap equivalents: a monitored rua address so DMARC reports actually get read (a free weekly digest parser is enough), a test send to a Gmail account after any DNS change, with Show original checked for three passes, and a calendar entry to re-check whenever a new tool starts sending as your domain. Vendors change IPs and selectors without telling you; the reports are how you find out before your customers do.

The whole plan in five lines

1. Today: turn on DKIM everywhere something sends as you, and publish SPF with a ~all ending.
2. Today: publish v=DMARC1; p=none; rua=mailto:you@yourdomain.com. One record, zero risk, starts the data flowing.
3. Weeks 1 through 4: read the reports, authenticate or retire every source you find.
4. Weeks 4 through 10: quarantine, watch, then reject.
5. After reject, and only if the logo is worth $1,400 a year to you: BIMI.

Everything else in email deliverability is probabilistic. This part is a checklist with error codes, which makes it the rare corner of the field you can simply finish. Finish it.