With the number of acronyms surrounding email encryption, it’s not hard to get lost. Hardly any email is sent without SSL or TLS. STARTTLS is often associated with them and STLS appears every now and then. How about ECC and RSA? We’ll leave them for next time. Join us this time as we discuss the role of SSL/TLS and STARTTLS in email encryption.
SSL and TLS – what are they all about?
As you can read in our article on SMTP security, this protocol is not secured by default. As such, it’s quite easy for the internet villains to intercept emails and make use of confidential information. Luckily, there are encryption methods in place that make their lives a bit more difficult.
SSL (Secure Socket Layer) and its successor TLS (Transport Layer Security) are two cryptographic protocols used in email transmission. Both rely on a set of private and public keys to turn messages into useless strings of characters. If, at any stage, such an email is intercepted, it won’t be of any use to whoever compromised your security.
SSL was originally developed by Netscape in 1995 and was quickly implemented in the popular email clients at the time (their own client included). Four years later, a new standard – TLS – was introduced, offering a more reliable security profile.
SSL has since been deprecated, but it is still widely used along with its younger sibling. As a matter of fact, both names are used interchangeably and you can often find a reference to SSL when TLS is being referred to. The term ‘SSL/TLS’ is also commonly used.
What’s the role of STARTTLS?
STARTTLS is not a protocol but an email protocol command. It’s used to tell an email server that an email client (such as Gmail, Outlook, etc.) wants to upgrade an existing insecure connection to an encrypted one using SSL or TLS.
However, if a server doesn’t support encryption or is malicious, running this command can result in clients establishing an insecure connection, opening the door for the silent transmission of unencrypted, potentially sensitive personal data.
STARTTLS, except for SMTP, is also used with IMAP protocol, traditionally used for retrieving emails from an email server. POP3, another protocol for receiving emails, uses a similar command called STLS.
Note: As STARTTLS doesn’t guarantee a secure connection, users should be discouraged from using it or use other measures in conjunction with STARTTLS, such as using strong authentication methods, encrypting the email content with end-to-end encryption (e.g., using PGP or S/MIME), and verifying the digital signatures of email messages.
How do TLS/SSL and STARTTLS work?
To understand the role of encryption in email transmissions, we need to briefly explain what the ‘handshake’ is about. In the same way that humans in many cultures tend to shake each other’s hands at the start of a conversation, email clients and servers also follow a similar ritual.
When an email is sent, a client reaches out to a server to verify its reliability. It shares which SSL/TLS versions it’s compatible with and also the encryption method one can expect from it. The server responds with its digital certificate to confirm its identity. When it checks out, the two sides generate and exchange a unique key that will now be used to decrypt messages.
For a ‘handshake’ to happen, a connection needs to first be established between a client and a server. By default, an SMTP connection is not secured and, as such, vulnerable to attacks. That’s why both sides will try to establish a secure connection. There are two approaches:
- with Opportunistic SSL/TLS (aka Explicit SSL/TLS), a client will run a STARTTLS command to upgrade a connection to an encrypted one. If a server is compatible and no errors occur, the secured TLS or SSL connection will be established. If anything fails in the process, a plain-text transmission will be established.
- with Forced SSL/TLS (aka Implicit SSL/TLS), a client will try to establish a secure connection without asking a server about its compatibility. If it succeeds, a secure connection will be set up and a handshake will follow. If a server is not compatible or a connection times out, a transmission will be abandoned.
Both are in common use these days and use dedicated ports for these transmissions.
Which ports are used for Implicit and Explicit SSL/TLS?
For many years, port 25 was used by default for both submitting emails to MTAs (email servers) and relaying them between MTAs. Over time, this led to an enormous amount of spam being sent through this port (and it still is).
New ports have been announced since and 25 was limited mainly to SMTP Relay purposes. Port 587 emerged as the most popular option for SMTP submission.
Although this port doesn’t require STARTTLS to be used, the platforms utilizing it mostly do. On top of that, they also require a username and password for authentication, making it even harder to spoof the real accounts. If you want to use an Explicit SSL/TLS, port 587 should be your choice. As an alternative, port 2525 is also commonly used.
For a brief period of time, port 465 was the recommended port for email submission. This decision was quickly revoked, in favor of port 587, but many clients and servers had already implemented it. As such, it has become a common alternative to 587 for those willing to use Implicit SSL/TLS (forcing an encrypted connection rather than trying to upgrade it with STARTTLS).
These days, many email clients, Gmail and Yahoo! included, use both port 465 (for Implicit SSL/TLS) and 587 (for Explicit SSL/TLS), while others limit themselves only to 587.
Things are set to change, as further attempts are made to enforce the use of TLS in both clients and servers. In 2018, the Internet Engineering Task Force (IETF) recommended that using Implicit TLS via port 465 is the way to go. Time will tell whether STARTTLS will become redundant one day or if both approaches will be used hand in hand for years to come.
IMAP and POP (mainly POP3) also use different ports for Implicit and Explicit SSL/TLS. IMAP retrieves emails via port 143 when STARTTLS is in place and via port 993 when using Implicit SSL/TLS. POP uses ports 110 and 995, respectively.
At Mailtrap, with our end-to-end email sending solution Email API, we support ports 587, 2525, and 25. But, as it’s the standard secure SMTP port, we advise users to go with 587.
With our email testing solution, Email Sandbox, we also support ports 587, 2525, and 25, along with port 465. And if you are using the POP3 protocol, you can pick between ports 1100 and 9950.
Now, you might be wondering, “why offer such a wide selection of ports?”. Well, we know that different devs/QAs using our solutions have different needs and thus might not all rely on the same port and/or protocol, even if it’s the most secure and recommended.
For example, one SMTP port might be blocked by an ISP, a firewall, or something else, resulting in the user not being able to connect to the Mailtrap SMTP server. In situations like these, which users of shared hosting often find themselves in, switching to a different port might be the solution to the issue.
You can read more about SMTP ports in our other article.
SSL/TLS version history
As we mentioned before, SSL has been deprecated for a few years already and TLS is considered to be the most reliable development in email encryption. Despite that, some platforms still use SSL, despite its vulnerabilities.
As you should know by now, SSL and TLS are used interchangeably. As such, it’s not uncommon to see a client or a server offering the latest SSL encryption to its users. But there’s no need to despair. It’s probably TLS that powers their transmissions. Quick research won’t hurt though.
Here’s a summary of all the SSL/TLS versions published to date:
| Protocol | Year published | Current status |
| SSL 1.0 | Never published | Never published |
| SSL 2.0 | 1995 | Deprecated since 2011 |
| SSL 3.0 | 1996 | Deprecated since 2015 |
| TLS 1.0 | 1999 | To be deprecated in 2020 |
| TLS 1.1 | 2006 | To be deprecated in 2020 |
| TLS 1.2 | 2008 | Actively supported |
| TLS 1.3 | 2018 | Actively supported |
SSL 1.0 was never published as serious security flaws were discovered before it was even announced. As a result, SSL 2.0 was the first protocol that was widely available.
With the release of TLS 1.3 in 2018, the first two versions of TLS are due to be deprecated. If you’re about to choose a provider and are comparing different offers, make sure yours runs on TLS 1.2 or newer.
Wrapping up
Be aware that, even with ancient technology as SMTP, things can change pretty quickly. A new version of TLS or even a completely different protocol may be introduced. Some ports could become redundant while others will rise to fame. When that happens, we’ll be sure to update the article, but try to always be on the lookout for the latest news and trends in the industry.
As a start, make sure to check out our YouTube channel and the video on the dangers of using AI in email security:
