Email Trust: Beyond Email Encryption and Authentication

SPF DKIM DMARC DNSSEC DANE MTA-STS TLS-RPT BIMI

TL;DR; Email security is no longer just the responsibility of the Sender.

Since the launch of CheckTLS in 2010, we have said that an email Sender, and only the Sender, is responsible for the safety of email on the Internet. We, and the industry, based that on the obvious fact that the Receiver has no idea that an email is coming or what is in it. How can a Receiver protect something they know nothing about? And we have said that TLS (Transport Layer Security) is sufficient to meet the Sender’s responsibility for safety, which is just to assure that the email is not snooped or changed (Encryption) and that it goes to the right place (Authentication).

Sure, Receivers assume some responsibility for email safety by demanding that Senders use multiple email protection mechanisms like TLS, SPF, DKIM, and DMARC, just in case an email should have been protected. But with the current adoption rate of these mechanisms by Senders, mandating them would cause the Receiver to lose over oner half of their emails. And adding these mechanisms requires adding infrastructure like more CPU, network bandwidth, and storage, which not only increases costs, but it also increases the risk for DDoS attacks. The more processing you do on an email, the easier it is to clog the system with bogus work.

However, as these protection mechanisms become more common, we at CheckTLS recommend that the Senders responsibility for the safety of email (Encryption and Authentication) is NOT all the protection that email requires. We believe that a Trust protection must be added to Encryption and Authentication. In this use of the word Trust we are referring to the contents or the meaning of the message, not just the bytes of the message. The bytes are still (mostly) the responsibility of the Sender, but the meaning of the message, the Trust, is a shared responsibility with the Receiver.

In other words, when a Receiver receives an email, they have some responsibility for determining if the content, the meaning, of the message, is valid. The Receiver doesn’t have to answer “Did I Encrypt the message?” and the Receiver doesn’t have to answer “Did I send the message (Authentication) to the right place?”, but the Receiver does need to answer the question: “Do I Trust what this message says?” – which may include answering a different facet of Authentication “Did the message come from the right place?”

The courts may use the legal principle of The Imposter Rule in ascertaining fault in cases of “bad” email. A “bad” email takes two main forms: the bytes of the message and the meaning of the message. Again, the Sender is responsible for making sure the bytes are not snooped or changed. But both the Sender and the Receiver, and more so the Receiver, are responsible for the meaning (Trust) of the message.

It is this responsibility of Trust that motivates the email security technologies that have been created to supplement TLS:

These are described in greater detail in Email Protection Technologies, and we show how to test them in How To Test Email Security. Here are brief descriptions of the technologies that help Receivers, and Senders, increase their Trust of email.

Trust Technologies for Receivers

Sender Policy Framework (SPF)
SPF allows a domain owner to specify which mail servers are authorized to send email on behalf of their domain. This helps protect against email spoofing and phishing, which can damage a brand's reputation and lead to spam.

DomainKeys Identified Mail (DKIM)
DKIM uses public-key cryptography to verify that an email was sent from an authorized server and that it was not altered in transit. It works by applying a digital signature to every email sent from a domain.

Domain-based Message Authentication, Reporting, and Conformance (DMARC)
DMARC helps prevent spoofing, phishing, and other email fraud by verifying that an email is genuinely from the domain it claims to be from. It builds upon and improves two older protocols, SPF and DKIM.

Brand Indicators for Message Authentication (BIMI)
BIMI allows companies to display their official, verified logo next to their email messages in supporting inboxes. This feature provides a visual confirmation of authenticity for the recipient, making it easier to recognize legitimate emails and distinguish them from phishing attempts.

Trust Technologies for Senders

DNS-based Authentication (DANE)
DANE allows a domain owner to cryptographically link an email server's TLS certificate to its domain name using DNSSEC. This process creates a secure, trusted channel for email to travel between mail servers, preventing man-in-the-middle and downgrade attacks. DANE works in conjunction with Transport Layer Security (TLS) encryption. Standard TLS, connections are often "opportunistic"—meaning if a secure connection fails, the system may default to an unencrypted one. This leaves email vulnerable to interception. DANE solves this problem by:

Mail Transfer Agent Strict Transport Security (MTA-STS)
MTA-STS enforces encrypted email delivery between email servers. It is designed to close vulnerabilities in older email protocols that could allow attackers to intercept, read, or alter emails while they are in transit.

Transport Layer Security Reporting (TLS-RPT)
TLS-RPT provides domain owners with reports on email encryption delivery issues. It is designed to give visibility into potential failures that can expose emails to interception or downgrade attacks.

Trust Technologies for Both Receivers and Senders

Domain Name System Security Extensions (DNSSEC)
DNS is a component of every one of the technologies described here, so protecting DNS and preventing adds, changes, or deletions of DNS results is critical. DNSSEC adds security to the standard DNS by allowing DNS resolvers to cryptographically validate the authenticity and integrity of DNS data, preventing attacks like DNS spoofing and cache poisoning. It works by having authoritative DNS servers digitally sign their DNS records using cryptographic keys, with a hierarchical chain of trust linking these signed zones together. A DNSSEC-aware resolver can then verify these digital signatures, ensuring that the DNS response received is authentic and hasn't been tampered with.

Email protection is not just the responsibility of Senders anymore!