Email Authentication Guide: SPF, DKIM, DMARC, and BIMI

What SPF, DKIM, DMARC, and BIMI Do

The four protocols stack on top of each other. Each protocol solves a specific spoofing gap, and each layer needs the layer below it to be in place before it can do its job.

SPF — Sender Policy Framework

SPF is a DNS TXT record at the apex of your domain that lists every IP address and mail server authorised to send mail on your behalf. When a receiving mail server gets a message from your domain, it does a DNS lookup against the SPF record and checks whether the sending IP is on the approved list. A passing SPF check tells the receiver that the envelope sender is one of your approved servers.

SPF evaluates the MAIL FROM envelope sender, not the visible From: header. It is capped at 10 DNS lookups during evaluation, and exceeding 10 causes a PermError that fails SPF on every message until you flatten the record into ip4: /ip6: ranges or use an SPF-flattening service. SPF breaks on forwarded mail because the forwarding server's IP is almost never in your record — which is one reason DKIM exists. Worked example for a single sending source:

yourdomain.com  TXT
  v=spf1 include:_spf.google.com -all

DKIM — DomainKeys Identified Mail

DKIM adds a cryptographic signature to every outgoing message. Your mail server signs the message with a private key; the matching public key is published as a DNS TXT record at selector._domainkey.yourdomain.com. Receiving servers verify the signature with the public key — a passing DKIM check means the message content has not been tampered with in transit and genuinely came from a sender that holds your private key.

Unlike SPF, DKIM survives forwarding because the signature travels with the message headers. The DKIM d= domain (the signing domain) is what DMARC later checks for alignment with the visible From: domain. Typical DNS record format:

selector._domainkey.yourdomain.com  TXT
  v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...

Most teams don't write the public key manually — Google Workspace, Microsoft 365, SendGrid, Postmark, and the rest of the major ESPs generate the key pair and tell you the TXT record to publish. Rotate the key periodically; most providers rotate yearly automatically.

DMARC — Domain-based Message Authentication, Reporting and Conformance

DMARC ties SPF and DKIM together. It requires that either the SPF-checked domain or the DKIM d= domain align with the visible From: domain — and it tells receiving servers what to do when both checks fail: none (no action, monitor only), quarantine (send to spam), or reject (block at SMTP). DMARC also gives you aggregate RUA reports daily from the major providers, showing every IP that sent mail claiming to be from your domain. Standard monitoring-only starting position:

_dmarc.yourdomain.com  TXT
  v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; pct=100

BIMI — Brand Indicators for Message Identification

BIMI is a DNS TXT record at default._bimi.yourdomain.com that points at a square SVG logo and (optionally) an a= self-assertion of logo-control or a Verified Mark Certificate (VMC). Gmail, Apple Mail, and Yahoo render the logo inline next to the from-line once DMARC passes; on Microsoft, the published a= assertion unlocks the verified-sender check mark.

BIMI is purely the brand-trust layer — Gmail does not reward a BIMI-published domain with extra inbox placement. But the rendered logo lifts the engagement signals Postmaster Tools and Microsoft SNDS actually score, which feeds the same loop. Worked example for self-asserted senders (no VMC):

default._bimi.yourdomain.com  TXT
  v=BIMI1; l=https://logo.yourdomain.com/bimi/acme.svg; a=https://logo.yourdomain.com/bimi/acme.pem

Why Authentication Drives Deliverability and Sender Reputation

Authentication is the floor under sender reputation. A message with no published SPF, no DKIM signature, and a DMARC record that has been ignored for months lands deeper in the spam pipeline before content is even examined — every other lever you have (engagement, list hygiene, content quality) is working against that baseline.

The 2024 Gmail + Yahoo bulk-sender bar. Since February 2024, any sender close to 5,000 messages per day to Gmail or Yahoo Mail recipients must publish valid SPF and DKIM, hold a DMARC record at p=none or stricter, keep spam complaint rate below 0.1% in Postmaster Tools, and include a List-Unsubscribe-Post: List-Unsubscribe=One-Click header (RFC 8058). Senders without all of those see throttling within weeks and outright rejection within months. Authentication is the entry ticket — without it, every other signal is read with a discount.

Postmaster Tools domain reputation. Gmail's deliverability score is fed by SPF/DKIM/DMARC alignment on every message, then weighted alongside recipient engagement (opens, replies, moves-from- spam). A high alignment rate on a clean reputation climbs the Postmaster domain reputation band (High / Medium / Low) and visibly moves inbox placement. The inverse: a domain with Low reputation because of dropped alignment rates has to spend months rebuilding it. Authentication alignment is the cheapest signal to keep clean — once broken, it is the most expensive to restore.

Microsoft SNDS filter colour. Outlook scores sender reputation per-IP through SNDS — a colour band (green / yellow / red) plus per-IP complaint rate and trap-hit counts. SNDS-reported filter colour is specifically tied to authentication (SPF / DKIM alignment at the receiving hop) plus PTR and forward-confirmed reverse DNS. Move an IP from yellow back to green faster by restoring DKIM alignment than by any other single change.

