STARTTLS vs SSL vs TLS: Email Encryption Differences

STARTTLS, TLS, and SSL often appear together in an email settings screen, usually beside a port number and a checkbox with suspiciously little explanation. The names overlap, but they are not interchangeable.

The short version is:

• TLS is the modern encryption protocol.
• SSL is an obsolete protocol family and a lingering label for TLS in some interfaces.
• STARTTLS is a command that upgrades an already-open SMTP connection to TLS.
• Implicit TLS starts the TLS handshake as soon as the connection opens.

For most application email, use the exact combination documented by your provider: commonly STARTTLS on port 587 or implicit TLS on port 465. Require certificate verification, then send a real message and confirm that it arrives. A happy handshake is useful, but your customer is waiting for the password reset, not admiring the cipher suite.

If you want a shorter operational introduction, read What is SSL for email?. This guide goes deeper into the SMTP conversation and the checks that distinguish a secure connection from a merely optimistic configuration.

STARTTLS vs TLS vs SSL at a glance

Term	What it means	Where you will see it
TLS	The current protocol that encrypts a network connection	SMTP, IMAP, POP, HTTPS, and provider APIs
SSL	The retired predecessor to TLS; often an imprecise UI label for implicit TLS	Older settings screens and support articles
STARTTLS	An SMTP, IMAP, or POP command that switches an existing clear connection to TLS	SMTP submission on 587, IMAP on 143, and POP on 110
Implicit TLS	TLS begins before any application-protocol commands are exchanged	SMTP submission on 465, IMAP on 993, and POP on 995

Two separate questions matter:

1. How does TLS begin? It begins immediately with implicit TLS, or after a STARTTLS command.
2. Is TLS required? A client may require the upgrade and stop on failure, or it may be allowed to continue without encryption under a relay policy.

That distinction prevents a common mistake. STARTTLS does not mean "optional," and implicit TLS does not mean "more forced." Correctly implemented STARTTLS on port 587 and implicit TLS on port 465 have no significant security difference when both sides require a successful TLS negotiation before message submission. RFC 8314 says clients and servers should support both during the transition toward implicit TLS.

What happens during a STARTTLS connection

STARTTLS begins as ordinary SMTP and changes gear before credentials or message content are sent. A typical submission conversation looks like this:

TCP connection to smtp.example.com:587
S: 220 smtp.example.com ESMTP ready
C: EHLO app.example.com
S: 250-STARTTLS
C: STARTTLS
S: 220 Ready to start TLS
TLS handshake and certificate validation
C: EHLO app.example.com
S: 250-AUTH PLAIN LOGIN
C: AUTH ...

The second EHLO is not a decorative encore. RFC 3207 requires the client and server to discard knowledge learned before the TLS handshake. The server may advertise a different capability list after encryption, including authentication methods that were deliberately hidden on the clear connection.

A safe submission client should:

1. connect to the documented STARTTLS port;
2. send EHLO and confirm that the server advertises STARTTLS;
3. send STARTTLS and wait for the 220 response;
4. perform the TLS handshake and validate the certificate chain and hostname;
5. send EHLO again over the encrypted connection;
6. authenticate only after TLS succeeds; and
7. stop rather than sending credentials or message content in clear text when TLS is required.

Most maintained SMTP libraries perform these details for you. The important configuration boundary is whether your code requires the upgrade and certificate validation. A setting named secure, ssl, tls, or starttls can mean different things in different libraries, so follow that library's current documentation rather than guessing from the property name.

What happens with implicit TLS

Implicit TLS reverses the opening order. The client connects to port 465, performs the TLS handshake immediately, validates the server, and only then starts the SMTP conversation:

TCP connection to smtp.example.com:465
TLS handshake and certificate validation
S: 220 smtp.example.com ESMTP ready
C: EHLO app.example.com
S: 250-AUTH PLAIN LOGIN
C: AUTH ...

There is no STARTTLS command because there is no clear SMTP phase to upgrade. If a client sends EHLO before starting TLS on an implicit-TLS port, the connection will fail. Likewise, a client that tries an immediate TLS handshake on a STARTTLS port is speaking at the wrong moment.

This is why changing only the port can break a working setup. The connection mode and port must agree.

Which SMTP port should you use?

Job	Typical port	TLS mode	Practical default
Application or mail-client submission	587	STARTTLS	Require the upgrade before authentication
Application or mail-client submission	465	Implicit TLS	Use when the provider documents implicit TLS
Server-to-server SMTP relay	25	STARTTLS when available or required by policy	Do not treat this as an application submission port
Provider-specific alternative submission	2525	Provider-defined	Match the provider's exact TLS instructions

