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.
What about DANE?

DANE, or DNS-based Authentication of Named Entities is an Internet standard which could on its own do what MTA-STS + the preload list would cover combined. It’s a downgrade-resistant way for mailservers to discover and publish each other’s TLS information using another technology called DNSSEC. DNSSEC is a protocol for signing and verifying statements by owners of domain names.

DANE has been around for a while– so why doesn’t everyone use it already, and why do we need MTA-STS in the first place? DNSSEC presents some challenges. * If your domain’s TLD doesn’t support DNSSEC, then your mailserver cannot utilize DANE. A large majority of TLDs are DNSSEC-signed, but many country-code TLDs remain unsigned. * DNSSEC can be difficult to deploy correctly, for both signing and validation. For instance, to do validation properly, the mailserver needs a local, trusted DNSSEC-validating resolver; otherwise, your server relies on upstream DNS resolvers for validation. DNSSEC adoption has unfortunately remained stagnant (validation is at around 10-15% worldwide) for the past five years.

We still recommend deploying DANE for email security if you have the resources to maintain DNSSEC signing and validation properly. The Internet Society has a good explanation and list of related resources and Viktor Dukhovni’s slides from ICANN contain lots of DANE deployment best practices.

MTA-STS was designed in the absence of a technology like DNSSEC. It bootstraps trust off the WebPKI Certificate Authority ecosystem (that secures HTTPS), but is not a perfect solution either.

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 and ecosystem support.


DANE, or DNS-based Authentication of Named Entities, is an Internet standard designed for mailservers to publish and validate TLS information over DNS. Its security relies on DNSSEC, a protocol for publishing and authenticating signed DNS entries. The What about DANE? FAQ entry has more details.

MTA-STS + Preloading

MTA-STS is a protocol for advertising your mailserver’s TLS information and security policy over HTTPS. The MTA-STS FAQ entry has more details.

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. The list will preload TLS policies for domains that support MTA-STS.

What is MTA-STS?

MTA-STS is an Internet standard for mailservers to learn and save each other’s TLS information in order to prevent downgrade attacks from succeeding.

There’s two sides for MTA-STS to work. When an email is sent: * the receiving server must have its MTA-STS policy up, advertising correct TLS information * the sending server must be able to look up and remember the other server’s MTA-STS policy Our checker confirms whether a server has MTA-STS receiving support and offers suggestions if it detects misconfigurations. It’s difficult to check for sending support in an automated way. Of the larger mail providers, Gmail has sending support by default, and domains using Gmail can turn it on.

MTA-STS is not perfect; before server A has discovered server B’s TLS information and vice versa, connections between the two can be downgraded in /faq#insecure. That’s where the STARTTLS policy list comes in, to pre-load the TLS information for various heavy-use mailservers as well as individual opted-in mail providers and servers.

MTA-STS support is on the rise.

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.


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.
What is STARTTLS? 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.