Some eight years ago, I made a logic error. Last month, I discovered it, proceeded to slap my forehead, and fixed it. We prepared new releases containing the fix, and began the process of notifying our users.

I now, therefore, have rough statistics about the prevalence and availability of TLS/SSL when sending email. Our notifications went to tens of thousands of unique addresses, with the following rough results. Percentages are based on the number of unique addresses in each category, so large email services (Google, Outlook, Yahoo) are represented according to their size. However, the results are filtered through the self-selected lens that is our users:


16% NoTls The SMTP server did not offer STARTTLS (large majority), or TLS handshake failed due to protocol error (small fraction; errors encountered were SEC_E_INVALID_TOKEN and SEC_E_ILLEGAL_MESSAGE).
20% Tls_NoHostAuth The SMTP server offered TLS, but could not be authenticated. By far the most common reason was SEC_E_WRONG_PRINCIPAL, followed by SEC_E_UNTRUSTED_ROOT. A ten times less common reason was SEC_E_CERT_EXPIRED. A rare reason was TRUST_E_CERT_SIGNATURE.
50% Tls_AnyServer The SMTP server was authenticated as the intended MX DNS name, but the MX name itself is not part of the recipient's email domain. Security of the connection hinges on how much you trust DNS MX lookup results, which are completely unauthenticated. Most large email services (e.g. Google, Outlook, Yahoo) are in this category, but many results could be bumped into Tls_DomainMatch by applying common knowledge. For example, one could trust *.google.com servers as being representative of @gmail.com addresses, but this requires having that knowledge.
14% Tls_DomainMatch The SMTP server was authenticated as the intended MX DNS name, and the MX name itself is a subdomain of (or equals the domain of) the target email address. This provides stronger assurance that the destination SMTP server is representative of the recipient domain.

To the extent that our user base is representative (or isn't), a large majority of recipients (84%) can receive email via SMTP using opportunistic encryption, which may protect against passive eavesdropping; but only a minority (14%) employ setups resistant to man-in-the-middle attack without the benefit of additional, external knowledge.

After you have exchanged email with a particular recipient, you can add their mail exchanger to a list of known mail servers for that recipient, and trust that host more highly in future deliveries. Assuming this strategy, up to two thirds of recipients (categories Tls_AnyServer + Tls_DomainMatch) could be considered resistant to a non-pervasive man-in-the-middle attack, as long as change of destination mail server identity triggers some kind of audit or warning.