Email Authentication: A Technology Introduction

DISCLAIMER: 100% of the content in this blog post is original and has been created by humans, including its research, writing, images, and graphics.  No AI (Artificial Intelligence) was used to create any portion of the content.

TL;DR: Email authentication is the technical process that enables email users to know whether or not an email is authentic.  It is a critical component of ensuring that sensitive information is kept private, but it's technically challenging to implement and manage.  Nine different technologies are used to ensure that email is authentic.  This article contains a technical introduction to each of these technologies.

• TLS (encrypts email and authenticates email receivers)
• SPF (authenticates email senders)
• DKIM (authenticates email senders; prevents forged email)
• MTA-STS (requests TLS; authenticates receiver email servers)
• DMARC (prevents SPF or DKIM from being disabled)
• DNSSEC (protects DNS, a critical component of email security)
• DANE (requests TLS; authenticates receiver SSL Certificate)
• TLS-RPT (reports email sender TLS issues to email receiver)
• BIMI (brand logo visually indicates that an email is authentic)

Today we're going to explain how email testing technology can tell if your email is really being sent to the right place, if it is really being sent from the right place, and if it was read or changed along the way.

When each of the technologies explained below were introduced, we began testing them using tests that we developed at CheckTLS.com.  What we found was a confusing mix of competing, overlapping, and complementary standards for protecting email when it is sent, when it is received, and when it travels between email servers.

In this introduction we will explain, at a beginner level, the nine technologies used to validate emails; what they are, what they do, how they work, and why use them.  This is a technical discussion.  For a more business-focused discussion of overall email security, specifically how to keep sensitive information private, click here to read our Email Security: A Privacy Introduction article.

What is Email Authentication?

Email authentication is the technical process that enables email users to know whether or not an email is "authentic", meaning that it came from where it was supposed to have come from, or that it was sent to where it was supposed to have been sent to, and that it wasn't changed along the way.  When you send an email, you want to know that it is being sent to a correspondent who isn't being impersonated.  When you receive an email, you want to know that it came from a correspondent who isn't being impersonated.  Both sending and receiving email users want to know that sent email messages are received exactly as they were sent and that nothing in the message was changed.

Authentication of sent and received email messages is done using domain names and email servers.  A domain name is the part of every email address that follows the at sign ("@") in the email address.  An email server is a specialized computer that is connected to the Internet that puts email onto the Internet or takes email off of the Internet.  Throughout the remainder of this post the term "sender" refers to an email server that puts email onto the Internet (sends email) and the term "receiver" refers to an email server that take email off the Internet (receives email).  Except in extremely rare instances, email authentication, and most email security, is domain name and email server based.  For example, email security, however it may be configured, is the same for john@smithco.com as it is for bill@smithco.com because both email address belong to the same domain name — "smithco.com".

Each of these technologies requires the sender and receiver to both use the same technology.  One side publishes instructions for the other side to follow to complete an authentication step.  For example, both the sender and receiver must be using DANE for DANE to authenticate email between them.  This is true for all of the email authentication technologies presented in this technology introduction.  This introduction reinforces this "both sides must use the same  technology" requirement by describing, for each technology, what each side has to do to use that technology.

Why Should I Care About Email Authentication?

If you receive an impersonated email from your CFO and wire $10M to a bitcoin address, you care.  If you accidentally email the secret recipe for Coke to a Pepsi employee, you care.  If someone changes your legitimate email order for 10 widgets into an order for 10,000 widgets, you care.  Email authentication is used to prevent these types of email catastrophes from occurring.  That's why you care about email authentication.

The Nine Email Authentication Technologies

All nine of the technologies described here that perform email authentication (and are tested by Information Security Testing) use something called Domain Name Service (DNS).  DNS is the Internet's address book.  A traditional address book lets you find a person's phone number when you lookup their name.  DNS lets your PC lookup the Internet protocol address (known as an "IP address") of the email server that handles email for a domain name.  For example, the email address "support@checktls.com" is associated with the domain name "checktls.com."  DNS says email for "checktls.com" is handled by two servers: "mail11-do.checktls.com" and "mail12-do.checktls.com".  DNS also says the IP address for "mail11-do.checktls.com" server name is 132.209.47.28 and 104.131.118.193 for the "mail12-do.checktls.com"server name.  Unlike a traditional address book that you must open to use, whenever an email is sent or received multiple DNS lookups happen automatically without your involvement.  Like a traditional address book, DNS allows for entries in addition to computer names and IP addresses like "see this other domain" or "my official logo is here."

