In 2013, documents leaked by Edward Snowden revealed that intelligence agencies were intercepting email traffic between major providers' data centers. The connections weren't encrypted—email flowed in plaintext across fiber optic cables, easily readable by anyone who could tap them.
The response was swift. Google, Microsoft, Yahoo, and others rapidly deployed encryption between their servers. The technology they used was STARTTLS, a mechanism that had existed for years but wasn't universally implemented. Within months, the majority of email traffic between major providers was encrypted.
STARTTLS isn't perfect, but it's the foundation of email encryption in transit. Understanding how it works helps you understand both its protection and its limitations.
How STARTTLS works
STARTTLS is an SMTP extension that upgrades a plaintext connection to an encrypted one. The name literally describes what happens: you start TLS.
Here's the sequence. A client connects to a server on a standard SMTP port. The connection begins unencrypted—both sides can see everything in plaintext. The client sends an EHLO command, and the server responds with its capabilities, including "250-STARTTLS" if it supports encryption.
If the client wants encryption (and it should), it sends the STARTTLS command. The server responds with "220 Ready to start TLS." At this point, both sides perform a TLS handshake—the same process that secures HTTPS connections. Once the handshake completes, everything that follows is encrypted.
The client then starts the SMTP conversation over again, but now encrypted. It sends another EHLO, authenticates if needed, and proceeds with sending email. Anyone watching the network sees only encrypted gibberish.
This "upgrade" approach is called opportunistic encryption. The connection starts unencrypted, and encryption is added if both sides support it. This differs from implicit TLS (used on port 465), where the connection is encrypted from the very first byte.
Why the upgrade approach
You might wonder why email doesn't just start encrypted, like HTTPS does. The answer is historical compatibility.
SMTP was designed in 1982, long before encryption was a concern. Millions of mail servers were deployed speaking unencrypted SMTP. When encryption became important, the protocol needed to evolve without breaking existing infrastructure.
STARTTLS solved this by making encryption optional and negotiated. Old servers that don't support it simply don't advertise the capability, and connections proceed unencrypted. New servers can upgrade to encryption when talking to other new servers. The ecosystem could migrate gradually.
This backward compatibility came with tradeoffs. The upgrade mechanism creates a window of vulnerability, and the optional nature means encryption isn't guaranteed. But it enabled encryption to spread across the email ecosystem without requiring a flag day where everything changed at once.
The security limitations
STARTTLS provides real protection, but it has known weaknesses.
The biggest issue is the downgrade attack. Because the STARTTLS negotiation happens in plaintext, an attacker who can intercept traffic can strip out the STARTTLS capability advertisement. The client thinks the server doesn't support encryption and proceeds unencrypted. Neither side knows the attack happened.
This isn't theoretical. Researchers have documented ISPs and nation-states performing STARTTLS stripping attacks. Your email might be encrypted when it leaves your server and encrypted when it arrives at the destination, but somewhere in the middle, someone removed the encryption and read everything.
Certificate validation is another weakness. Many mail servers don't strictly validate certificates during STARTTLS. They'll accept self-signed certificates, expired certificates, or certificates for the wrong hostname. This makes deployment easier but means a man-in-the-middle attacker could present a fake certificate and intercept traffic.
These limitations are why MTA-STS and DANE exist—they provide mechanisms to require encryption and validate certificates, closing the gaps that STARTTLS leaves open.
STARTTLS vs implicit TLS
Email supports two encryption approaches: STARTTLS (explicit TLS) and implicit TLS.
With STARTTLS, the connection starts unencrypted and upgrades. This is used on port 587 for submission and can be used on port 25 for server-to-server transfer.
With implicit TLS, the connection is encrypted from the first byte. There's no plaintext phase, no upgrade negotiation. This is used on port 465 for submission.
Implicit TLS is arguably more secure because there's no opportunity for downgrade attacks during connection establishment. The TLS handshake happens immediately; if it fails, the connection fails. There's no fallback to plaintext.
However, STARTTLS is more widely deployed, especially for server-to-server communication. Port 25 with STARTTLS is how most email flows between servers. Implicit TLS on port 465 is primarily used for client submission.
For your own email submission, either approach is fine if properly implemented. For server-to-server email, STARTTLS on port 25 is the standard, supplemented by MTA-STS or DANE for stronger guarantees.
Checking STARTTLS support
You can verify whether a server supports STARTTLS using command-line tools.
Connect with telnet or netcat to the SMTP port and issue an EHLO command. The server's response lists its capabilities. If "250-STARTTLS" appears in the list, the server supports encryption upgrades.
For testing the actual TLS connection, use OpenSSL: "openssl s_client -starttls smtp -connect mail.example.com:25". This connects, issues STARTTLS, performs the TLS handshake, and shows you the certificate and connection details.
Online tools like CheckTLS and MXToolbox can test STARTTLS support for any domain's mail servers. They'll report whether encryption is available and provide details about the certificates in use.
Monitoring STARTTLS across your email traffic helps identify servers that don't support encryption. If you're sending sensitive email to a domain that doesn't support STARTTLS, that email travels in plaintext.
STARTTLS in practice
Most modern email infrastructure supports STARTTLS, but implementation quality varies.
Major email providers (Gmail, Microsoft, Yahoo) support STARTTLS and use it for the vast majority of their email traffic. Google publishes transparency reports showing what percentage of email to and from Gmail uses encryption—it's over 90% for most traffic.
Corporate mail servers vary widely. Well-maintained Exchange and Google Workspace deployments support STARTTLS. Older or poorly maintained servers might not. When sending to corporate domains, encryption isn't guaranteed.
Self-hosted mail servers should always enable STARTTLS. The configuration is straightforward in modern MTA software. There's no good reason to run an unencrypted mail server in 2024.
Email services (SendGrid, Mailgun, etc.) support STARTTLS for both inbound and outbound connections. When you send through these services, they'll use encryption when the destination supports it.
Beyond STARTTLS
STARTTLS provides encryption in transit, but it's not end-to-end encryption. The email is decrypted at each server along the path. If you need true end-to-end encryption—where only the sender and recipient can read the message—you need S/MIME or PGP.
For stronger transport security, MTA-STS and DANE address STARTTLS's weaknesses. MTA-STS publishes a policy requiring encryption and specifying valid certificates. DANE uses DNSSEC to authenticate certificates. Both prevent the downgrade attacks that STARTTLS alone can't stop.
The email ecosystem is gradually moving toward mandatory encryption. Google and Microsoft increasingly penalize unencrypted connections in their spam scoring. Future standards may require encryption rather than making it optional.
Frequently asked questions
Does STARTTLS encrypt my email end-to-end?
No. STARTTLS encrypts email in transit between servers, but the email is decrypted at each server. Server administrators and anyone with server access can read the content. For end-to-end encryption, use S/MIME or PGP.
Is STARTTLS the same as TLS?
STARTTLS is a command that initiates TLS encryption on an existing connection. TLS is the encryption protocol itself. STARTTLS is the mechanism; TLS is what it activates.
Why do some emails still go unencrypted?
STARTTLS is optional. If the receiving server doesn't support it, or if a man-in-the-middle strips the capability, email falls back to plaintext. MTA-STS and DANE help prevent this, but adoption isn't universal.
Should I require STARTTLS for all email?
For sending, you can prefer encryption but may need to allow fallback for servers that don't support it. For receiving, requiring STARTTLS might reject legitimate email from poorly configured senders. MTA-STS lets you require encryption with more nuance.