Is STARTTLS insecure?

Not if the client refuses to continue without it and checks the server's certificate. The risk is clients that fall back to plain text when the STARTTLS offer is missing. Implicit TLS avoids that risk entirely.

What should I pick if my provider lists both?

Choose implicit TLS: port 993 for IMAP and port 465 for SMTP. If your provider only lists 587 for sending, use 587 with STARTTLS.

Learn

SSL/TLS vs STARTTLS: email ports 993, 465 and 587

The two ways mail apps encrypt their connection, and which port number goes with which.

Two ways to encrypt the same connection

Mail apps encrypt the connection to your provider with TLS (Transport Layer Security). There are two ways to start it, and mail settings usually label them SSL/TLS and STARTTLS.

With implicit TLS (often labeled SSL/TLS), the connection is encrypted from the first byte. The client connects to a dedicated port and starts a TLS handshake right away, before any email commands are exchanged.

With STARTTLS, the client connects to the normal port in plain text, the server says it supports encryption, the client sends the STARTTLS command, and only then does the TLS handshake happen. After that, the rest of the session is encrypted.

Which port goes with which

Each protocol has a port for each method. When a mail app asks for a port and a security type, these are the pairs that belong together:

Protocol           Implicit TLS     STARTTLS (or plain)
IMAP (reading)     993              143
POP3 (reading)     995              110
SMTP (sending)     465              587
SMTP (server to server)  n/a        25

Why implicit TLS is now preferred

RFC 8314, published in 2018, recommends implicit TLS for mail apps connecting to their provider, for reading and sending alike. The reason is that STARTTLS has a weak moment. The first part of the conversation is unencrypted, so an attacker on the network can strip the server's offer of STARTTLS. A client that does not insist on encryption may then carry on in plain text, password included. Researchers have also found many bugs in how servers and clients handle the switch.

A client that requires STARTTLS and refuses to continue without it is safe from stripping. The trouble is that you often cannot tell from the settings screen whether it does. Implicit TLS removes the question.

Port 465 has an odd history. It was assigned for SMTP over SSL in the 1990s, then withdrawn, while many providers kept using it anyway. RFC 8314 made it official again for sending mail with implicit TLS.

Why it still says SSL

SSL is the old name for the protocol that became TLS. Every version of SSL is now broken and deprecated (SSL 3.0 was formally retired by RFC 7568 in 2015). When a mail app offers SSL, it almost always means implicit TLS, using TLS 1.2 or 1.3 under the hood.

Port 25 is different. It carries mail between servers, where encryption is opportunistic: servers use STARTTLS when both sides offer it. Domains that want to require it can publish MTA-STS (RFC 8461) or use DANE (RFC 7672).

Questions

Is STARTTLS insecure?: Not if the client refuses to continue without it and checks the server's certificate. The risk is clients that fall back to plain text when the STARTTLS offer is missing. Implicit TLS avoids that risk entirely.
What should I pick if my provider lists both?: Choose implicit TLS: port 993 for IMAP and port 465 for SMTP. If your provider only lists 587 for sending, use 587 with STARTTLS.

In Bloop.email

Bloop.email connects from your Mac directly to your provider's IMAP and SMTP servers, so the encrypted connection runs between your Mac and the provider with no Bloop server in the middle.

See the features