Email authentication
Email authentication combines SPF, DKIM, and DMARC into a layered defense that verifies sender identity and prevents domain spoofing, with BIMI emerging as a visual trust indicator built on top.
4 min read
What it is#
Email authentication is the set of DNS-based protocols that allow a receiving mail server to verify whether an incoming message was actually authorized by the domain it claims to come from. The three core protocols, SPF, DKIM, and DMARC, each address a different aspect of sender verification, and together they form a layered architecture that is now expected of every domain that sends email.
Without email authentication, the SMTP protocol allows any server to claim any sender address. This is the root cause of email spoofing, forging the sender address on an email to make it appear to come from a trusted domain. These protocols close that gap, though each has distinct capabilities and limitations.
The three layers#
SPF (Sender Policy Framework) checks the envelope sender. The domain owner publishes a DNS TXT record listing the IP addresses authorized to send mail for that domain. The receiving server verifies that the connecting IP is on the list. SPF is simple to deploy but has structural limitations. It breaks on forwarding (the forwarding server's IP isn't authorized) and it only checks the envelope sender, not the From header users see.
DKIM (DomainKeys Identified Mail) checks the message itself. The sending server cryptographically signs specified headers and the body, and the receiving server verifies the signature using a public key published in DNS. DKIM survives forwarding because the signature travels with the message. It proves the message hasn't been tampered with and that a specific domain authorized it.
DMARC (Domain-based Message Authentication, Reporting, and Conformance) ties SPF and DKIM together. It requires that at least one of them passes and aligns with the domain in the visible From header. DMARC adds a policy layer (none, quarantine, reject) telling receivers how to handle failures, plus a reporting mechanism (rua) that gives domain owners visibility into who is sending mail as their domain.
How they work together#
Consider a message with From: [email protected]:
- SPF check. The receiver looks up
example.com's SPF record and checks whether the connecting IP is authorized. If the envelope sender domain matchesexample.com, SPF alignment passes. - DKIM check. The receiver verifies the DKIM signature and confirms the signing domain (
d=example.com) matches theFromdomain. If valid, DKIM alignment passes. - DMARC evaluation. If either SPF or DKIM passes with alignment, DMARC passes. The receiver then applies the domain's DMARC policy to determine disposition.
A message that fails both aligned SPF and aligned DKIM will be handled according to the DMARC policy, delivered normally (at p=none), sent to spam (p=quarantine), or rejected (p=reject).
Deployment order#
The recommended deployment sequence:
- SPF first. Publish a TXT record listing authorized senders. This is the lowest-effort starting point.
- DKIM next. Enable signing on all mail systems. This requires configuration on each sending platform but provides stronger authentication that survives forwarding.
- DMARC last. Publish at
p=nonewithrua=reporting, analyze aggregate reports to confirm all legitimate mail passes, then progressively tighten toquarantineandreject.
Deploying DMARC before SPF and DKIM are properly configured will not accomplish anything, DMARC depends on the underlying protocols being in place.
BIMI as an emerging layer#
Brand Indicators for Message Identification (BIMI) is a newer standard that builds on DMARC enforcement. When a domain has p=quarantine or p=reject and publishes a BIMI record, participating email clients display the domain's authenticated logo next to the message. BIMI requires a Verified Mark Certificate (VMC) from a qualified certificate authority, which validates trademark ownership.
BIMI does not add security enforcement itself, it is a visual trust signal that rewards domains with strong authentication. Adoption is growing but not yet universal across email clients.
What email authentication does not prevent#
Even with full SPF, DKIM, and DMARC deployment at p=reject, several attack vectors remain:
- Lookalike domains.
examp1e.comis a separate domain with its own (or no) authentication. DMARC onexample.comprovides zero protection. - Compromised accounts. A message sent from a genuinely compromised
@example.commailbox passes all authentication checks because it is legitimately sent. - Display name spoofing. The free-text display name is not covered by any authentication protocol.
- Free email impersonation. BEC messages from
[email protected]pass Gmail's authentication regardless of the target organization's policies.
These gaps require complementary controls, domain monitoring, mail flow anomaly detection, and user awareness training. Email authentication closes the front door, and domain intelligence watches for attackers building new ones through brand impersonation.
More from Email security
View allBusiness email compromise (BEC)
Business email compromise is a targeted social engineering attack that uses email impersonation and trust exploitation to divert payments, steal sensitive data, or manipulate business processes.
What is adversary-in-the-middle (AiTM) phishing?
AiTM phishing uses reverse-proxy tools to relay credentials and capture session tokens in real time, allowing attackers to bypass multi-factor authentication and hijack authenticated sessions.
What is DKIM?
DKIM uses cryptographic signatures to verify that an email's headers and body haven't been tampered with in transit, tying the message to a specific sending domain through DNS-published public keys.