What is StartTLS?

What is StartTLS?

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 StartTLS and Transport Layer Security (TLS) to encrypt mail as it moves between servers. 

But what is StartTLS?

StartTLS is an email protocol command that tells a mail server to upgrade an existing plain-text connection to an encrypted one using TLS. StartTLS is used with SMTP and IMAP, while POP3 uses the slightly different command for encryption, STLS. 

Below, we’ll cover how StartTLS differs from TLS, how the StartTLS handshake works, which port to use, and how to test and troubleshoot it.

StartTLS vs TLS: What's the difference?

StartTLS and TLS work together. TLS (Transport Layer Security) is the encryption protocol that secures your data. StartTLS is the command that switches an existing connection over to TLS.

StartTLS is a command. The connection starts unencrypted, then the client asks the server to upgrade it. This is also called explicit TLS.

TLS is the encryption protocol that protects the data. TLS 1.2 and 1.3 are the current versions. TLS 1.0 and 1.1 are deprecated, and SSL is retired.

When people compare StartTLS vs. TLS for email, they usually mean StartTLS vs. implicit TLS:

StartTLS makes email encryption more flexible because it allows the same port to handle both encrypted and unencrypted connections. Without StartTLS, you'd need separate ports for secure and insecure email—which is exactly what happens with implicit TLS on port 465.

StartTLS is the process, TLS is the protection. You need both for secure email transmission.

For even more information on TLS vs. SSL, check out our docs page.

How does StartTLS work?

The StartTLS process

An SMTP connection on port 587 or 25 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.

1. TCP connection: The client opens a connection to the mail server, usually on port 587.
2. Server greeting: The server replies with a 220 code to say it’s ready.
3. EHLO: The client sends EHLO to start an Extended SMTP (ESMTP) session.
4. STARTTLS advertised: The server lists the extensions it supports. A line reading 250-STARTTLS means encryption is available.
5. STARTTLS command: The client sends STARTTLS, and the server replies “220 Ready to start TLS.”
6. TLS handshake: The client and server agree on a TLS version and exchange keys. The connection is now encrypted.
7. New EHLO: The client sends EHLO again over the secure connection, then logs in and sends the email.

Which port should you use?

Use port 587 for StartTLS. It’s the standard port for email submission, and most providers require StartTLS on it. Ports 25 and 2525 also support StartTLS, but many ISPs and cloud providers block port 25 for outgoing mail.

Port 465 doesn’t use StartTLS. It uses implicit TLS, so the connection is encrypted from the start. For a deeper comparison, read SMTP port 587 vs. 465.

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:

• Opportunistic TLS: The sending server uses TLS if the receiving server supports it and falls back to plain text if it doesn’t. Mail always gets delivered, but some of it may travel unencrypted.
• Enforced TLS: The sending server only delivers over an encrypted connection. If the receiving server doesn’t support TLS, the message isn’t sent. It’s more secure, but some mail may never arrive.

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. TLS secures far more than email. It protects HTTPS websites, API calls, and VoIP signaling, among other traffic.

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.

Why is StartTLS important?

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. 

With StartTLS, the connection between client and server is encrypted, so anyone who intercepts the traffic sees scrambled data.

Keep in mind that StartTLS encrypts each hop: from your app to your email provider, and from your provider to the recipient’s server. It isn’t end-to-end encryption, so the mail servers along the way can still read the message.

Drawbacks

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.

How do I test StartTLS?

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.

Troubleshooting common StartTLS errors

"StartTLS is required to send mail" errors are annoying, but it’s usually pretty easy to fix them (at least when you know what’s going wrong):

• Error: "Must issue a STARTTLS command first": Your email client is trying to authenticate before establishing encryption. Solution: Enable StartTLS in your email client settings and double-check you're using the correct port (usually 587).

• Error: "STARTTLS is required": The mail server mandates encryption, but your client isn't requesting it. Solution: Check that StartTLS is enabled in your SMTP configuration, not just SSL/TLS.

• Connection timeout or refused: Your ISP might be blocking the SMTP port you're using. Solution: Try alternative ports—587, 2525, or 465. If port 25 isn't working, this is likely the culprit.

• Certificate verification failed: The server's TLS certificate can't be verified. Solution: Check your date/time settings first (seriously), then verify the server hostname matches your SMTP settings exactly.

• Negotiation failed errors: Your client and server can't agree on a TLS version. Solution: Update your email client or check if the server supports your client's TLS version. Older clients might only support deprecated TLS versions.

Quick diagnostic steps:

1. Test your StartTLS connection manually using telnet (see our testing section above)

2. Verify your SMTP server address and port combination

3. Check if your firewall or antivirus is interfering with SMTP connections

4. Confirm your email provider actually supports StartTLS on the port you're using

If you’re still stuck, the issue is usually in the configuration details. Double-check your authentication method, port number, and guarantee StartTLS is explicitly enabled, not just "SSL/TLS."

How does Twilio SendGrid use StartTLS?

Twilio SendGrid supports TLS v1.2 and higher. Unencrypted and TLS connections are accepted on ports 25, 587, and 2525. Or, you can connect with implicit TLS on port 465.

By default, Twilio SendGrid uses opportunistic TLS and delivers at the highest encryption level the recipient server accepts. You can also turn on Enforced TLS. With Enforced TLS on, if the recipient server doesn’t support TLS, we drop the message and send a block event instead of delivering it unencrypted.

You would mainly interact with StartTLS when initiating the SMTP request to Twilio SendGrid, asking to send mail. Otherwise, Twilio SendGrid handles the matching of the TLS certificates, the rest of the encryption process, and any issues that may come up along the way.

For more information on Twilio SendGrid and SMTP, head over to our docs article, How to Send an SMTP Email. And when you're ready to start sending emails, sign up for a free Twilio SendGrid account and get started. 

Frequently asked questions

What port does StartTLS use?

StartTLS typically uses port 587, which is the standard for email submission with encryption. Ports 25 and 2525 also support StartTLS, but port 587 is recommended for client applications. Port 465 uses implicit TLS instead of StartTLS.

Is StartTLS secure?

StartTLS provides strong security when properly configured, but it's not foolproof. It's vulnerable to man-in-the-middle attacks during the initial unencrypted handshake. For maximum security, use StartTLS with certificate verification enabled.

How do I enable StartTLS?

Enable StartTLS in your email client's SMTP settings. Look for options like "Use STARTTLS," "Explicit TLS," or "TLS/StartTLS." Avoid "SSL" or "Implicit TLS" options, which use different encryption methods.

What's the difference between StartTLS and SSL?

StartTLS upgrades an existing connection to encrypted, while SSL creates an encrypted connection from the start. StartTLS is more flexible because it allows the same port to handle both encrypted and unencrypted connections.

Why am I getting "StartTLS is required" errors?

This error means the mail server requires encryption, but your email client isn't requesting it. Check that StartTLS is enabled in your SMTP configuration and you're using the correct port (usually 587).

Can I use StartTLS with any email provider?

Most modern email providers support StartTLS, but older or less secure providers might not. Test your connection first, and consider switching providers if StartTLS isn't supported.

Which is better, SSL/TLS or StartTLS?

Both are secure when configured correctly. RFC 8314 recommends implicit TLS on port 465 for email submission, but port 587 with StartTLS is more widely used. Go with what your provider recommends and require encryption either way.