For a web application, start with the provider's documented submission endpoint. Port 587 with required STARTTLS remains widely deployed. Port 465 is the registered implicit-TLS submission service and is a good choice when the provider supports it. Port 2525 is a convention rather than a universal standard; providers sometimes offer it when another port is blocked.

Port 25 has a different job. Mail transfer agents use it to relay mail between domains. That relay environment often uses opportunistic STARTTLS so delivery can continue to older destinations, although MTA-STS, DANE, or explicit policy can require authenticated TLS for particular routes. Application credentials generally belong on a submission service, not an open port-25 connection.

For a dedicated port decision guide, see Which SMTP port should I use?.

Does "SSL" still mean SSL?

Usually not. SSL 2.0 and SSL 3.0 are obsolete, as are TLS 1.0 and TLS 1.1. Modern email software should negotiate TLS 1.2 or TLS 1.3; RFC 8996 prohibits TLS 1.0 and TLS 1.1 and moves current deployments to a minimum of TLS 1.2. Use TLS 1.3 when both sides support it.

An interface that offers an "SSL" checkbox may really mean "start TLS immediately." Confirm three details before trusting it:

• the documented port;
• whether TLS starts immediately or after STARTTLS; and
• whether certificate and hostname verification are enabled.

Do not enable old SSL protocol versions to satisfy an old label. If a legacy server cannot negotiate an approved TLS version, update or replace that endpoint rather than weakening every client that talks to it.

Certificate verification is part of the connection

Encryption without identity verification can protect a conversation with the wrong server. The client must validate that:

• the certificate chains to a trusted authority;
• the certificate is currently valid;
• the hostname in the certificate matches the server name the client intended to reach; and
• a verification failure stops the connection when TLS is required.

Use the provider's SMTP hostname for both the connection and hostname check. A load balancer IP address may accept a TCP connection while failing certificate-name validation, and disabling that validation turns a useful alarm into a quiet vulnerability.

Also remember the hop boundary. SMTP TLS protects one network connection at a time. A message may cross several relays, each with its own TLS decision, before it reaches the recipient's mailbox. Transport TLS does not by itself provide end-to-end message encryption like S/MIME or OpenPGP.

Test STARTTLS safely with OpenSSL

OpenSSL can show whether the endpoint negotiates TLS and presents a certificate for the expected hostname. Use a placeholder server first, then substitute the exact hostname and port from your provider:

openssl s_client \
  -connect smtp.example.com:587 \
  -starttls smtp \
  -servername smtp.example.com \
  -verify_hostname smtp.example.com \
  -verify_return_error \
  -crlf \
  -brief

For implicit TLS on port 465, omit -starttls smtp:

openssl s_client \
  -connect smtp.example.com:465 \
  -servername smtp.example.com \
  -verify_hostname smtp.example.com \
  -verify_return_error \
  -crlf \
  -brief

The OpenSSL s_client documentation calls out an easy-to-miss behavior: the diagnostic client normally continues after certificate verification errors so it can display them. -verify_return_error makes a verification error abort the handshake, which is much closer to the failure behavior a production client should use.

Read the result as evidence, not confetti. Look for:

• Protocol version: TLSv1.2 or TLSv1.3;
• a real cipher suite rather than NONE;
• a peer certificate for the SMTP hostname; and
• successful certificate verification.

If the output says no peer certificate is available or the cipher is NONE, a TLS session was not negotiated. Verification: OK beside Cipher is (NONE) is not proof of a successful secure SMTP connection; inspect the earlier errors and the exit status instead.

These commands intentionally omit usernames and passwords. Use them to inspect transport behavior, not to paste production secrets into a shell history or support transcript.

Why STARTTLS failures happen

Symptom	Likely boundary	What to check
Server does not advertise STARTTLS	Wrong port, wrong endpoint, or server policy	Confirm the submission hostname and port; do not authenticate in clear text
Immediate disconnect on port 465	Client is sending clear SMTP to an implicit-TLS service	Enable implicit TLS before EHLO
TLS error on port 587	Client is attempting implicit TLS on a STARTTLS service	Connect normally, then issue STARTTLS
Hostname mismatch	Connected name differs from certificate identity	Use the provider's documented SMTP hostname and keep verification enabled
Authentication rejected after TLS	Credentials, auth mechanism, or provider policy	Re-run EHLO after TLS and inspect the advertised auth methods
Handshake succeeds but mail never arrives	Routing, sender authentication, content, throttling, or placement	Send to a controlled inbox and inspect the delivered message and events

