How does email work?

Email typically makes more than one hop in order to be delivered. Let’s say you have an email address @gmail.com. You open your email client, which might be a desktop app like Thunderbird or Outlook, a mobile app, or a website in your browser, like Gmail and Yahoo both provide.

Then you draft an email to your friend, who has an email address @eff.org. What happens when you press “SEND”?

  1. Your email is sent to and queued for delivery at Gmail’s email servers.
  2. Then, Gmail transmits your email to EFF’s email servers, where the email stays and waits until your friend opens their own mail client.
  3. Your friend’s mail client then asks EFF’s mail server whether they have any outstanding mail, and EFF transmits the relevant messages to your friends computer.
How can my email be insecure?

As mentioned in the previous section, your email goes through multiple hops! Each of these hops have to be secure and authenticated for your email to reliably be delivered securely.

how is email insecure diagram

Passive monitoring

Typically, Internet traffic between two computers is secured using Transport Layer Security. Since your email goes through multiple hops, if any of the hops it goes through are insecure, then your email is visible to anyone on the same network. This is referred to as “passive monitoring.” For example, if hop (1) is unencrypted, anyone on your WiFi network can read the email your sending!

For hops (1) and (3), you’ll want to make sure the connection between your email client and the mailserver is secure. If you use a web email client through your browser, make sure the site has “HTTPS” at the beginning of the URL— this means it’s using TLS for the connection.

For hop (2), you’ll want to make sure both your mailserver and the destination mailserver support “STARTTLS,” or TLS for email — you can use our STARTTLS checker to do this!

Active monitoring

active monitoring diagram

Although we depicted each individual connection as a single “hop,” beneath the surface, there are many computers along the path of each “hop” that help you get to your final destination. One of these computers on the path between you and gmail.com could lie to you and impersonate gmail.com. This is referred to as “active monitoring” — where an attacker on the path can impersonate your destination, and then monitor the email you’re sending.

In order to verify that you really are talking to gmail.com, the computer that you’re connected to typically presents a certificate — that is, signatures from various authorities on the Internet that confirm that this computer is gmail.com.

For hops (1) and (3), if you’re using a webmail client through your browser, you’ll want to check for a “green lock” next to the URL bar, in addition to HTTPS, to make sure you really are talking to the correct computer!

For hop (2), you’ll want to make sure both your mailserver and the destination mailserver support “STARTTLS” and present a valid certificate. Again, you can use our STARTTLS checker to do this!

Downgrade attacks

downgrade attacks diagram

This section only applies to hop (2). Suppose Gmail and EFF’s mailservers want to deliver mail to each other. As we mentioned previously, TLS is supported over email! Unfortunately, not all mailservers support TLS, so before sending each other mail, they ask each other:

EFF: Hey, let’s START a TLS connection?

Gmail: Yeah, ok!

After which they would proceed by encrypting any further communication. Unfortunately, this first “negotiation” phase is sent in-the-clear, so any computer on the network between Gmail and EFF— for instance, an ISP— can alter this traffic. As a result, a machine in the middle can simply drop EFF’s request, or alter Gmail’s response to indicate that they don’t support TLS. This is typically referred to as a “downgrade attack”.

In 2014, researchers discovered that governments were actually doing this. For instance, in Tunisia, 94% of email being sent to Gmail was sent in-the-clear.

This happens because email servers can’t tell if someone they’re talking to (1) legitimately does not support TLS, or (2) there’s an active attacker on the network trying to read the email traffic. The goal of the STARTTLS Policy List is to provide a list of mailservers that support TLS, so you can distinguish between these two worlds, and decide to behave accordingly.

Check if your email server is on the STARTTLS Policy List, our index of high-security email domains, so people can email you securely.

Does STARTTLS encrypt email so only I and the recipient can read it (i.e. end-to-end-encryption)?

No, STARTTLS only secures communication between mailservers (hop 2 in this figure). Even if each of your hops are secured and encrypted, your email provider, like Gmail and Yahoo, can still read your email. If you’ve heard of PGP, PGP encryption can provide end-to-end encryption for you, although it can be difficult to use. If you want to take advantage of all the benefits of end-to-end encrypted messaging, check out our series on Secure Messaging.

If I use webmail on a secure (HTTPS) site, does my provider need to use STARTTLS too?

Yes, you should make sure your email provider, and your recipient’s email provider both support STARTTLS! As we mentioned in “How can my email be insecure?”, email goes through multiple hops— the webmail-to-server hop is just one of them.


What's STARTTLS Everywhere?

STARTTLS Everywhere is a project by EFF to improve the security of the email ecosystem. We want to increase and improve STARTTLS adoption and improve solutions for downgrade attacks on secure email communications.

What does the STARTTLS Checker do?

This tool checks whether your email domain…

