Understanding email encryption

Encrypted email sounds good, but what does it really mean? Email can be encrypted in many different ways, at different times, for different purposes. Each protects against different threats, and may have downsides to be weighed up. Understanding your options helps you make informed choices about your privacy and security.

What are you protecting against?

Before diving into encryption methods, it’s worth asking: what threats actually matter for your email? For most people, the realistic concerns are:

• Account compromise: phishing or password reuse giving attackers access to your account
• Mistaken spam detection: causing important mail to go missing
• Malware: getting a virus via email, either linked or as an attachment
• Accidental deletion: losing vital data due to human error

Far less common, although also important, are:

• Network eavesdropping: someone on your WiFi or ISP intercepting your traffic
• Data breaches: attackers gaining access to stored email through a security vulnerability
• Physical theft: stolen devices or hard drives exposing your data

For a smaller number of people — journalists protecting sources, activists in hostile countries, or those facing sophisticated adversaries — the threat model expands to include insider threats at providers and legal compulsion by governments. Different encryption approaches help protect (or may even hinder protection) against subsets of these threats, and understanding this helps you choose the right balance.

Encrypting the connection to your email provider

Whenever you connect to your email provider, TLS (Transport Layer Security) encrypts everything between your device and the server. This protects you from eavesdroppers on your local WiFi network, your ISP, and anyone monitoring network traffic between you and your email service. This standard has been widely adopted and modernised, the latest version being TLS 1.3, which mandates the strongest ciphers and is the foundation of today’s secure internet.

But encryption alone isn’t enough. You also need assurance you’re actually talking to your email provider and not an imposter. This is where Public Key Infrastructure (PKI) comes in. When you connect to Fastmail or Gmail, the server presents a certificate that’s been digitally signed by a trusted Certificate Authority (CA) like Let’s Encrypt. Your browser or email client checks this signature against its built-in list of trusted CAs, verifying that the certificate was legitimately issued to that domain. This prevents attackers from intercepting your connection by pretending to be your email provider — even if they can redirect your traffic, they can’t obtain a valid certificate for a domain they don’t control.

The system was strengthened significantly with the introduction of Certificate Transparency (CT) logs: public, append-only records of every certificate issued by participating CAs. Domain owners can monitor these logs to detect if someone fraudulently obtains a certificate for their domain, and browsers now require certificates to be logged before trusting them. While no system is perfect — CAs have occasionally been compromised or tricked into issuing bad certificates — PKI combined with Certificate Transparency provides strong, practical assurance that your encrypted connection terminates at the server you intended to reach.

Fastmail fully supports the latest TLS 1.3 standard. We also use HTTP Strict Transport Security (HSTS) to ensure browsers never try connecting to us without TLS. Similarly, we ensure the ports for unencrypted IMAP/POP/SMTP are closed on our servers, so email apps do not try to connect without encryption (this is why we have always preferred “implicit” TLS over STARTTLS, which is also now the recommendation of the IETF).

Encrypting email between servers

When you send an email, it first goes to your email provider’s server, and then they send it on to the recipient’s email server. The more interesting challenge lies in that transit between different servers.

Server-to-server encryption relies on “opportunistic TLS”, meaning servers attempt encryption but fall back to unencrypted delivery if the receiving server doesn’t support it. Fastmail has supported this for inbound mail since April 2009 and for outbound mail since January 2010.

The fundamental limitation is that opportunistic TLS can be defeated by active attackers, commonly referred to as a man-in-the-middle (MITM) attack. A sophisticated adversary positioned between mail servers can strip the STARTTLS command from the initial handshake, forcing an unencrypted connection. There is still enough legitimate mail sent to, or received from, servers that don’t support encryption that mandating it for everyone would lose an unacceptable amount of wanted email.

Additionally, servers don’t verify certificates by default. They accept any valid-looking certificate without confirming it actually belongs to the destination server. This is because verifying the certificate adds no security when an active attacker could just fall back to an unencrypted connection.

MTA-STS and DANE attempt to close the gaps

Two protocols address these vulnerabilities, though adoption remains limited.

MTA-STS (Mail Transfer Agent Strict Transport Security) lets domains declare they support and require STARTTLS encrypted connections, including a valid certificate, when receiving email for addresses at that domain. Senders can check this policy and must refuse to send mail if they are unable to establish an encrypted connection with a valid certificate for the receiving domain.

MTA-STS is reasonably straightforward to deploy: it requires only a DNS record and a policy file hosted over HTTPS. If something goes wrong, the worst case is that some incoming mail gets delayed or bounced — it cannot affect websites or other uses of the domain.

