How to Tell Who Supports SMTP TLS for Email Transmission
SMTP TLS (Transport Layer Security) is the mechanism by which two email servers, when communicating, can automatically negotiate an encrypted channel between them so that the emails transmitted are secured from eavesdroppers.
It is becoming ever more important to use a company that supports TLS for email transmission as more and more banks, health care, and other organizations who have any kind of security policy are requiring their vendors and clients to use this type of encryption for emailed communications with them. Additionally, if your email provider supports TLS for email transmission, and you are communicating with people whose providers do also, then you can be reasonably sure that all of the email traffic between you and them will be encrypted.
How do you find out if someone to whom you are sending email uses a provider who’s servers support TLS-encrypted communications? We will take you through the whole process step-by-step, but first let us note some 6 important truths about TLS connection encryption.
- The use of TLS encryption is negotiated/determined each and every time two servers connect to each other to transmit your email.
- Just because a server supports TLS today, does not mean that it will tomorrow — server configurations can change and mistakes can be made. There are ways, however, to ensure that an email will never be sent to someone without TLS — see Enforcing Email Security with TLS when Communicating with Banks.
- If your email is passed between more than one server, then the security of each server-to-server connection along the way needs to be negotiated separately.
- Only the recipient’s externally facing email servers can be checked for TLS support. There is no way of checking the back-end servers of a service provider’s email system to make sure TLS is supported all the way to delivery to the recipient’s mailbox.
- Even if the sender’s email servers and the recipient’s email servers are configured to use TLS, both parties still need to configure their email clients to connect securely to their respective servers (for the initial sending of the message, and for the final download and viewing of the message) in order to ensure that the email message is transmitted securely during its entire trek from sender to receiver.
- There is no automated way to see if a specific company’s outbound email will use TLS. You can only check their inbound email TLS support.
First: a Little Bit about DNS: MX Records
To start off, we need to know a little bit about DNS (The Domain Name System). DNS is what tells the world “address information” about your domain name (kind of like a phone book for domain names), from where to find the web server hosting the domain’s associated webpage, to what inbound servers accept email sent to the email addresses of your domain. DNS information is split into many categories, such as “A records”, “CNAME records”, and “MX records”. For the purpose of this article we need only be concerned with the MX records (Mail eXchange records).
A domain’s MX records are a list of all the email servers that can accept inbound email sent to the email addresses of that domain. By querying the DNS MX records for a domain, you can discover what servers handle its inbound email. For instance, if I wanted to know what email servers receive and handle inbound email for “support@luxsci.com” I would perform a DNS query for the MX records of the domain “luxsci.com”.
Once we have determined the names of the inbound email servers associated with the domain of the email address to which you want to send email, you will need to connect to each one of these servers individually and ask them if they support TLS encryption. Mail servers do this by starting an SMTP connection with a server found in the MX records of the recipient’s domain and then issuing a command called “elho”. Once the “elho” command is given to the recipient’s server it will send back the list of the options that it supports. If you see “STARTTLS” in the list of options supported, then the server does support TLS.
Getting a Command Prompt
To query the DNS settings for the MX records of the recipient’s domain you will first need to know how to bring up your “command prompt”. This varies between operating systems:
- For Windows XP, Vista and 7, you will need to click on your start button and go to “All Programs” and then “Accessories” where you will click on “Command Prompt”.
- For Windows 8: Swipe up to show the Apps screen. You can accomplish the same thing with a mouse by clicking on the down arrow icon at the bottom of the screen. Note: Prior to the Windows 8.1 update, the Apps screen can be accessed from the Start screen by swiping up from the bottom of the screen, or right-clicking anywhere, and then choosing All apps. Now that you’re on the Apps screen, swipe or scroll to the right and locate the Windows System section heading. Under Windows System, press or click on Command Prompt.
A new Command Prompt window will open on the Desktop. - For Linux users you should check the documentation for your distribution if you don’t know where your terminal program is located.
- For Mac users, you will want to use the “Terminal” application found under “Application > Utilities”.
The Query
Windows: DNS Query using “nslookup”
If you use Windows then you are going to use the program “nslookup” to query the DNS settings of the domain in question. At the command prompt you will type “nslookup” and hit “Enter” to start the program’s interactive mode. You should now see a “>” as your prompt. At this prompt type “set a=mx“, press “Enter”, then type the domain name you want to query and press “Enter” again. Once you have finished you will need to type “quit” and press “Enter” to exit nslookup. Here is an example with the results:
C:>nslookup
Default Server: UnKnown
Address: 192.168.131.252> set q=mx
> luxsci.com
Server: UnKnown
Address: 192.168.131.252Non-authoritative answer:
luxsci.com MX preference = 10, mail exchanger = luxsci.com.inbound10.mxlogic.net
luxsci.com MX preference = 15, mail exchanger = luxsci.com.inbound15.mxlogicmx.net
luxsci.com MX preference = 20, mail exchanger = luxsci.com.inbound20.mxlogicmx.net
luxsci.com MX preference = 25, mail exchanger = luxsci.com.inbound25.mxlogic.net
The last portion of each line following “exchanger =”, such as “luxsci.com.inbound15.mxlogicmx.net” is the server name for an inbound email server that will be used by this domain. When you send email to an email address ending in “@luxsci.com” it is possible that any one of these servers could be the one that processes the email you sent.
Mac and Linux: DNS Query using “dig”
For Mac OSX and Linux you will be using a command line tool called “dig” which has the following format: “dig +short doman_name mx” (the “+short” eliminates a lot of unneeded textual output). Here is an example with the results:
support$ dig +short luxsci.com mx
10 luxsci.com.inbound10.mxlogic.net.
15 luxsci.com.inbound15.mxlogicmx.net.
20 luxsci.com.inbound20.mxlogicmx.net.
25 luxsci.com.inbound25.mxlogic.net.
The last portion of each line, such as “luxsci.com.inbound15.mxlogicmx.net” (without the trailing period) is the name of an email server the will be used by this domain. When you send email to an email address ending in “@luxsci.com” it is possible that any one of this servers could be the one that processes the email you sent.
Checking support for TLS
The final step is done using a program called “telnet”, which is another command prompt utility that exists in all of the operating systems that we have mentioned. Telnet will be used to simulate the SMTP connection to the server; once connected, we will issue the ”ehlo” command. If the server supports TLS encryption then we will see “250-STARTTLS” in the list of supported options.
The following steps will need to be repeated for every server provided by your query for MX records. To use the Telnet program type, “telnet server_name 25”, replacing “server_name” with the name of a mail server from your DNS query and press “Enter“. (25 is the standard SMTP port at which that all public inbound email servers must be listening for connections). A few lines will appear, the last starting with “220” and containing the date.
support$ telnet luxsci.com.inbound10.mxlogic.net 25
Trying 208.65.144.2…
Connected to luxsci.com.inbound10.mxlogic.net.
Escape character is ‘^]’.
220 p01c11m033.mxlogic.net ESMTP mxl_mta-8.2.0-3 [2ac5dfc25940.177057.00-540]; Tue, 27 Jan 2015 08:42:14 -0700 (MST); NO UCE, INBOUND (p01c11m033.mxlogic.net)
Now type “ehlo” followed by a domain name, your own domain name will work fine, and press “Enter“. If you see within the results the line, “250-STARTTLS”, then that email server is configured to support use of TLS. Here is a full example:
ehlo luxsci.com
250-p01c11m033.mxlogic.net
250-SIZE 0
250-STARTTLS
250-SUBMITTER
250-8BITMIME
250 PIPELINING
Once again you will need to repeat this telnet step for each email server listed in the MX records to be sure that TLS support is enabled on all servers processing email for email address in that domain.
Advanced: Checking TLS Protocol and Ciphers
The telnet test described above only checks to see if the server advertises SMTP TLS support. This is not quite good enough to get the full picture.
- That support could be broken, so that any attempt to actually use TLS fails,
- It does not address what versions of the TLS (or SSL) protocol are supported, nor what Ciphers are available for encryption.
For example, if your mail servers are configured to use only TLS configurations considered “secure”, but your recipient’s servers have only support for old, insecure TLS (e.g. SSL v3 only), then you your servers will not be able to talk TLS together.
In order to actually test if the recipient servers TLS is working and that it supports strong encryption, you can use the “openssl” command line tool. In this example, we will use openssl at the Linux / Mac command line and check and see if the server luxsci.com.inbound10.mxlogic.net supports SMTP TLS with the TLS v1.0+ protocol and the AES 256 Cipher “AES256-SHA“:
openssl s_client -starttls smtp -no_ssl3 -no_ssl2 -cipher “AES256-SHA” -connect luxsci.com.inbound10.mxlogic.net:25
If you get a successful connection, which we do in this case, you will get the beginning of an SMTP dialog (similar to a telnet connection, but now secure), and you can perform an “ehlo” or issue other SMTP commands.
If the connection fails, you will get some kind of error message, perhaps indicating that TLS cannot be negotiated. This would indicate that you cannot speak TLS with this server using TLS v1.0+ and this cipher.
To check if TLS v1.0+ and any of the recommended strong ciphers are supported, you would modify the above example to include all allowed ciphers:
openssl s_client -starttls smtp -no_ssl3 -no_ssl2 -cipher "DES-CBC3-SHA:AES128-SHA:AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-GCM-SHA256:AES128-SHA256:AES256-SHA256:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA384:DHE-DSS-DES-CBC3-SHA:DHE-DSS-AES128-SHA:DHE-DSS-AES256-SHA:DHE-DSS-AES128-SHA256:DHE-DSS-AES256-SHA256:DHE-DSS-AES128-GCM-SHA256:DHE-DSS-AES256-GCM-SHA384:DH-DSS-AES128-SHA:DH-DSS-AES256-SHA:DH-DSS-AES128-SHA256:DH-DSS-AES256-SHA256:DH-DSS-AES128-GCM-SHA256:DH-DSS-AES256-GCM-SHA384:ECDH-ECDSA-DES-CBC3-SHA:ECDH-ECDSA-AES128-SHA:ECDH-ECDSA-AES256-SHA:ECDH-ECDSA-AES128-SHA256:ECDH-ECDSA-AES256-SHA384:ECDH-ECDSA-AES128-GCM-SHA256:ECDH-ECDSA-AES256-GCM-SHA384" -connect luxsci.com.inbound10.mxlogic.net:25
Conclusion
Use of TLS is good practice and secure when you know that it is implemented through the entire chain of delivery. However if security is your top requirement then encrypting the email itself before sending it is the most secure option. This can be done, for example, using PGP or S/MIME or other products that support these and other encryption mechanisms in an integrated format.
SMTP TLS Lookup Tool: LuxSci provides a free tool that does all of these steps for your, including checking for HIPAA-compliant strong TLS support. Use our TLS Checker tool to see if all of the MX records for any domain support TLS or not.
