MailSlurp logo

blog

STARTTLS vs SSL vs TLS: Email Encryption Differences

Understand STARTTLS vs TLS vs SSL, SMTP SSL/TLS port choices, email certificates, and how to test secure email delivery with MailSlurp.

If your application sends email, you need to know whether the connection uses STARTTLS, implicit TLS, or an older SSL label in your provider settings.

These terms affect SMTP ports, provider setup, deliverability checks, and whether password resets, login codes, receipts, and campaign messages travel over an encrypted connection.

If you want the plain-language operational version first, use What is SSL for email?.

Quick answer: STARTTLS vs SSL vs TLS

TLS is the modern encryption protocol used to secure email connections. SSL is the older name people still use casually, but legacy SSL protocol versions should not be used. STARTTLS is the SMTP command that upgrades an existing plain connection into an encrypted TLS connection when the server supports it.

For most SMTP submission:

  • port 587 commonly uses STARTTLS, also called explicit TLS
  • port 465 commonly uses implicit TLS
  • port 25 is mainly used for server-to-server SMTP relay

In product terms: choose the right SMTP SSL/TLS port, send a real test email, then confirm the message arrives in the inbox with the expected headers and timing. MailSlurp helps with the send-and-receive side of that check.

STARTTLS, TLS, and SSL compared

Term What it means today Common email use
TLS The modern encryption protocol for secure network connections Secures SMTP, IMAP, POP, HTTPS, and provider APIs
SSL Older protocol name still used in settings screens Often means TLS in modern provider UI, but legacy SSL versions should be disabled
STARTTLS Command that upgrades a plain SMTP, IMAP, or POP connection to TLS Common on SMTP port 587, IMAP port 143, and POP port 110
Implicit TLS TLS starts immediately when the connection opens Common on SMTP port 465, IMAP port 993, and POP port 995

The safest way to debug provider setup is to use the exact port and mode your app uses, then verify the final email outcome in a controlled inbox.

What are SSL and TLS, Exactly?

Two cryptographic protocol families appear in email settings: SSL (Secure Socket Layer) and TLS (Transport Layer Security), which replaced it. Modern email systems should use TLS to encrypt the connection between clients, relays, and mail servers.

When Netscape introduced SSL in 1995, it was quickly incorporated into all of the popular email clients at the time, including their own. A new standard with a more reliable security profile was introduced four years later, and it is the TLS.

The word SSL is still widely used in product interfaces, documentation, and support conversations. In modern email systems, those labels usually refer to TLS under the hood.

Here is a list of all SSL/TLS versions that have been released so far:

Protocol Year Published Present Status
SSL 1.0 NEVER PUBLISHED NEVER PUBLISHED
SSL 2.0 1995 Deprecated
SSL 3.0 1996 Deprecated
TLS 1.0 1999 Deprecated
TLS 1.1 2006 Deprecated
TLS 1.2 2008 Supported
TLS 1.3 2018 Supported

What function does STARTTLS serve?

STARTTLS is an email protocol command. It informs an email server that a client wants to switch from an existing insecure connection to a secure one using SSL or TLS. Typical clients include Gmail, Outlook, and others.

For SMTP submission, STARTTLS usually appears after the client connects, says EHLO, sees STARTTLS advertised by the server, and then upgrades the connection before authentication and message transfer.

STARTTLS is not a separate encryption protocol. It is the upgrade step that lets SMTP use TLS.

How do TLS/SSL and STARTTLS Work?

TLS encrypts the connection and lets the client validate the server certificate. STARTTLS is one way to begin with a plain connection and upgrade it to TLS before authentication and message transfer. There are two common techniques:

i. Using Opportunistic SSL/TLS (aka Explicit SSL/TLS)

Here, a client upgrades the connection by sending the STARTTLS command. If the server advertises STARTTLS and the handshake succeeds, the client continues over TLS. For application email, configure the client to fail closed rather than silently falling back to plaintext.

ii. Using Forced SSL/TLS (aka Implicit SSL/TLS)

In this case, a client will attempt to create a secure connection without contacting a server to inquire about compatibility. A handshake and a secure connection will be established if it is successful. The transmission will be canceled if the server is unreliable or the connection times out.

What Ports do Explicit and Implicit SSL/TLS Use?

