Early last year, we implemented opportunistic encryption of incoming emails. We’ve now done the same thing for outgoing emails. This means that for email sent via FastMail (either the web interface or SMTP), if the receiving server advertises STARTTLS support in response to an EHLO command, we will try and negotiate a secure connection and send the email over a secure connection. However if the negotiation fails for any reason, we’ll fallback to a standard connection.
Some extra notes on this:
- This doesn’t change what happens when sending via SMTP from your email client/software (eg. Outlook, Apple Mail, Thunderbird, etc) to the FastMail servers. Whether that connection is encrypted is controlled by your email client/software and what you configured when you set it up
- We can’t force a remote server to use encryption, it’s only if the remote server advertises support for encryption that we try and setup a secure channel
- This is not full end-to-end encryption of the email. The email is only encrypted during transit from our server to the other server, once it’s at their side, it’s stored in whatever form the other side stores emails. For full end-to-end encryption, you need something like PGP
- The only way to tell if an email has gone over an encrypted connection or not is to look at the headers of the email on the received side. In other words, as a sender, it’s unfortunately not easy to tell, only the receiver can easily tell
Since this feature is only enabled if the other side advertises support for it, it shouldn’t affect sending to servers that don’t support STARTTLS, and thus shouldn’t affect the deliverability of email in any way.