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