For a long time, port 25 was the standard for sending emails to MTAs (email servers) and relaying them among MTAs. Today, port 25 is mainly used for server-to-server SMTP relay. The most common port for SMTP submission is 587 with STARTTLS.

Use:

  • 587 for SMTP submission with STARTTLS in most application setups
  • 465 when your provider requires implicit TLS
  • 2525 as a common alternative submission port when supported
  • 25 for relay between mail servers, not typical application submission
Protocol/job STARTTLS port Implicit TLS port Notes
SMTP submission 587 465 Most apps should start with 587 and STARTTLS unless the provider documents 465
SMTP relay 25 provider-specific Usually server-to-server mail transfer, often restricted by cloud hosts
IMAP mailbox access 143 993 Use TLS when reading mail through IMAP
POP mailbox access 110 995 Use TLS when reading mail through POP

Additionally, different ports are used for Implicit and Explicit SSL/TLS by IMAP and POP (primarily POP3). IMAP retrieves emails on port 143 when STARTTLS is used and on port 993 when implicit SSL/TLS is used. Specifically, POP uses ports 110 and 995.

If a settings screen asks for an SMTP SSL TLS port, map the label to the behavior:

  • choose 587 when the app can connect first and then run STARTTLS,
  • choose 465 when the provider expects TLS immediately,
  • avoid legacy SSL protocol versions even if the UI still says "SSL",
  • verify the delivered message because a successful TLS connection does not prove the email reached the inbox.

How to check if a Server Supports STARTTLS

To perform a mail ssl test, you can use tools like OpenSSL to check if a server supports STARTTLS. Here is a short example:

# check if server supports start tls
openssl s_client -starttls smtp -crlf -connect mailslurp.mx:2525

You'll see a lot of debugging information in the terminal response and then at the end a message like this:

---
SSL handshake has read 202 bytes and written 347 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
This TLS version forbids renegotiation.
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---

Test STARTTLS and TLS email with MailSlurp

A secure connection check should be paired with a real delivery check. Use this workflow before changing SMTP ports, TLS settings, sender domains, or provider credentials:

  1. Confirm the provider advertises STARTTLS or supports implicit TLS on the selected port.
  2. Validate SMTP connectivity with the SMTP tester.
  3. Send a production-like message through the same SMTP path your app uses.
  4. Receive the message in Email Sandbox or a MailSlurp inbox.
  5. Inspect Received headers with the email header analyzer.
  6. Verify SPF, DKIM, and DMARC posture with DMARC monitoring and deliverability checks.
  7. Add an email integration test so the TLS and delivery path is checked before future releases.

This matters because transport security and user-visible delivery are related but different. A TLS handshake can succeed while authentication, throttling, content, DNS, or relay policy still delays or blocks the message.

Related MailSlurp workflows:

Final take

Use TLS for secure email. Use STARTTLS when your SMTP, IMAP, or POP connection starts plain and upgrades to TLS. Use implicit TLS when the provider requires encryption from the first byte of the connection.

Then test the real result with MailSlurp: the message should connect securely, authenticate successfully, arrive in the expected inbox, and expose headers that help your team debug failures quickly.

FAQ

Is STARTTLS the same as TLS?

No. TLS is the encryption protocol. STARTTLS is the command that upgrades an existing SMTP connection so it can use TLS.

What is the SMTP SSL TLS port?

For most application SMTP submission, use port 587 with STARTTLS. Use port 465 only when your provider requires implicit TLS. Port 25 is mainly for server-to-server relay.

Should I use SSL or TLS for SMTP?

Use TLS. If a UI says SSL, check the actual port and protocol behavior. Modern secure SMTP should use TLS through STARTTLS or implicit TLS.

Which SMTP port should I use for STARTTLS?

Use port 587 for most application SMTP submission with STARTTLS, unless your provider documents a different port.

Is STARTTLS secure enough for email?

STARTTLS is secure when the client requires TLS, validates certificates, and does not silently fall back to plaintext. For critical application email, also verify authentication, headers, deliverability, and inbox receipt.

What is an email SSL certificate?

An email SSL certificate usually means the certificate used during a TLS-secured SMTP, IMAP, or POP connection. Check that the certificate is valid for the server name your app connects to and that the connection uses a modern TLS version.

Next steps for secure SMTP operations

After choosing your STARTTLS and TLS submission model, add operational checks so encryption settings stay reliable: