In Thunderbird (and I assume in many other clients, too) I have the option to choose between "SSL/TLS" and "STARTTLS".

As far as I understand it, "STARTTLS" means in simple words "encrypt if both ends support TLS, otherwise don't encrypt the transfer". And "SSL/TLS" means in simple words "always encrypt or don't connect at all". Is this correct?

Or in other words:

Is STARTTLS less secure than SSL/TLS, because it can fallback to plaintext without notifying me?

8 Answers 8


The answer, based on the STARTTLS RFC for SMTP (RFC 3207) is:

STARTTLS is less secure than TLS.

Instead of doing the talking myself, I will allow the RFC to speak for itself, with the four relevant bits highlighted in BOLD:

A man-in-the-middle attack can be launched by deleting the "250 STARTTLS" response from the server. This would cause the client not to try to start a TLS session. Another man-in-the-middle attack is to allow the server to announce its STARTTLS capability, but to alter the client's request to start TLS and the server's response. In order to defend against such attacks both clients and servers MUST be able to be configured to require successful TLS negotiation of an appropriate cipher suite for selected hosts before messages can be successfully transferred. The additional option of using TLS when possible SHOULD also be provided. An implementation MAY provide the ability to record that TLS was used in communicating with a given peer and generating a warning if it is not used in a later session.

If the TLS negotiation fails or if the client receives a 454 response, the client has to decide what to do next. There are three main choices: go ahead with the rest of the SMTP session, [...]

As you can see, the RFC itself states (not very clearly, but clearly enough) that there is NOTHING requiring clients to establish a secure connection and inform users if a secure connection failed. It explicitly gives clients the option to silently establish plain-text connections.

  • 6
    Your point is certainly valid, but by lack of any RFC or official specification regarding SMTPS (i.e. SMTP + "implicit SSL/TLS" where SSL/TLS is established first), SMTP/SMTPS clients could also decide to fall back to a plain connection if they can't manage to initiate an SSL/TLS connection on port 465. That's still purely an implementation choice.
    – Bruno
    Dec 1, 2014 at 17:13
  • 2
    There are plenty of RFCs for establishing TLS connections. Nowhere in there does "allow plain-text connection" exist as an option for conforming to the RFC (at least that would be news to many people). So SMTPS doesn't require a separate RFC to be more secure than STARTTLS.
    – Greg
    Dec 1, 2014 at 17:20
  • 1
    There are RFCs about TLS (RFC 5246 and predecessors), PKI (RFC 5280), name verification (RFC 6125), but nothing to describe the interaction between SMTP and SSL/TLS in SMTPS officially AFAIK, not in the same way as you get a spec for HTTPS: RFC 2818. One may say "it's obvious, just establish the SSL/TLS connection first", but not everything about it is that obvious (in particular the identity verification aspect, only formalised quite recently in RFC 6125).
    – Bruno
    Dec 1, 2014 at 17:28
  • 2
    There is now RFC 8314, which recommends SSL/TLS by default and resurrects SMTPS - tools.ietf.org/html/rfc8314
    – IBBoard
    Feb 24, 2020 at 21:01
  • 1
    STARTTLS is dead on arrival. Stick with port 465/tcp or submissions service. blog.apnic.net/2021/11/18/… Apr 16, 2022 at 13:19

There is no difference in the security between the two options.

  • SSL/TLS opens an SSL/TLS connection first, then begins the SMTP transaction. This must occur on a port that does not have a non-SSL/TLS SMTP server already running; it is impossible to configure a single port to handle both plain text and encrypted connections due to the nature of the protocols.

  • STARTTLS starts the SMTP transaction and looks for support from the other end for TLS in the response to EHLO. If the client sees STARTTLS in the supported command list, then it sends STARTTLS and begins negotiation for encryption. All this can (and usually does) occur on the standard SMTP port of 25, partly for backwards compatibility, but also to allow for opportunistic encryption between endpoints that both support it but don't necessarily require it.

Generally, SSL/TLS is only used between end-clients and servers. STARTTLS is more commonly used between MTA's to secure inter-server transport.