Some of the nine email authentication technologies described in this post use public/private key encryption (click here to read our Beginner's Guide To Public Key Encryption).  Public/private key encryption technology is its own complex topic, but for this introduction you just need to know that there are two paired keys that work together to perform email encryption.  What one key locks (encrypts) the other can unlock (decrypt) and vice-versa.

Some of these email authentication technologies use digests and signatures.  Digests and signatures are their own complex topic, but for this introduction you can think of a digest as a math function that totals all of the bytes that comprise an email.  If the email is altered, even just one character, the byte total changes.  The byte total (the digest) cannot be used to recreate the email, but it does uniquely identify it.  A signature is created by encrypting the digest with a private key.  The signature then assures two things when it is decrypted using its matching public key: 1.) That the message has not been changed since it was signed, and 2.) That it came from one specific private key.

Some of these email authentication technologies use SSL Certificates to authenticate email servers in the same manner as web browsers do to authenticate HTTPS websites.  One of the earliest Internet security technologies that was invented is the HTTPS protocol.  HTTPS was designed to enable secure browsing on the Internet.  When you browse to an HTTPS website address, your browser and HTTPS make sure you are connected to the genuine website (not an impersonated website) and that your data is encrypted.  Your browser does this because the website sends an SSL Certificate that has been issued by a trusted entity known as a Certificate Authority ("CA").  The CA has verified that the website's domain name (the text in the website address that immediately follows the double-right-slashes ("//") and ends before the next single-slash ("/") in the website address) is legitimate.  If the SSL Certificate is missing, invalid, expired, or not signed by a trusted CA, your browser will display an error.  This same thing happens when SSL Certificates are used by email authentication technologies to perform email authentication.

With this overview of these nine technologies out of the way, lets explore each of them in more detail.

Transport Layer Security (TLS)

Transport Layer Security ("TLS", formerly "SSL") is one of the oldest and most widely used Internet security technologies.  It is the basis of secure web sites (HTTPS), secure email (STARTTLS), and many other Internet services.  TLS encrypts Internet communications.  When two computers connect over the Internet, TLS makes sure that everything that goes between them is completely scrambled and unreadable.  TLS also verifies Internet destinations.  When one computer attempts to connect to another computer over the Internet, TLS verifies that the answering computer really is who they say they are using SSL Certificates.

Email receivers use TLS to provide their SSL Certificate (which authenticates their identity) to email senders when a sender requests a connection with the receiver.  The receiver's SSL Certificate is issued specifically to the receiver and is considered secure only when it is signed by a Certificate Authority.  Email senders use TLS by checking the SSL Certificate provided by the receiver, and only connecting to the receiver if the SSL Certificate information matches what the sender was expecting.

