Pangram verdict · v3.3
We believe that this text is a mix of AI and human-written content.
AI likelihood · overall
MixedArticle text · 1,485 words · 33 segments analyzed
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.