Given those two implementations, STARTTLS could be construed as insecure if the user or administrator are assuming the connection is encrypted but have not actually configured it to require encryption. However, the encryption used is exactly the same as SSL/TLS and therefore not more or less vulnerable to a Man-in-the-Middle attack beyond this type of configuration error.

  • 4
    If the connection is encrypted, both SSL/TLS and STARTTLS are the same, yes. But that's not what I asked. I meant: If I use STARTTLS, how do I (as a user) know if my connection is really secured? If I try to use SSL/TLS I just can't connect if the server does not support it, but at least nothing is sent as plaintext. But if STARTTLS falls back to plaintext, then my mail gets sent in plaintext without me knowing that it was sent in plaintext (making me think I'm safe when I'm not actually).
    – Foo Bar
    Jul 16, 2013 at 19:55
  • 6
    I don't know why this answer was chosen as correct. It's wrong. As Christopher points out, STARTTLS is less secure than TLS because it gives a false sense of security to clients.
    – Greg
    Nov 14, 2014 at 22:16
  • 5
    @greg there is nothing wrong with the protocol. The flaw is clients that don't follow the rfc and do not warn the user when the connection is not encrypted.
    – longneck
    Nov 14, 2014 at 23:45
  • 1
    @longneck so... maybe this is a semantics thing, but clients can't "not follow" the TLS protocol and have an email go through, period. so that's a meaningful difference.
    – Greg
    Nov 16, 2014 at 1:18
  • 5
    @Bruno "It's only less secure if the client is badly implemented" <= you're just making my point for me. If there is anything the client can do to make the connection insecure while still establishing a functioning connection, then STARTTLS is less secure than explicit TLS (where that is not possible).
    – Greg
    Nov 30, 2014 at 6:43

For email in particular, in January 2018 RFC 8314 was released, which explicitly recommends that "Implicit TLS" be used in preference to the STARTTLS mechanism for IMAP, POP3, and SMTP submissions.

In brief, this memo now recommends that:

  • TLS version 1.2 or greater be used for all traffic between MUAs and Mail Submission Servers, and also between MUAs and Mail Access Servers.
  • MUAs and Mail Service Providers (MSPs) (a) discourage the use of cleartext protocols for mail access and mail submission and (b) deprecate the use of cleartext protocols for these purposes as soon as practicable.
  • Connections to Mail Submission Servers and Mail Access Servers be made using "Implicit TLS" (as defined below), in preference to connecting to the "cleartext" port and negotiating TLS using the STARTTLS command or a similar command.

(emphasis added)


The answer depends to some degree on what you mean by "safe".

First, your summary doesn't quite capture the difference between SSL/TLS and STARTTLS.

  • With SSL/TLS, the client opens a TCP connection to the "SSL port" assigned to the application protocol it wants to use, and starts speaking TLS immediately.
  • With STARTTLS, the client opens a TCP connection to the "cleartext port" associated with the application protocol it wants to use, then asks the server "what protocol extensions do you support?". The server then responds with a list of extensions. If one of those extensions is "STARTTLS", the client can then say "okay, let's use TLS" and the two start speaking TLS.

If the client is configured to require TLS, the two approaches are more-or-less equally safe. But there are some subtleties about how STARTTLS must be used to make it safe, and it's a bit harder for the STARTTLS implementation to get those details right.

On the other hand, if the client is configured to use TLS only when TLS is available, and use cleartext when TLS is not available, what the client might do is first try to connect to the SSL port used by the protocol, and if that fails, then connect to the cleartext port and try to use STARTTLS, and finally fall back to cleartext if TLS isn't available in either case. It's fairly easy for an attacker to cause the SSL port connection to fail (all it takes is some well-timed TCP RST packets or blocking of the SSL port). It's a little bit harder - but only a little bit - for an attacker to defeat the STARTTLS negotiation and cause the traffic to stay in cleartext. And then the attacker not only gets to read your email but also gets to capture your username/password for future use.

So the simple answer is if you're connecting to a server which you already know supports TLS (as should be the case when you're sending or reading email), you should use SSL/TLS. If the connection is being attacked, the connection attempt will fail, but your password and email won't be compromised.

On the other hand, if you're connecting to some service which you don't know whether it supports TLS, STARTTLS may be marginally better.