If the sender can authenticate the receiver's identity, then the receiver and sender switch their connection from plaintext (human readable text) that was used to establish their initial connection to TLS encrypted text (which is scrambled and not human readable), like two people agreeing to switch from English to French.  Each TLS connection's encrypted text "language" (it's cipher) is uniquely created on each connection and is completely unintelligible by anyone but the sender and receiver for that connection only.

Sender Policy Framework (SPF)

Sender Policy Framework ("SPF") enables email receivers to authenticate that received email is being sent from an email server that is controlled by the sender and not an impostor.  With SPF, senders publish a list of the email servers that they own and control and tell the world, "Any email that says it is from my email domain name must come from one of these servers that I own and control."  This allows a sender to protect their email domain name from unauthorized use; only the email servers that they control can send email for the domain name(s) they own.

Senders use SPF by creating one SPF record in DNS for each domain name that they own, for example "spf.smithco.com".  If a sender owns more than one domain name, multiple SFP records will be created in DNS.  Each SPF record lists the IP address of every email server that is allowed to send email for the domain name.  If more than one email server is configured to send email for the domain name, multiple email server IP addresses will be listed in the SPF record for the domain name.

Receivers use SPF by looking up the sender's SPF record in DNS and only accepting email that came from an IP address that the sender listed therein.

DomainKeys Identified Mail (DKIM)

DomainKeys Identified Mail ("DKIM") is like an electronic version of the old-fashioned wax seal that is sometimes used to sign and protect physical letters from tampering.

DKIM lets receivers detect forged sender email addresses and altered email.  With DKIM, senders publish their public encryption key and tell the world, "Any email that says it was sent from my email domain name must be signed by my private encryption key, which you can validate with my public encryption key."  This allows a sender to protect their domain name from unauthorized use in sent emails; only emails signed by the sending domain name owner's private encryption key will be validated by receivers when they use the sending domain name owner's public encryption key.

An email's DKIM signature includes the digest of the email as it was created by the sender.  The sender is telling the world, "This email is unaltered if its current digest is identical to the digest I put in the DKIM signature."

Senders use DKIM by first publishing their public encryption key in a DKIM record in DNS.  If a sender owns more than one domain name, multiple DKIM records will be created in DNS.  Then, for every email that they send, they use a publicly available math function (known as a "hash algorithm") to compute a digest of the message contents and the important email headers like the TO:, FROM:, SUBJECT:, and DATE: headers.  They sign this digest using their private encryption key.  Then they add a DKIM header to the email that contains the signed digest, the name of the hash algorithm they used, and which headers they think are important.

The receiver uses DKIM by creating their own digest of the received email contents and important headers, using the same hash algorithm and headers list as the sender specified in the received email's DKIM header.  The receiver uses the sender's public key, which is located in the sender's DKIM DNS record, to decrypt the signed digest sent by the sender.  If the two digests exactly match, the receiver is assured of two things: one, that the email they received is identical to what the sender sent, and two, that the sender really sent it (because the public key decoded the same digest that the sender's private key encoded).  This is how senders protect their emails — only emails whose digest exactly matches the digest contained in their DKIM signature are guaranteed to be unaltered original emails and guaranteed to be from the stated sender.

Domain-based Message Authentication, Reporting, and Conformance (DMARC)

Domain-based Message Authentication, Reporting, and Conformance ("DMARC") enables email senders to tell email receivers what email security features should be present in each received email.  It builds on SPF and DKIM, allowing the sender to tell the receiver whether SPF, DKIM, or both should be present in the received email, and what to do with emails when one or both of these security feature(s) is missing or can't be authenticated.  This prevents a hacker from removing DKIM signatures or interfering with SPF domain checks to circumvent the use of these two email security features.  DMARC also enhances sender email security by instructing receivers to report back to senders the results of their DMARC security checks, thereby allowing the sender to monitor the integrity of their sent email security and detect security threats quickly.

Senders use DMARC by publishing instructions in their domain name's DMARC record in DNS that tells receivers to use SPF or DKIM or both to authenticate sender emails.  If a sender owns more than one domain name, multiple SFP records will be created in DNS.  The instructions also tell the receiver what to do with emails if both SPF and DKIM are missing or if one or the other (or both) can't be authenticated.

Receivers use DMARC by looking for the sender's domain name DMARC record from DNS.  If a DMARC record exists, the receiver knows it must use SPF, DKIM, or both to authenticate the sender's emails.  The instructions also give an email address for receivers to optionally send feedback about their SPF and DKIM authentication results to the sender.

Domain Name System Security Extensions (DNSSEC)

