What does it mean when someone talks about “email authentication?” It’s pretty straightforward: When an email message has been authenticated, we can have confidence that it really is from who it says it’s from.
Unfortunately, while this seems like a no-brainer, email was not originally built with this type of assurance. As a result, open Internet standards have been developed to make email authentication possible and restore trust to email. There are five that you need to know about, and each one covers a different piece of the puzzle.
Here is the high-level overview of the five key standards that make up email authentication: SPF, DKIM, DMARC, ARC, and BIMI.
Sender Policy Framework (SPF)
Sender Policy Framework is the standard that pioneered the concept of domain-based email authentication. SPF lets domain owners publish a list of approved IP addresses. If a mail server with an IP address that’s not on the list tries to send email using that domain, it won’t pass SPF authentication.
Authentication role: Validates that the sender is on the domain’s whitelist.
Why SPF can’t stand alone: SPF uses the domain from a message’s Return-Path for authentication, not the “From:” address that humans actually see (most mail clients do not display the Return-Path). Phishers can set up their own domains with an SPF record that authenticates the domain used in the Return-Path. Then they can send out phishing emails with another company’s domain showing in the “From:” field — but the message would still pass SPF authentication based on the phisher’s domain used in the Return-Path.
For more information: What is SPF?
DomainKeys Identified Mail (DKIM)
DomainKeys Identified Mail uses public key cryptography to authenticate individual email messages. The sending server adds an encrypted hash of the message to the email. Upon receipt, the hash can be validated (using a public key stored in DNS) asserting that the content has not been modified in transit.
Authentication role: Verifies that the message and its contents have been validated using PKI.
Why DKIM can’t stand alone: To stop phishing, the most important address is the domain in the “From:” field. The domain used to sign a message with DKIM could be completely different from the domain shown in the “From:” field.
For more information: What is DKIM?
Domain-based Message Authentication, Reporting & Conformance (DMARC)
Domain-based Message Authentication, Reporting, and Conformance builds on SPF and DKIM to stop exact-domain email spoofing by matching what SPF and DKIM validate with the header that the end user actually sees — the “From:” field. It also gives domain owners the ability to set a policy specifying what mail servers should do with messages that fail authentication. Also, provides reporting back to the domain owner about which senders are passing and failing authentication. This prevents the most damaging form of impersonation — phishers from using your domain in the “From:” address while signing the message with an unrelated domain that they control.
Authentication role: Ensures that the domain the user sees in the visible From: has been authenticated by SPF and/or DKIM.
Why DMARC can’t stand alone: DMARC alone can’t authenticate an email. It must have authenticated via SPF or DKIM and match the “From:” Additionally, there is a small percentage (<1%) of messages that will fail authentication after being forwarded or passed through a mailing list. Those systems break authentication by forwarding through IPs no longer on an SPF whitelist or by modifying the subject or body of the message, therefore invalidating the original hash added by DKIM.
For more information: What is DMARC?
Authenticated Received Chain (ARC)
The Authenticated Received Chain protocol provides an authenticated “chain of custody” for a message, allowing each entity that handles the message to see what entities handled it before, and to see what the message’s authentication assessment was at each step in that chain.
This gives email services a way to verify email authentication even when messages pass through multiple forwarders, such as mailing lists.
Authentication role: Allows authentication information to survive complex routing, so even forwarded messages and mailing list messages can be validated.
Why ARC can’t stand alone: ARC only allows for the confirmation of an authentication status that is already attached to the message. It must be used in conjunction with authentication mechanisms such as SPF, DKIM, or DMARC.
For more information: ARC: A standard we’re proud to support
Brand Indicators for Message Identification (BIMI)
Brand Indicators for Message Identification allows senders to provide brand-specific imagery that appears alongside authenticated messages they send. These images appear in place of the user photo or the sender initials that many email clients display next to the sender’s name. This acts as a visual cue of authenticity for recipients.
Authentication role: Lets domain owners specify which image appears alongside authenticated messages in recipients’ inboxes.
Why BIMI can’t stand alone: The visual confirmation is great, but without the underlying authentication standards, you’ll run into similar problems where anyone could upload any logo to an email to trick the recipient.
For more information: How BIMI will make brands’ emails more recognizable and trustworthy
If you’re interested in digging deeper into these standards, our white paper, The Insider’s Guide to Email Authentication, is a great place to start.