When STARTTLS was invented, "passive" listening-only attacks were very common, "active" attacks in which the attacker would inject traffic to try to lower security were less common. In the 20 or so years since then, active attacks have become more feasible and more common.

For instance, if you are trying to use a laptop in an airport or some other public place and try to read your mail via the wifi that's provided there, you have no idea what that wifi network is doing with your traffic. It's very common for wifi networks to route certain kinds of traffic to "proxies" that interpose themselves between your client applications and the servers they're trying to talk to. It's trivial for those proxies to disable both STARTTLS and "try one port then another" in an attempt to get your client to fall back to cleartext. Yes, this happens, and it's just one example of how your traffic can be spied on by a network. And such attacks aren't limited to three-letter state-supported agencies, they can be pulled off by a teenager with a $35 computer that is hidden in a public place somewhere.


Yes, you have the basics right. And yes, STARTTLS is definitely less secure. Not only can it failback to plaintext without notification, but because it's subject to man-in-the middle attacks. Since the connection starts out in the clear, a MitM can strip out the STARTTLS command, and prevent the encryption from ever occurring. However, I believe mailservers can specify that transfers only occur after an encrypted tunnel has been setup. So you can work around this.

So why does such a thing even exist? For compatibility reasons. If either side doesn't support encryption, you may still want the connection to complete properly.

  • So, a server capable of STARTTLS will also always be capable of SSL/TLS, right? So it's always better to try SSL/TLS first and see if it works?
    – Foo Bar
    Jul 16, 2013 at 19:36
  • 2
    @FooBar no, one does not imply the other is available. in fact, they could be configured with completely different authentication domains.
    – longneck
    Jul 16, 2013 at 19:41
  • 3
    STARTTLS is not vulnerable to MitM unless you don't validate certificates or use weak ones. The certificate is still presented just the same as always, and the client can require that the TLS upgrade succeeds before continuing. It's worth noting that this is exactly the same situation as SSL/TLS. Jul 16, 2013 at 20:16
  • 2
    Don't know why people are downvoting you, this is the correct answer, STARTTLS is less secure than TLS, and it gives a false sense of security. ISPs can just stip it: arstechnica.com/tech-policy/2014/11/…
    – Greg
    Nov 14, 2014 at 22:17
  • 2
    As far as the protocol itself goes, STARTTLS is less secure than TLS because it explicitly allows plain-text communication without warning the user: serverfault.com/a/648282/207987
    – Greg
    Dec 1, 2014 at 17:09

As of 2021 I would say STARTTLS is less secure then direct TLS. Some security researchers released a paper about this topic here: https://nostarttls.secvuln.info

And there is also an RFC to deprecated STARTTLS for email protocols: https://datatracker.ietf.org/doc/html/rfc8314

Have this from this german article: https://www.golem.de/news/verschluesselung-sicherheitsrisiko-starttls-2108-158714.html


Agree with @Greg. Those attacks are possible. However the MTAs can be configured(depending on the MTA) to use "mandatory TLS", not "opportunistic TLS". What this means is that TLS and only TLS is used(this also includes STARTTLS) for the email transactions. If the remote MTA doesn't support STARTTLS, the email is bounced.


No, it is not less secure, when your application handles it correctly.

There are fourways to handle TLS and many programs allow you to choose:

  • No TLS
  • TLS on dedicated port (only tries TLS)
  • Use TLS if available (Tries starttls, uses an unencrypted connection when it fails)
  • Always use TLS (Uses starttls and fails if it does not work)

The advantage of TLS on a dedicated port is, that you can be sure there is no fallback when you use a program you do not know yet or which does not expose the detail settings for error handling in its first-start wizard.

But in general the security depends on the handling of security errors. A program could decide to switch to the plaintext port when TLS on the TLS-Port fails as well. You need to know what it will do and choose safe settings. And programs should use safe defaults.

Update for 2021:
I've reading more and more people recommending explicit TLS instead of starttls because it is harder to misconfigure it and too many programs may still fall back to not encrypting when starttls fails while there is no such insecure fallback on explicit TLS connections.

While my answer stays valid and choosing starttls yourself when your program supports enforcing it is still safe, you may consider recommending users of your own service to use explicit TLS to avoid people accidentally using vulnerable configurations.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .