Email Authentication Protocols: SPF vs DKIM vs DMARC vs BIMI

The email authentication stack has grown from a single DNS record in the early 2000s to a layered set of four protocols that work together to verify sender identity, detect tampering, enforce policy, and display brand logos. Understanding what each protocol does — and does not do — is essential before you start deploying them, because mistakes in one layer undermine the others.

Why Email Authentication Matters

SMTP was designed without authentication. Any mail server can claim to send from any domain. The result is decades of phishing, business email compromise, and spam that impersonates trusted brands. Email authentication protocols attach verifiable identity to messages using DNS records that only the domain owner can publish.

Together, SPF, DKIM, DMARC, and BIMI give receiving mail servers the information to answer: was this message sent by someone the domain owner authorized, has it been tampered with, what should we do if it fails, and should we display the sender's brand logo?

SPF: Sender Policy Framework

What it does

SPF defines which IP addresses and mail services are authorized to send email on behalf of your domain. It is enforced by checking the sending server's IP against a list you publish in a DNS TXT record at your domain root.

DNS record format

yourcompany.com  TXT  "v=spf1 ip4:203.0.113.0/24 include:_spf.google.com include:sendgrid.net -all"

What SPF checks

SPF verifies the envelope sender (the MAIL FROM SMTP command), not the From: header visible to recipients. This distinction matters enormously: an attacker can craft a message where the envelope passes SPF (using their own domain) while the visible From: header shows your domain. SPF alone does not prevent header spoofing.

SPF enforcement modifiers

• -all — hard fail: reject mail from unlisted sources (recommended)
• ~all — soft fail: accept but mark mail from unlisted sources
• ?all — neutral: no policy (essentially disables SPF enforcement)
• +all — pass everything (never use this)

SPF limitations

• 10 DNS lookup limit per evaluation (every include: counts)
• Breaks on forwarded email (the forwarder's IP is not in your SPF record)
• Checks envelope sender only, not the visible From: header
• No mechanism to tell receiving servers what to do with failures

DKIM: DomainKeys Identified Mail

What it does

DKIM adds a cryptographic signature to each outgoing message. The signature covers specified headers and the message body. Receiving servers fetch your public key from DNS and verify the signature, confirming the message came from your infrastructure and was not modified in transit.

How the signature is added

Your mail server signs selected headers (typically From, To, Subject, Date, Message-ID) and the body using a private key. The signature is added as a DKIM-Signature header:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=yourcompany.com; s=mail2026;
  h=from:to:subject:date;
  bh=<body-hash>;
  b=<signature>

DNS record for the public key

mail2026._domainkey.yourcompany.com  TXT  "v=DKIM1; k=rsa; p=<public-key-base64>"

What DKIM checks

DKIM verifies that the signing domain (d= value) authorized the message and that the signed content has not changed. It does not require the signing domain to match the From: header — an attacker can sign with their own domain while spoofing yours in From:. Like SPF, DKIM alone is not sufficient to prevent From: header spoofing.

DKIM advantages over SPF

• Survives email forwarding (the signature travels with the message)
• Covers message content integrity, not just the sending IP
• Supports multiple simultaneous keys via selectors

DMARC: Domain-based Message Authentication, Reporting & Conformance

What it does

DMARC is the policy layer that makes SPF and DKIM meaningful for anti-spoofing. It requires at least one authentication mechanism to align with the From: header domain, and it tells receiving servers what to do when alignment fails.

DMARC alignment explained

• SPF alignment — the domain in the MAIL FROM envelope must match the From: header domain
• DKIM alignment — the d= value in the DKIM signature must match the From: header domain

Both alignment checks can be relaxed (subdomains allowed) or strict (exact domain match required).

Without DMARC, an attacker can pass both SPF and DKIM using their own domain in the respective fields while spoofing your domain in From:. DMARC closes this gap.

DMARC DNS record

_dmarc.yourcompany.com  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@yourcompany.com; ruf=mailto:forensics@yourcompany.com; pct=100"

Policy levels

Policy	Effect	When to use
p=none	Monitor only, no enforcement	Initial deployment, discovery phase
p=quarantine	Deliver to spam/junk folder	Transition phase
p=reject	Block delivery entirely	Full enforcement

DMARC reporting

DMARC aggregate reports (rua) are XML files sent daily by major receiving services. They show every source sending with your From: domain, whether SPF and DKIM passed or failed, and message volumes. These reports are essential for discovering unauthorized sending sources and ensuring legitimate senders pass authentication before moving to reject.

Common DMARC misconfigurations

• Staying at p=none permanently — provides zero protection; it is a monitoring mode, not a security control
• Not monitoring reports — you will miss legitimate senders that need fixing before enforcement
• Forgetting subdomains — DMARC applies to the exact domain by default; use sp=reject to also cover subdomains
• Not protecting parked domains — every domain you own needs p=reject, including ones that never send email

BIMI: Brand Indicators for Message Identification

What it does

BIMI is an emerging standard that displays your organization's logo in the recipient's inbox next to authenticated email. It builds on top of DMARC enforcement to provide a visible trust signal to recipients.

Requirements for BIMI

1. DMARC must be at p=quarantine or p=reject (enforcement required)
2. Your logo must be in SVG Tiny P/S format
3. You need a Verified Mark Certificate (VMC) from an approved CA (DigiCert or Entrust) — required by most major mail providers to display the logo
4. The logo must be trademarked

BIMI DNS record

default._bimi.yourcompany.com  TXT  "v=BIMI1; l=https://yourcompany.com/logo.svg; a=https://yourcompany.com/vmc.pem"

Current BIMI support

• Gmail — supported with VMC requirement
• Yahoo Mail — supported
• Apple Mail — supported
• Microsoft 365 — partial/limited support as of early 2026

BIMI limitations

VMCs cost several hundred dollars per year. The SVG format requirements are strict. BIMI provides a brand trust signal but does not add technical security beyond what DMARC already provides.

Correct Implementation Order

Deploy these protocols in sequence — skipping steps or deploying out of order causes authentication failures for legitimate mail:

1. SPF — identify all your sending sources, publish the record with -all
2. DKIM — generate keys, publish DNS records, configure signing on all mail servers
3. DMARC at p=none — enable reporting, collect data for 2–4 weeks
4. Fix alignment issues — ensure all legitimate sources pass SPF or DKIM with your From: domain
5. DMARC at p=quarantine — move gradually from pct=10 to pct=100
6. DMARC at p=reject — full enforcement once you are confident all legitimate mail passes
7. BIMI — optional brand enhancement, only after DMARC enforcement is stable

Summary Comparison

	SPF	DKIM	DMARC	BIMI
What it checks	Sending IP vs authorized list	Cryptographic signature	Alignment + policy	Logo display
Checks From: header	No	No	Yes	Yes
Survives forwarding	No	Yes	Depends	N/A
Provides reports	No	No	Yes	No
Prevents spoofing alone	No	No	Yes	No
Requires others to work	No	No	Requires SPF or DKIM	Requires DMARC

The complete stack — SPF + DKIM + DMARC at p=reject — is what actually stops From: header spoofing of your domain. Each layer is necessary; none is sufficient on its own.