Ever wonder how email is securely sent from one server to another? When using Simple Mail Transfer Protocol (SMTP) to send mail, we rely on a combination of StartTLS and Transport Layer Security (TLS) or Secure Sockets Layer (SSL) to encrypt our mail and help it safely land in the inbox.
But what is StartTLS?
StartTLS is a protocol command used to inform the email server that the email client wants to upgrade from an insecure connection to a secure one using TLS or SSL. StartTLS is used with SMTP and IMAP, while POP3 uses the slightly different command for encryption, STLS.
We’ll dig into the differences between TLS and SSL, the StartTLS process, and how to test StartTLS for your program.
Even though “TLS” is in its name, StartTLS works with both encryption protocols, TLS and SSL.
While StartTLS works with both protocols, we recommend using TLS over SSL. SSL is an older protocol and is not as secure as its successor, TLS. SSLv2 and SSLv3 have both been deprecated.
For reference, here’s a list of SSL and TLS protocols from oldest to newest:
SSLv2, SSLv3, TLSv1.0, TLSv1.1, TLSv1.2, TLSv1.3
Both the email client and email server need to agree on what connection to use. The email client may support TLSv1.3, but the email server may only support up to TLSv1.2. This means that both parties will need to use TLSv1.2 to proceed with the encryption.
For even more information on TLS vs. SSL, check out our docs page.
SMTP always starts unencrypted. The StartTLS command starts the negotiation between server and client. Here’s an outline of the communication that happens between the email client and email server.
Here’s a visual representation of the StartTLS process.
Which port should you use?
The port that uses StartTLS most often is port 587. It often requires email clients to use StartTLS to send mail. Other ports used to send encrypted mail are 25, 465, and 2525. Since port 25 was designed for mail transfer, not submission, your ISP may block email sent through this port. Port 465 is the second most commonly used port for StartTLS.
Opportunistic vs. Enforced TLS
There are a couple of different ways to set up your email encryption program by using either Opportunistic TLS or Enforced TLS:
- The process begins with the Transmission Control Protocol (TCP) handshake to help both the email client and server identify each other.
- The server identifies with 220 Ready that the email client can proceed with the communication.
- The client sends the server “EHLO” to inform the server that the client would like to use Extended SMTP (the more advanced version of SMTP that lets you include images, attachments, etc.).
- The client sends “250-STARTTLS” to the mail server to ask whether or not StartTLS is accepted.
- If the server sends back “go head,” the StartTLS connection can be created.
- The client restarts the connection and the email message has been encrypted.
Opportunistic TLS (or Explicit TLS) allows the email client to deliver on the highest encryption level the recipient server accepts. If the recipient server does not accept TLS, the email client will negotiate with the server and agree to downgrade to an unencrypted connection. The message will then be sent in an unencrypted, plain text form. This method is useful because you can use the same port for both encrypted and plain text mail.
Enforced TLS (or Implicit TLS) requires the mail to be sent over a secure connection. If the connection is not encrypted, the mail will be blocked from sending. This method is much more secure than Opportunistic TLS, but does lead to more mail being dropped.
Both approaches are widely used in the email world, so consider what makes the most sense for your program. If you are sending email that contains sensitive, personal information, it may be best to use Enforced TLS. On the other hand, if you’re sending non-sensitive material, like marketing or promotions, you may be more inclined to use Opportunistic TLS.
Other TLS use cases
TLS is frequently used for encrypting a variety of communication methods outside of email. Since TLS is a relatively simple, multi-step protocol, it makes it easy to adjust for a variety of communication types. This includes web browsers, SMS, and Voice over IP. In fact, a lot of companies use TLS to encrypt all communication between their web servers and browsers, even if the majority of the communication isn’t sensitive material.
For more information on how Twilio uses TLS, check out Twilio’s Security page.
SMTP is not secured by default, which means that if you were to send email over SMTP without StartTLS the email could be intercepted and easily interpreted. This is especially worrisome when sending sensitive, personal information like usernames, passwords, or bank information.
Without StartTLS, your personal information is at risk of being stolen.
When an email client uses StartTLS, it informs the server that the content must be encrypted. This way, if the mail is intercepted, the content has been scrambled and is very challenging to decipher. The email server and email client are the only ones that hold the key to decode the message.
There are certain drawbacks to using StartTLS. Email clients are susceptible to man-in-the-middle attacks because, in the initial connection between email client and server, the IP addresses are not encrypted.
Using StartTLS could also add some latency to the SMTP connection. This would not be enough of a delay to make it necessary to send unencrypted email, but it is good to keep in mind.
It’s important to test in advance to make sure the server is capable of processing StartTLS. If it isn’t capable of processing StartTLS you could accidentally send a fair amount of email that isn’t encrypted and is, therefore, susceptible to attack vectors.
Here is an example of how you would test StartTLS from SendGrid’s SMTP server.