DANE (DNS-Based Authentication of Named Entities) takes a different approach, publishing TLS certificate information directly in cryptographically-signed DNS records via DNSSEC. This eliminates dependence on certificate authorities and the “trust on first use” weakness of MTA-STS — but at significant operational cost.

DNSSEC is not supported by all domains (it depends on the registry for the top-level domain). More importantly, DNSSEC’s deployment complexity significantly increases the likelihood of a serious outage. Unlike most system failures, DNSSEC errors are uniquely unforgiving: when there’s a routing problem, you fix it and service is restored immediately, but when there’s a DNSSEC problem, broken records can persist in caches across the internet for hours or days.

Even sophisticated operators get this wrong. In October 2023, Cloudflare’s 1.1.1.1 resolver — one of the world’s most popular DNS services — experienced hours of failures when DNSSEC signatures in their cached root zone expired. In May 2023, New Zealand’s .nz country-code TLD triggered a multi-day availability incident during a routine DNSSEC key rollover. There is a long history of similar outages.

At Fastmail we know security is not just about confidentiality (no one else can read your email). Availability (you can read your email) and integrity (your email cannot be corrupted or modified by others) are just as important. For this reason, we don’t currently consider the confidentiality benefits of DANE over MTA-STS to be worth the trade-off against increased availability risk. Other major providers such as Google and Yahoo have made similar choices, favouring MTA-STS over DANE. However, we regularly re-evaluate our position on this as the global ecosystem evolves.

For most users, the practical upshot is that email traveling between major providers is almost certainly encrypted in transit. Sophisticated nation-state attackers who can manipulate network traffic may be able to downgrade connections to intercept mail in the absence of DANE or MTA-STS. However, doing so at scale would almost certainly be noticed, and targeting specific individuals is very difficult in high-volume mail flows between major providers.

Encrypting email at rest

Once email reaches a server, encryption at rest protects it while stored on disk. This typically means full-disk encryption using technologies like BitLocker, LUKS, or ZFS dataset encryption, using keys held by the email provider.

This architecture protects against specific threats. If someone physically steals a hard drive from a data center, or if decommissioned drives aren’t properly wiped, the data remains unreadable. Encryption at rest defends against physical data center breaches and helps meet compliance requirements for regulations like GDPR and HIPAA.

As the email service holds the keys, legal requests backed by valid court orders can compel providers to decrypt and hand over data. And if attackers gain full control of a server, encryption at rest provides no protection because the keys are already loaded.

Fastmail stores all user data on encrypted disk volumes, including backups, with encryption keys retained solely under our control. We maintain strict access controls with comprehensive logging and auditing. Our transparency report details the number of legal requests we receive and respond to each year.

The trade-offs of zero-access encryption

Services like Proton Mail and Tuta offer zero-access encryption, where encryption keys are derived from your password on your device, meaning even the provider cannot decrypt your stored email. When you log in, your password decrypts the key locally; the server never sees it.

For users whose threat model prioritises protection against insider threats or government compulsion — and who are willing to accept significant trade-offs in functionality — zero-access encryption is a legitimate choice. It can provide real protection against insider attacks, data breaches, and limit the data handed over in response to court orders. However, it’s important to understand both what it protects against and what it doesn’t, as the additional protections of zero-access encryption are limited in ways that are sometimes understated:

• New mail can still be intercepted. Unless the email is end-to-end encrypted (see the next section), the provider will have access to the unencrypted version before encrypting it with the user’s public key. An interception court order or rogue employee could still take a copy at this point.
• Not all data is encrypted. Email addresses, timestamps, and in Proton Mail’s case, subject lines, stay unencrypted. Who you’re talking to, when, how often, and the summary of what it’s about is often more important than the contents of the email itself.
• Only protects against read-only server compromise. Most people access their email through the browser. The code that decrypts the email is therefore loaded on demand from the provider’s server — if the server is compromised, the code can be modified to capture your password. Law enforcement may also be able to compel this change for specific users subject to a court order.
• An unencrypted copy exists elsewhere. Even if your copy is encrypted, the senders likely retain a fully readable copy of every message you receive.

Zero-access encryption also has significant trade-offs in functionality:

• Password loss means data loss. Forget your password without a recovery phrase, and your email is gone forever. There’s no “reset password” in the traditional sense. Many years of experience have taught us that people forget or lose their password all the time. Even sophisticated users who swear it would never happen to them have found themselves locked out. Password reset flows can be a weak point in securing an account, but at Fastmail we have a very carefully considered automated system for secure account recovery.
• Search capabilities are constrained. Encrypted content cannot be seen or indexed on servers. Client-side search indexes are possible, but require downloading all mail to every device — often impractical for large accounts with tens of gigabytes of mail.
• Standard email clients don’t work. Zero-access encryption prevents the provider directly offering standard IMAP or JMAP protocols. This also makes migrating to another provider difficult — it’s the ultimate vendor lock-in.
• Customer support is limited. Because the provider cannot access your mail even with your permission, many issues become impossible to help with. Business features like shared mailboxes and compliance tools are often unavailable.

