SMTP TLS Checker Help & Support

This checks that the server is listening to SMTP, advertises "STARTTLS" as a feature, and that LuxSci can negotiate a successful TLS connection using some protocol version and cipher. This checks for bare minimum SMTP TLS functionality.

TLS Certificates are issued for a specific domain or domains. The report lists the primary domain (Common Name) listed in the certificate presented by this server. Note that some certificates can have multiple domain names within them -- the report will not display all certificate names, just the primary one (though we support all of them in the next step, "Certificate Verifiable."

In order to properly authenticate a TLS-secured connection, one must have (a) a TLS certificate that is signed by a trusted third-party certificate authority (CA), (b) that has not expired, and (c) whose listed domain name(s) match the name of the name of the MX record to which your are connecting.

This "verifiable" check look as all three of these criteria.

Unfortunately, most email sending servers do not validate TLS certificates. They do not check if the domains names match, if they are expired, or even if they are trusted. This is because many email servers have issues with their certificates. They often present ones with mismatching names and ones that are "self signed." This is not great. It means that SMTP TLS provides good protection against passive eavesdropping but not against active main-in-the-middle attacks. There is progress towards "fixing" this issue -- see "SMTP MTA STS," below.

Everyone should working on improve their certificates over time so that eventually SMTP TLS communications can be authenticated as well and commonly as HTTPS communications.

SSL protocol version 3 is extremely weak in terms of security. It has been abandoned for years by the internet community and best practices are that it should never be enabled on any SSL/TLS-supporting server. See also: SSL vs. TLS: what's the difference?

If this check finds SSL v3 enabled, it should be disabled ASAP.

This check lets you know if TLS v1.0 is supported by the server. For general compatibility with email on the internet at large, TLS 1.0 is OK to be used, even according to the very latest NIST 800-52r2 recommendations.

For closed government systems and situations where you know that everyone sending email to you must support TLS v1.2, it is required and/or preferable to disable TLS 1.0 support.

Note that the PCI/DSS requirements that TLS v1.0 not be used do not apply to your inbound email servers, as long as these are independent of the servers involved in credit card processing and/or storage.

This check lets you know if TLS v1.2 is supported by the server. Every server supporting SMTP TLS should support TLS v1.2.

There is extremely wide support across the internet for strong ciphers. If your server still uses "Export," "Low," or "Medium" strength ciphers or ciphers using outdated algorithms like RC2, RC4, and MD4, the server really needs to be updated ASAP. There is generally no reason that such ciphers should still be in use anywhere and they seriously decrease the security of those systems.

Additionally, ciphers using 3DES should be removed from servers as they are known to be vulnerable. There were included in the NIST 800-52r1 recommendations, but have been removed from the 800-52r2 recommendations.

Ideally, all DES ciphers and all ciphers not in the NIST 800-52r1 and 800-52r2 lists should be removed from the server. Or at least, remove all "weak" ciphers.

Having weak ciphers available is especially poor if there is an active man-in-the-middle. If there is only passive eavesdropping, then the client and server will generally pick one of the best available ciphers and not one of the available weak ones. If there is an active man-in-the-middle, all bets are off anyway unless the sender is doing certificate validation or supporting SMTP MTA STS. Weak ciphers should be removed; however, having weak ciphers does not significantly detract from your "Score" currently.

In 2014, NIST produced Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations. This contains the official recommendations for what TLS ciphers to use for "good security."

Having good ciphers allows the communications to be more secure against passive eavesdroppers. Using ciphers from the NIST list makes it more likely that they are generally used and are well vetted.

The "revision 2" if this specification is still a "Draft." It is a best practice to support some or all of the ciphers in the 800-52r1 specification. For more on this, see What level or TLS is required for compliance?

NIST produced version 2 of Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations. This contains updated official recommendations for what TLS ciphers to use for "good security" and improves on "version 1".

Having good ciphers allows the communications to be even more secure against passive eavesdroppers. Using ciphers from the NIST list makes it more likely that they are generally used and are well vetted.

The "revision 2" if this specification is still a "Draft;" however, its recommended list of ciphers is better than that in "version 1." It is a best practice to support the ciphers in 800-52r2 that are not in the 800-42r1 recommendations. For more on this, see What level or TLS is required for compliance?

SMTP MTA Strict Transport Security is a method where you can publish (via DNS and a secure web site) which MX records support TLS for email delivery. Armed with this information, a sender can know that the MX record (a) supports TLS 1.2+, (b) the MX records TLS certificate will validate properly, and (c) TLS should be used on all connections. This goes a long way to prevent active man-in-the-middle attacks and protocol downgrade attacks.

While this specification is still in draft, it is already being adopted by the big players. It is recommended that you setup SMTP MTA STS for your critical email domains.