Domain Name System Security Extensions ("DNSSEC") assures that DNS records (e.g., the domain name's IP address records, email server records, SPF record, DKIM record, DMARC record, et al) are authentic and have not been altered.  DNS is critical to every facet of email security (or any kind of Internet security, for that matter).  As explained at the beginning of the section of this post titled, The Nine Email Authentication Technologies, the Domain Name System ("DNS") is the Internet's address book.

So far, we've explained how DNS looks up computer names, their associated IP address, and other relevant information.  For example, computers can only connect to each other on the Internet using IP addresses.  But people cannot (easily!) remember an IP address like "17.253.144.210".  But people can remember "apple.com".  DNS is what lets you type "apple.com" into your PC, and your PC knows to connect to "17.253.144.210".  DNS is also what lets an email sender tell an email receiver how to authenticate using SPF or DKIM (see previous sections).

DNSSEC is used to authenticate the integrity of DNS records.  It uses public/private key encryption to sign DNS records so that they become provably valid and certified as unaltered.  When DNSSEC is in use (enabling DNSSEC is not trivial) a private key is used to sign every DNS record associated with the domain name and the matching public key is uploaded to an upstream trusted DNS server.

DNSSEC uses a chain of trust to authenticate DNS records.  DNS root zones, which are the last parts of domain names, (for example ".com", ".net", ".org", etc.) are "trusted", meaning the DNS information they store is authentic and has not been altered.  DNS root zones are hosted on servers that are very physically and electronically protected.  They know how to obtain the public key for each domain under them, for example the "checktls" part of checktls.com.

Senders and receivers can both use DNSSEC to protect their DNS records by sending their public key to the DNS zone above them in the chain of trust and then signing each of their DNS records with their private key.

Senders and receivers can both use DNSSEC when looking up (referred to as "querying") DNS by adding an option to the query that says "use DNSSEC".  This tells DNS to retrieve the public key associated with the domain name and only return those DNS records that have been signed by the matching private key.

When DNSSEC is in use, it returns an authenticated denial of existence when a DNS record is not found.  This is a definitive confirmation by DNSSEC that says that the DNS record does not exist.  DNSSEC authenticated denial of existence is a critical tool in thwarting email impersonation because it assures that no one can add bad data to a domain name's DNS data.

Brand Indicators for Message Identification (BIMI)

Brand Indicators for Message Identification ("BIMI") provides a visual confirmation (a brand logo) that an email has been authenticated using DMARC.  The owner of a domain name uses BIMI to tell receiver's email client to authenticate the received email using DMARC; if the email authenticates, then a specific registered company logo is displayed in the email.  When reading email, if a user sees the BIMI-registered logo for the sender (the logo is visible only if the receiving email program supports BIMI; since BIMI is new, many email programs don't yet support BIMI so the logo may not be displayed) they are assured that the email came from the logo owner and that the email was authenticated using DMARC.

Senders use BIMI by publishing a BIMI DNS record that specifies that DMARC must be used by the receiver to authenticate received email and a URL that points to the location of their BIMI-registered logo.

Receivers use BIMI by first authenticating the received email using DMARC.  If DMARC authentication passes, the BIMI-registered logo is retrieved using the URL that is present in the domain name's BIMI DNS record and displayed along with the email.

DNS-based Authentication of Named Entities (DANE)

DNS-based Authentication of Named Entities ("DANE") was proposed as a way for domain names to self-authenticate their SSL Certificates, basically to eliminate the Certificate Authority ("CA") and sign their own SSL Certificates.  That did not happen, but DANE can be used to confirm the authenticity of CA-issued SSL Certificates by leveraging the authentication features of DNS.  A single trusted CA can undermine the security of the entire SSL Certificate system, because, by design, any CA can issue SSL Certificates for any domain name.  If hackers succeed in creating an illegitimate CA SSL Certificate (and they have), they would be able to create CA-issued SSL Certificates for any domain name and those SSL Certificates would not raise warnings on email servers.

DANE does two things.  It requests that TLS be used for all email communications, and it says "my certificate must be signed by this (these) CA(s) and only this (these) CA(s)."  DANE has multiple methods to perform this authentication, all of which are very technical and beyond the scope of this post.  The easiest way to think about DANE is that it sets rules for authenticating CA-issued SSL Certificates in a domain name's TLSA DNS record.  What gets authenticated and how the authentication is performed is governed by the rules that have been configured in the TLSA DNS record.  In addition to CA-issued SSL Certificate authentication, DANE requires that Transport Layer Security ("TLS") be active for DANE to work.

While other authentication technologies described in this article all benefit greatly from their DNS queries being protected by DNSSEC (see above), DANE requires DNSSEC to validate all DNS queries involved with DANE.  This is a big reason why DANE is not as popular as MTA-STS (next section) even though both do much the same thing.

The email sender queries the email receiver to authenticate the receiver and to determine if the receiver can guarantee a TLS connection.  If receiver authentication or the guarantee of a TLS connection fails, the sender can be configured to not send email.  DANE prevents downgrading of TLS to plaintext, impersonation of DNS records ("DNS spoofing"), and STRIPTLS (which tricks both sides into not using TLS).

Receivers use DANE by configuring the rules that govern CA-issued SSL Certificate authentication and TLS connection requirements in their domain name's TLSA DNS record.

