The Email Authentication Stack: SPF to BIMI, and How Each Layer Fails

Email has no built-in identity. SMTP lets any host claim any sender address, and every control layered on since has been an attempt to bolt verification onto a protocol that was never designed for it. Seven standards do that work in 2026, each covering a gap the previous one left open, and each failing in a way that is invisible from the outside.

Here is the stack, in the order a message encounters it, and what each layer actually proves.

The stack at a glance

Three of these authenticate the sender. Two protect the transport. One rescues forwarded mail. One puts a logo in the inbox. They are frequently discussed as if they were interchangeable, and they are not.

SPF: the IP list

SPF publishes a DNS record naming the hosts allowed to send for a domain, and the receiver checks the connecting IP against it. It is the oldest layer and the most brittle.

Two structural problems. First, SPF validates the SMTP envelope sender, not the From header a human reads, so on its own it stops nothing an attacker cares about: they send from a domain whose SPF they control and put yours in the visible header. Second, evaluation is capped at 10 DNS lookups. Every vendor include: consumes at least one and vendor includes nest, so a growing company blows through the ceiling and gets permerror, which receivers treat as no SPF at all.

SPF also breaks on forwarding by design. The forwarding host's IP is not in your record, so the check fails. That is not a bug in your configuration. It is the reason ARC exists.

DKIM: the signature

DKIM signs selected headers and the message body with a private key and publishes the public key in DNS under a selector. A receiver fetches the key and verifies.

DKIM is the more durable of the two authentication paths because a signature travels with the message. A forwarded message still verifies as long as the signed content is unaltered. Mailing lists that append footers or rewrite subject lines break it, which is precisely the case ARC handles.

The operational failure is key management. Selectors exist so keys can rotate without downtime: publish the new selector, start signing with it, retire the old one after the mail in flight has cleared. Teams that never rotate end up with 1024-bit keys from 2016 and no procedure for changing them.

DMARC: the alignment layer

DMARC is the layer that makes the other two matter. It requires that the domain validated by SPF or DKIM aligns with the domain in the visible From header, publishes a policy for what to do when neither does, and opens a reporting channel that tells you who is sending as you.

Without DMARC, SPF and DKIM are two checks on domains the recipient never sees. With it, they become a statement about the identity the recipient is actually reading.

The reporting is worth more than the policy for the first month. Aggregate reports are the only complete inventory of your sending estate that exists anywhere. Most organizations discover systems they had forgotten they were paying for.

Full rollout mechanics: Roll Out DMARC to p=reject Without Breaking Mail.

ARC: the forwarding rescue

Authenticated Received Chain (RFC 8617) lets an intermediary that legitimately modifies a message record the authentication results it observed before modification, and sign that record. A downstream receiver that trusts the intermediary can honor the original result even though SPF and DKIM now fail.

This is what keeps mailing lists and forwarding services working under DMARC enforcement. It is also the layer with the weakest guarantees, because ARC is trust-based: the receiver decides which intermediaries to believe, and there is no certificate authority making that judgment for them. Google and Microsoft both evaluate ARC. Smaller receivers frequently do not.

You do not configure ARC as a sender. You benefit from it when your mail passes through infrastructure that implements it, and you implement it if you are the intermediary.

MTA-STS and TLS-RPT: the transport layer

The first four layers all answer "who sent this". MTA-STS answers a different question: was it encrypted in transit, and can an attacker downgrade it.

SMTP's opportunistic TLS via STARTTLS is trivially strippable by an active network attacker, because a sending MTA that sees no STARTTLS offer will fall back to plaintext without complaint. MTA-STS (RFC 8461) publishes a policy over HTTPS declaring that your domain requires TLS with a valid certificate, and caches it, so a sender that has seen your policy refuses to downgrade.

TLS-RPT (RFC 8460) is its telemetry: receivers send you daily reports of TLS negotiation failures. Without it, MTA-STS failures are as invisible as everything else in this stack.

DANE is the DNSSEC-based alternative to MTA-STS. It is stronger and requires DNSSEC on your zone, which is why MTA-STS dominates outside of Northern Europe.

BIMI: the visible layer

BIMI is the only layer a recipient can see. It publishes a logo in DNS and lets Gmail, Apple Mail, Yahoo, and Fastmail display it next to authenticated mail, with a VMC additionally producing the blue checkmark in Gmail.

It proves nothing new about the message. Every security property comes from the DMARC enforcement it requires. What it adds is a visual signal that is expensive to counterfeit, since a phishing actor cannot obtain a certificate for a trademark they do not own.

Cost and prerequisites: Gmail Blue Checkmark: What BIMI Actually Costs.

Where each layer fails silently

This is the property that unites the stack and the reason email authentication rots. Every layer degrades to "no protection" rather than to an error you can see.

• SPF hits 11 lookups and returns permerror. Your mail still delivers. Nothing tells you.
• A DKIM key is rotated at the vendor but not in DNS. Signatures fail. Mail still delivers if SPF holds.
• DMARC sits at p=none for three years because nobody scheduled the enforcement work. The record looks correct in every checker.
• MTA-STS policy expires. Downgrade protection ends. No alert.
• A BIMI PEM is served without its intermediate certificate. The logo simply never appears.

None of these produce a bounce, a log line in your application, or an email to your admin. The only detection is the reporting channels, which is why rua and TLS-RPT are not optional extras. They are the monitoring for everything above them.

Minimum viable configuration

For a company that sends mail and does not want a project:

1. SPF with -all, under 10 lookups, audited when you add a vendor.
2. DKIM signing with your own domain on every sending platform, 2048-bit, selectors documented.
3. DMARC at p=reject, pct absent, rua pointed at a parser somebody reads monthly.
4. sp=quarantine or stricter, and p=reject on every parked domain.
5. MTA-STS in enforce mode with TLS-RPT reporting.
6. BIMI only if the logo is worth $650 to $1,400 a year to you.

Items 1 through 4 are the security. Item 5 is cheap and mostly ignored. Item 6 is marketing with a security prerequisite.