The DMARC RUA feedback loop. The most under-used piece of authentication is the daily RUA aggregate report. Once you publish a DMARC record with a rua= address, Google, Microsoft, and Yahoo send you XML reports every day showing every IP that sent mail claiming to be from your domain, the volume per IP, and the per-IP SPF and DKIM pass/fail rate. That data lets you spot a new sending source failing before it costs you placement, and it lets you spot a spoofer piggy-backing on your brand. The reports are the closed-loop signal the rest of the stack is missing.

BIMI does not feed the spam filter — it feeds the engagement that feeds the filter. BIMI itself is not a placement signal at Gmail; the visible logo next to your from-line lifts open rates, reply rates, and moves-from-spam actions at every supporting provider. Those actions feed Postmaster domain reputation directly. The render is the visible win — the closed-loop win is the engagement that flows back into the alignment-and-reputation score the providers actually maintain.

Best-Practice Setup Steps

Publish in this order. Each step is gated on the previous step being clean — if you skip ahead (publishing BIMI before DMARC is enforced, for example) the new layer will silently fail at the providers.

1. Publish a single SPF record at the apex ending -all, stay under 10 DNS lookups. List every system that sends mail for your domain (Google Workspace, Microsoft 365, your ESP, transactional senders, your own SMTP relay) and combine each provider's include: into a single TXT record at the apex of the domain. End the record with -all so unapproved senders are hard-failed. Stay under the 10-lookup cap — if you breach it, flatten include: chains into ip4: /ip6: ranges or use an SPF flattening service. Step-by-step reference is in the SPF Record Setup guide; validation is one click with the SPF record checker.
2. Rotate DKIM and publish the public key in DNS. Each sending platform (Workspace, M365, your ESP, CRM, helpdesk) needs its own DKIM selector — the DNS TXT goes at selector._domainkey.yourdomain.com and the signing server uses the matching private key. Most providers rotate keys yearly; rotate deliberately to invalidate leaked keys rather than letting a rotation run unannounced. Confirm with the SPF / DKIM / DMARC checker that the selector resolves and parses correctly. The deeper protocol walkthrough is in the SPF, DKIM, and DMARC explained guide.
3. Publish DMARC starting at p=none, review RUA for 2–4 weeks, then escalate to p=quarantine pct=10 → pct=100, then p=reject. Move only when your RUA reports show SPF and DKIM alignment rates consistently above 95%. A monitoring-only policy still satisfies the 2024 Gmail/Yahoo bulk- sender bar — but BIMI is gated on real enforcement, so this step is where you decide whether your brand-trust layer (and the Microsoft verified check mark) will ever render. The diagnostic walkthrough for a failing DMARC alignment is in the Fix DMARC Failing guide. 2024 checklist context is in the Gmail Bulk Sender Requirements guide.
4. Only after DMARC is enforced, publish BIMI at default._bimi.<domain> with a square SVG and an a= self-assertion (or VMC for Microsoft certified check mark). Every supporting provider gates BIMI rendering on a passing DMARC check. Host a square single-path SVG at an HTTPS URL you control (no third-party CDN that strips the Content-Type header, no redirect chain), then publish the BIMI TXT at the default selector. Add a= PEM-encoded Assertion of logo-control for the Microsoft verified check mark (and as best practice everywhere); swap to v=VMC URL once you go through a Mark Certificate Authority for the 2024+ DMARC ARC certified path. Validate the rendering providers' view with the BIMI checker, and read the per-step protocol walkthrough in the BIMI guide.

Common Mistakes

• Publishing more than one SPF record (or none at all). RFC 7208 specifies exactly one SPF record per domain. Two v=spf1 TXT records at the same apex produce a PermError on every message you send. Merge them into a single record; the diagnostic is in the SPF record checker.
• Using +all or ~all as the trailing default in a production SPF. +all authorises any sender in the world — it makes SPF worthless. ~allis a softfail, useful while you're still auditing sending sources. Production SPF should end with -all once every source is accounted for.
• Letting your ESP sign DKIM with its own vendor domain. If your ESP signs with d=mailvendor.net while the visible From: is your brand domain, DKIM alignment fails on every message — DMARC fails, and your deliverability drops. Configure your sending platform to use a subdomain of your brand (e.g. mail.yourbrand.com) for both the envelope sender and the DKIM signing domain.
• Publishing DMARC without a rua= address. Without aggregate reports, you don't know which sources are sending on your behalf, which are failing alignment, or whether a spoofer is piggy-backing on your domain. DMARC without RUA is flying blind — and you'll find out about broken alignment when your Postmaster domain reputation falls to Low.
• Publishing BIMI before DMARC is at p=quarantine or stricter. Every supporting provider treats a monitoring-only p=none DMARC as a non-pass for BIMI purposes. The logo will never render. Wait for the p=quarantine floor before publishing the BIMI record at default._bimi.<domain>.

Related Tools and Guides

• SPF / DKIM / DMARC checker →
• BIMI checker →
• SPF, DKIM, and DMARC explained →
• SPF / DKIM / DMARC verification pillar guide →
• BIMI guide →
• How to fix DMARC failing →
• Gmail Bulk Sender Requirements →
• Sender Reputation Guide →