The Email Authentication Stack Explained: How SPF, DKIM, DMARC, ARC, BIMI, and MTA-STS Fit Together

Most guides explain email authentication protocols one at a time: here is SPF, here is DKIM, here is DMARC. That is useful for configuring each record, but it leaves a gap. The protocols are not independent tools you pick from a menu; they are a layered system where each one depends on and reinforces the others. Understanding how the stack fits together is what separates someone who can copy a DNS record from someone who can diagnose why authentication is failing and architect it correctly.

This guide is the complete mental model. It explains what each protocol actually does, how they interlock, the dependencies between them, and the exact order to deploy them so each layer builds on a solid foundation rather than failing because a prerequisite was missing.

The Core Problem the Stack Solves

SMTP, the protocol that moves email across the internet, was designed in an era of mutual trust and has no built-in way to verify that a sender is who they claim to be. Anyone can connect to a mail server and claim to be sending from any address. This is why email spoofing, phishing, and business email compromise are possible at all.

The authentication stack bolts identity verification onto a protocol that never had it. Each layer answers a different verification question:

• SPF: Is this server allowed to send for this domain?
• DKIM: Was this message actually sent by the domain it claims, and was it tampered with in transit?
• DMARC: Does the authenticated domain match the visible From address, and what should happen if not?
• ARC: Was this message legitimately authenticated before a forwarder modified it?
• MTA-STS and DANE: Is the connection between mail servers actually encrypted and not downgraded by an attacker?
• BIMI: Now that we trust this sender, what is their verified logo?

No single protocol answers all of these. That is why the stack exists.

Layer 1: SPF Authorizes the Sending Server

SPF (Sender Policy Framework) is a DNS record listing which servers are authorized to send mail for your domain. When a receiving server gets a message, it checks the envelope sender domain's SPF record and confirms the connecting IP is on the authorized list.

SPF answers "where did this come from?" Its limitation is that it checks the envelope sender (the return-path), not the visible From address that recipients see. A spoofer can pass SPF for their own domain while displaying your domain in the From field. SPF alone does not stop the spoofing recipients actually see, which is why it is a foundation layer, not a complete solution.

SPF also breaks on forwarding (the forwarding server is not in your SPF record) and has a hard limit of 10 DNS lookups, beyond which it fails. These limitations are exactly what later layers address.

Layer 2: DKIM Signs the Message

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to each message. The sending server signs selected headers and the body with a private key, and the receiving server verifies the signature against a public key published in the sender's DNS. A valid signature proves two things: the message genuinely came from the signing domain, and it was not altered between signing and delivery.

DKIM answers "is this authentic and unmodified?" Its advantage over SPF is that the signature survives forwarding as long as the forwarder does not modify the signed content. Its limitation, like SPF, is that DKIM on its own does not require the signing domain to match the visible From address, so a message could carry a valid DKIM signature from one domain while displaying another in the From field.

SPF and DKIM are complementary. SPF validates the path, DKIM validates the content. Neither alone connects authentication to what the recipient sees. That connection is the job of the next layer.

Layer 3: DMARC Ties It Together and Sets Policy

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is the layer that makes SPF and DKIM meaningful. It does three things none of the lower layers can.

First, it requires alignment: the domain that passed SPF or DKIM must match the visible From domain. This closes the spoofing gap, because now passing authentication for an unrelated domain no longer helps an attacker who wants to display your domain in the From field. Alignment is the single most important concept in the stack, and the reason DMARC is the keystone.

Second, it sets policy: the domain owner tells receivers what to do with mail that fails alignment, via p=none (monitor only), p=quarantine (send to spam), or p=reject (block entirely).

Third, it provides reporting: receivers send aggregate reports showing which sources are sending as your domain and whether they pass alignment, which is how you discover misconfigured senders and spoofing attempts.

DMARC depends on SPF or DKIM (at least one must pass with alignment). This dependency is why you cannot deploy DMARC first; the lower layers must exist for DMARC to have anything to enforce. The mechanics of strict versus relaxed DMARC alignment are worth understanding in depth, but the key architectural point is that DMARC is the layer that converts SPF and DKIM from isolated checks into a system that actually stops spoofing.

Layer 4: ARC Preserves Authentication Across Forwarding

The foundation has a known weakness: forwarding breaks it. When a message is forwarded, SPF fails (the forwarder is not in the original SPF record) and DKIM may break (if the forwarder modifies the message). A mailing list that adds a subject prefix and a footer will break DKIM, and then DMARC fails even though the original message was perfectly legitimate.

ARC (Authenticated Received Chain) solves this. When a forwarder receives a message, it records the authentication results it observed and cryptographically seals them. The next receiver can see "this forwarder verified the message was authentic on arrival" and choose to honor that even if SPF and DKIM now fail due to the forwarding modifications.