Avoid the tempting "fix" of disabling certificate checks or allowing clear-text fallback. That only trades a visible setup problem for a quieter security problem.

Submission and relay use STARTTLS differently

Application submission is a known client talking to a known provider. It can require TLS, verify one expected hostname, and stop safely when the secure connection fails.

Internet relay is messier. A sending mail server discovers a recipient domain's mail exchanger and may encounter destinations with different TLS support. Opportunistic STARTTLS improves encryption coverage, but a stripped STARTTLS advertisement or a failed handshake can allow downgrade unless policy says otherwise. MTA-STS or DANE can tell a sender that TLS and an authenticated destination are required; TLS-RPT can report failures in that policy-protected path.

The practical rule is simple: never copy a permissive relay fallback into an application submission client. Your app knows its provider and should fail visibly before exposing credentials or content.

For transport policy, authentication, and relay hardening, continue with the SMTP security guide.

Test the delivered email, not only the socket

A TLS test can prove the connection mode and certificate. It cannot prove that the provider accepted the message, the recipient received it, the HTML rendered, or the login code worked.

Use MailSlurp to test the customer-visible path:

1. Create a fresh inbox in Email Sandbox.
2. Configure the application with the provider's documented STARTTLS or implicit-TLS submission settings.
3. Send the same password reset, OTP, receipt, or campaign template used by the application.
4. Wait for the message through the MailSlurp API rather than using a fixed delay.
5. Assert the recipient, sender, subject, important text, links, codes, and attachments.
6. Inspect the Received headers with the email header analyzer when you need to trace the route.
7. Check the delivered HTML with Free Email Render and use inbox placement testing when spam-folder behavior matters.
8. Complete the link or code flow, then remove the test inbox during cleanup.

That sequence catches the awkward middle ground where TLS is healthy but authentication, routing, content, or the final customer action is not.

A release checklist for secure SMTP

Before shipping a configuration change, confirm:

• the hostname, port, and TLS mode match the provider's documentation;
• STARTTLS is required on an explicit-TLS submission connection;
• implicit TLS begins before SMTP commands on port 465;
• the certificate chain and hostname are verified;
• TLS succeeds before SMTP authentication;
• the client sends EHLO again after STARTTLS;
• no old SSL or TLS version was enabled as a workaround;
• logs expose the connection stage without printing credentials;
• the production-like message arrives in MailSlurp; and
• the delivered code, link, content, and final customer action work.

Common questions

Is STARTTLS the same as TLS?

No. TLS is the encryption protocol. STARTTLS is a command that upgrades an existing SMTP, IMAP, or POP connection so it can use TLS.

Is STARTTLS less secure than implicit TLS?

Not when it is implemented correctly and required before submission. The danger comes from optional downgrade or weak verification, not from the STARTTLS command itself. Implicit TLS does remove the clear protocol phase and is preferred by RFC 8314 for new email submission and access configurations.

Which port uses STARTTLS for SMTP?

Port 587 is the common message-submission port for STARTTLS. Providers may also offer 2525. Use the exact endpoint and mode documented by the provider.

Which port uses implicit TLS for SMTP?

Port 465 is the registered implicit-TLS message-submission service. TLS begins immediately after the TCP connection opens.

Should I use port 25 from my application?

Usually no. Port 25 is primarily for server-to-server relay. Applications normally authenticate to a submission service on 587, 465, or a provider-specific alternative.

Can I trust an OpenSSL Verification: OK line by itself?

No. Confirm that a peer certificate and real cipher were negotiated, use hostname verification and -verify_return_error, read earlier errors, and check the command's exit status.

Does TLS guarantee inbox delivery?

No. TLS protects a transport hop. Authentication, provider acceptance, DNS policy, content, throttling, reputation, and inbox placement still affect delivery. Test the received message and the action it carries.

Final take

Use TLS, not obsolete SSL protocols. Choose STARTTLS or implicit TLS to match the documented submission port, require the secure connection, validate the certificate hostname, and never send credentials before encryption is established.

Then follow the message all the way to a MailSlurp inbox. The best SMTP configuration is not merely the one that shakes hands politely; it is the one that delivers the right email and lets the person waiting for it finish what they came to do.