Senders use DANE by fetching the TLSA record that corresponds to the receiver's domain name they are connecting to and verifying that the receiver's SSL Certificate meets the requirements specified in the receiver's TLSA DNS record, and only using TLS before allowing email to be sent.

Mail Transfer Agent — Strict Transport Security (MTA-STS)

Mail Transport Agent — Strict Transport Security ("MTA-STS") is an email security standard that enables email senders to authenticate email receivers AND request that the connection between sender and receiver be encrypted using TLS before the sender sends email.  Without MTA-STS, an email sender faces two major security issues: 1.) The email sender cannot authenticate that the email receiver is who they say they are, and 2.) The connection between the email sender and the email receiver may not be encrypted using TLS.

MTA-STS solves these security challenges by authenticating email receivers and using TLS.  This is accomplished by the receiver presenting the sender with a list of the receiver's email servers' names that are allowed to receive email, and by requesting that the sender's email servers use TLS to connect with the receiver.  Email senders that use MTA-STS will only connect to those receiver email servers specified by MTA-STS, and will only send email if TLS verifies the receiver's SSL Certificate and encrypts the transmission.  If either of these fails, the email receiver is not authenticated.

The email sender queries the email receiver to authenticate the receiver and to determine if the receiver can guarantee a TLS connection.  If receiver authentication or the guarantee of a TLS connection fails, the sender can be configured to not send email.  MTA-STS prevents downgrading of TLS to plaintext (after the TLS connection has been made), impersonation of DNS records ("DNS spoofing"), and STRIPTLS (which tricks both sides into not using TLS).  MTA-STS and DANE are both email authentication standards, but they each use a different method to provide the security.

You may be asking yourself, "Doesn't MTA-STS do the same thing as DANE?"  In a broad sense, the answer to this question is, "Yes."  The purpose of both technologies is to prevent the addition, alteration, or deletion of receiver email server names and request the use of TLS.  DANE does this in DNS.  MTA-STS does this in HTTPS.  DANE has never been widely adopted because it is generally harder to install and manage than MTA-STS.  DANE also requires DNSSEC be used, which is also difficult to install and manage in its own rite.

Receivers use MTA-STS by creating an MTA-STS record in DNS and an MTA-STS text file at a specific HTTPS URL (https://mta-sts.domainname/.well-known/mta-sts.txt) that declares their support for TLS and contains information about each of their receiving email servers, including each email server's name.

Senders use MTA-STS by checking a receiver's MTA-STS DNS record and its associated text file, which provides details about each of the receiver's email servers, and only using TLS before allowing email to be sent.

Transport Layer Security Reporting (TLS-RPT)

Transport Layer Security Reporting ("TLS-RPT") is a standard for reporting TLS failures to email receivers.  Email receivers have no awareness that the email senders can't sent email because TLS failed.  When an email cannot be sent by the sender because there are issues with TLS, it is TLS-RPT that reports back to the receiver why the sender was unable to use TLS.  TLS-RPT helps email receivers identify TLS issues and email security threats by reporting why sender TLS failed.

Receivers use TLS-RPT by creating instructions in their TLS-RPT record in DNS for how senders should report TLS-related failures to the receiver.

Senders use TLS-RPT by using the information contained in the receiver's TLS-RPT DNS record to send feedback about TLS-related failures to the receiver.

What Now?

This email authentication technology introduction gives you a foundation-level understanding about the nine technologies that are routinely used to validate the authenticity of email.  You should now be able to talk intelligently about each of them, to learn more about them, and be able to understand your own organization's implementation of them.

Email is the most common entry point for security breaches.  Email authentication is just one facet of overall email security, and email security is just one facet of protecting your organization's sensitive information.  The overall information security landscape is vast and it's often hard to know where and how to start protecting your sensitive information.

One way to start is by implementing email security "low hanging fruit".  A few of the technologies introduced above are easy to implement.  For example, TLS is universally available and only requires a signed certificate and following one of many step-by-step implementation instructions found on the Internet.

Whether you are just getting started, or you are well down an email security path, we cannot stress enough the importance of continuous testing.  No email security technology is "set it and forget it."  Email security standards evolve, software gets updated, SSL Certificates renew or expire, and things just break.  CheckTLS can continuously test every one of the email authentication technologies you just learned about so that you know they are working properly as your organization moves through time.  We invite you to learn about our testing products and services and how you can determine for yourself if your email is secure by visiting our home page.