Supports STARTTLS?

  • “STARTTLS” is the command an email server sends if it wants to encrypt communications (using Transport Layer Security or “TLS”) with another email server. If your server supports STARTTLS, that means any other server that supports STARTTLS can communicate securely with it.
  • Does your email server send the STARTTLS command correctly, and does it accept the STARTTLS command from other servers?

Uses a secure version of TLS?

  • TLS has changed many times over the years. Researchers have discovered security flaws in some older versions, named “SSLv2” and “SSLv3”, so technologists across the Internet are working to deprecate SSLv2/3.
  • Does your email server disallow establishing a valid TLS connection over SSLv2/3?

Presents a valid certificate?

  • Even if you think you’re talking to a service named “eff.org”, it could be an impersonator pretending to be “eff.org”. Checking a mail server’s certificate helps ensure that you really are talking to the actual service.
  • In order for your certificate to be valid for your email domain, it should be unexpired, chain to a valid root from Mozilla’s CA certificates list, and one of the names on the certificate should either match the domain (the part of an email address after the @) or the server’s hostname (the name of the server, as indicated by an MX record).

Preloaded on our STARTTLS policy list?

  • Even if you pass the above checks, someone sitting between your server and other mailservers can choose to drop “STARTTLS” messages and fool servers into thinking that you do not support TLS.
  • To prevent this from happening, if you pass all the previous checks, you can add your domain to our index of high-security email domains so servers have another point of reference to discover that you support STARTTLS encryption.
How can I make my mailserver more secure?

Do you have STARTTLS enabled?

First thing’s first: consult your mailserver’s documentation or contact your hosting provider about how to enable STARTTLS for your mail delivery.

Are your TLS parameters secure?

There’s a tradeoff in the mailserver world you’ll need to make between backwards-compatibility (so you can encrypt with as many mailservers as possible) and requiring strong security. Here are some various things we recommend you do to make your mailserver robust, while still allowing it to encrypt with modern mailservers.

Is your certificate valid?

Standard practice is to obtain a certificate matching the hostname of the mailserver. However, you can also obtain a certificate matching your email domain (the part of the email address after the @) for a stronger security guarantee.

You can obtain a valid certificate automatically and for free from Let’s Encrypt using Certbot! Consult your mailserver documentation or contact your hosting provider for how to install these certificates.

Do you have some sort of downgrade prevention?

If you already meet all the above requirements, you can add your domain to the STARTTLS Policy List to protect against downgrade attacks.

How can I protect my secure mailserver against downgrade attacks?

Since STARTTLS negotiation is done in the open, the process of upgrading an email connection to TLS is susceptible to tampering. There are a couple of proposed solutions for this, each with varying degrees of effectiveness.


DANE, or DNS-based Authentication of Named Entities relies on DNSSEC, a protocol for publishing and authenticating signed DNS entries. Mailserver operators would sign their MX records with DNSSEC and publish a record alongside them containing the public key that the mailserver is expected to use in TLS. So long as senders trust the DNSSEC signature chain, senders can discover both 1) whether to expect a STARTTLS connection, and 2) how to validate the recipient’s certificate. Full DANE deployment presents a scalable solution for mailservers to clarify certificate validation rules and prevent downgrade attacks. However, DANE is dependent on deployment and validation of DNSSEC, which has unfortunately remained stagnant (validation is at around 10-15% worldwide) for the past five years.

The Internet Society has a good explanation and list of related resources if you’re interested in deploying both DNSSEC and DANE.


MTA-STS is an upcoming protocol for advertising your mailserver’s security policy. Mailserver operators are expected to 1) publish a DNS record indicating MTA-STS support, and 2) serve a JSON file describing their security policy over HTTPS at a .well-known address. Without DNSSEC to authenticate the related DNS record, MTA-STS is still a trust-on-first-use protocol, similar to HSTS for the web. It’s in last call at the IETF, so few MTAs have implemented it so far.

STARTTLS Policy List

The STARTTLS Policy List’s aim is to decouple secure email from DNSSEC adoption with a stop-gap, intermediate solution to secure email delivery today rather than later. Once a protocol like MTA-STS starts to gain adoption, the list may optionally indicate whether a domain supports MTA-STS, rather than the full policy of a domain.

What is the STARTTLS Policy List?

The STARTTLS Policy List is a list of email domains who meet a minimum set of security requirements.

By providing a list of email domains that support TLS encryption and present valid certificates, the STARTTLS Policy List gives mailservers another point of reference to discover whether other mailservers support STARTTLS. Then, if a man-in-the-middle prevents a sender from receiving a recipient’s “STARTTLS” message, the sender will know that an attack is occuring if the recipient domain is on the STARTTLS Policy List.

You can request your own email domain to be added to the list, but make sure to read the details.