ARC only matters once DMARC is at enforcement, because it exists specifically to rescue legitimate forwarded mail from DMARC failures. If your DMARC is still at p=none, forwarded mail is not being rejected anyway, so ARC has nothing to rescue. This is why ARC sits above DMARC in the deployment order.

Layer 5: MTA-STS and DANE Secure the Transport

SPF, DKIM, DMARC, and ARC all authenticate the message and its origin. None of them encrypt the connection between mail servers. A message can be perfectly authenticated and still travel in cleartext across the internet where a network attacker could read or modify it, because the STARTTLS encryption that should protect it can be stripped by a man-in-the-middle downgrade attack.

MTA-STS and DANE close this gap by making TLS encryption mandatory and downgrade-resistant. MTA-STS publishes a policy (via HTTPS) telling sending servers to require TLS when delivering to your domain. DANE publishes certificate fingerprints (via DNSSEC-signed DNS) that let sending servers verify the receiving server's certificate without relying on certificate authorities. They solve the same transport-security problem with different trust models, and our guides on MTA-STS transport security and DANE cover the deployment specifics.

These transport layers are independent of the message-authentication layers; they can be deployed at any point and protect the channel rather than the message. They are placed after the foundation in the deployment order simply because the foundation is more urgent for deliverability, not because of a technical dependency.

Layer 6: BIMI Displays Your Verified Logo

BIMI (Brand Indicators for Message Identification) is the visible top of the stack. It displays your brand logo next to authenticated messages in supported inboxes. BIMI is the reward layer: it does not add security on its own but makes the security underneath visible to recipients, turning your authentication investment into a trust signal users can actually see.

BIMI has the strictest dependency in the entire stack: it requires DMARC at enforcement (p=quarantine or p=reject). It will display nothing while you are at p=none. This is deliberate; a logo next to an unauthenticated message would defeat the purpose, so BIMI only activates once the foundation is fully enforced. This is why BIMI is always the last layer deployed, and why "I want my logo in Gmail" is really a request to complete the entire stack underneath it first.

The Dependency Map

The protocols are not independent. Here is what depends on what:

The Correct Deployment Order

Following the dependencies, here is the sequence that builds each layer on a solid prerequisite.

1. SPF and DKIM first. Publish an SPF record covering all your sending sources, and enable DKIM signing. These are the foundation and have no prerequisites. Verify both with a SPF checker and DKIM checker.
2. DMARC at p=none. Publish a DMARC record in monitor-only mode with reporting addresses. This does not affect delivery but starts collecting aggregate reports showing every source sending as your domain.
3. Analyze reports and fix alignment. Spend several weeks reviewing DMARC reports. Identify every legitimate sending source and ensure each passes alignment. Fix misconfigured senders. This is the longest and most important phase.
4. DMARC to p=quarantine, then p=reject. Once all legitimate sources pass alignment consistently, tighten the policy. Move to quarantine first, monitor, then to reject. This is the point at which spoofing is actually blocked.
5. ARC and transport security. Deploy ARC if you forward mail or operate mailing lists, and deploy MTA-STS (and DANE if you have DNSSEC) to secure the transport channel.
6. BIMI last. With DMARC at enforcement, deploy BIMI to display your logo. This is the visible payoff for completing the stack.

Diagnosing the Stack as a System

Because the layers interlock, diagnosing a problem means understanding which layer failed and why. The Authentication-Results header on any delivered message shows the verdict for each layer. Reading it as a system:

• SPF fail but DKIM pass: Often forwarding. DMARC may still pass via DKIM alignment. Usually not urgent.
• DKIM fail but SPF pass: The message was modified after signing, or DKIM is misconfigured. Check for forwarders or content rewriting.
• Both pass but DMARC fails: An alignment problem. The passing domain does not match the From domain. This is the classic misconfiguration where a sender authenticates with the ESP's domain instead of yours.
• DMARC passes but BIMI logo does not show: Almost always a certificate or DMARC-enforcement-level problem, not a DNS record problem.

Use a header analyzer to read the full authentication results, and your DMARC aggregate reports to see patterns across all your mail rather than one message at a time. The whole point of understanding the stack as a system is that a symptom at one layer often has its root cause at another, and only a system-level view reveals it.

Why the System View Matters

Senders who treat these protocols as a checklist of independent records tend to deploy them partially, in the wrong order, or without understanding why one fails when another changes. They publish DMARC at p=reject without analyzing reports and block their own mail. They buy a BIMI certificate while still at p=none and wonder why no logo appears. They configure SPF and call authentication done, leaving the From-address spoofing gap wide open.

Senders who understand the stack as a system deploy in the right order, know that BIMI requires enforcement, know that ARC rescues forwarded mail, know that transport security is a separate concern from message authentication, and can diagnose failures by tracing them through the layers. The stack is not six tasks; it is one architecture, and treating it as an architecture is what produces reliable deliverability and real protection against impersonation.

Frequently Asked Questions