End-to-end encrypted email

True end-to-end encryption, where only the sender and recipient can read the message, has existed for email since the 1990s through S/MIME and OpenPGP. Yet neither has achieved meaningful consumer adoption despite decades of availability.

S/MIME uses certificates from Certificate Authorities and is supported by some enterprise email clients. It has some traction in organisations with existing PKI infrastructure where you can find a recipient’s public key in an internal corporate directory, but is rarely used outside of this.

OpenPGP uses a decentralized “Web of Trust” where users vouch for each other’s keys. The Web of Trust is practically dead according to security researchers, and PGP suffers from a myriad of design problems: it leaks metadata, is not forward secure, and lacks practical key rotation. The seminal 1999 study “Why Johnny Can’t Encrypt” found that only 4 of 12 participants could properly encrypt email with PGP within 90 minutes. Follow-up studies in 2006 and 2019 found users still struggling with “finding and verifying other people’s public encryption keys.” Even PGP inventor Phil Zimmermann had difficulty decrypting an email in 2015 due to version incompatibility.

A fundamental challenge for any end-to-end system is key distribution and rotation. To send an end-to-end encrypted message to someone, you first need to obtain their public key (and be absolutely sure it’s theirs!). There is no infrastructure for doing this at the moment, let alone for rotating keys regularly in accordance with cryptographic best practice. Without key rotation, a compromised key or password means all previously intercepted email can be decrypted.

Contrast all this with Signal or WhatsApp, where encryption works automatically because a single organisation controls the full software stack rather than using open protocols. They generate keys automatically when you install the app, discover contacts through phone numbers, and update security protocols universally. Email’s federated architecture — where any client can talk to any server — makes this unified approach impossible.

End-to-end encryption also fundamentally conflicts with features email users depend on. Server-side search becomes impossible when the server can’t read content — even just keeping a searchable archive of all your messages is antithetical to security best practice. Phishing detection and malware prevention (two of the biggest security risks!) require inspecting messages. Multi-device access requires synchronising private keys across devices — a security risk. And crucially, email headers including To, From, and Date cannot be encrypted without breaking email’s basic functionality.

As cryptographer Bruce Schneier concluded: “The things we want out of e-mail, and an e-mail system, are not readily compatible with encryption.”

The necessary trade-off between privacy and security

There’s an inherent tension between strong privacy protections and the ability to combat abuse. Spam filters, phishing detection, and malware scanning all require reading email content, or at least work more effectively when they can. A provider that truly cannot see your messages cannot protect you as effectively from threats within them.

This creates real consequences. With server-side content inspection, providers can identify phishing attempts by analysing links and sender patterns. They can quarantine malware before it reaches your inbox. They can detect account compromise by recognising unusual behaviour patterns. These protective capabilities are reduced or eliminated with end-to-end encryption.

Choosing your own balance

Email security isn’t binary — it’s a spectrum of trade-offs. Transport encryption (TLS) is now universal and protects against passive surveillance. Encryption at rest guards against physical theft. Zero-access encryption limits insider access but sacrifices functionality. True end-to-end encryption provides the strongest content protection but remains impractical for most users and has significant usability and security issues of its own.

For highly sensitive communications, dedicated messaging apps like Signal offer much stronger guarantees than any email solution can provide. For everyday email, transport encryption combined with encryption at rest provides meaningful protection against the most likely threats while preserving the searchability, spam filtering, and convenience that make email useful.

Here’s the honest truth: if you are a journalist trying to protect a source, or face nation-state adversaries, you probably shouldn’t use email — use an encrypted messaging app instead. But for the vast majority of communications, modern email security offers substantial protection while maintaining the features that make email indispensable.

Fastmail’s ongoing approach to email and encryption

Fastmail has been doing email for over 25 years. We know that email is your electronic memory and keeping your messages accessible, private and secure are our top priorities. We keep your emails private and secure with encryption in transit and on our servers, strong authentication options, and innnovative features like Masked Email. We keep your email accessible by concentrating on rock-solid reliability, with full multi-data center redundancy, and a lightning-fast interface with powerful search, capable of handling decades of mail with ease. We regularly evaluate the tradeoffs required to provide the best overall user experience and privacy possible taking into account all the technical and practical options available.