Home > Resources > System Admin Guide to a Secure Network > Check if an Email Was Encrypted using Message Headers

How to Check if an Email Message was Encrypted with TLS By Analyzing Message Headers

The use of TLS (Transport Layer Security) encryption in emails allow sensitive information to be sent securely through the open and inherently unsecure Internet. Financial institutions, healthcare providers, law firms, or regulated industries are example entities that need or is required to use encryption. They would have information to send or receive via email that needs to be protected from unauthorized disclosure (e.g., eavesdropping). The use of TLS encryption provides the mechanism to accomplish this. But how can one confirm TLS encryption was used in the delivery of an email message? This is were email message headers can help. Every email that is sent has a log of how it was delivered, along with a variety of other information (such as date and time sent, sender information, and recipient information).

For our purpose, the header we are interested in is the Received header. When you send an email, it is often relayed from one email server to another until is reaches the recipient. Email servers that relay your message, also called hops, record details about its handling of your email in the message header. It includes information about its hostname, IP address, and whether encryption was employed for the delivery of your email.

There are two ways to check to see if an email was encrypted with TLS throughout its journey to the recipient's email box. The manual method involves inspection of the message header with your own eye. The other method is automated analysis using a tool. While using a tool to perform the analysis makes sense, it is important to have a general understanding on how to inspect message headers with your own eyes to identify the use of TLS.

Manually Inspecting Message Header

Looking at the example message header below, we see that a few servers were involved in the delivery of this particular email. Looking as each of the Received header, we can identify that TLS encryption (highlighted in yellow) was used by each server to secure the message throughout the journey of this email from the sender's email server to the recipient's. The Received headers all have a timestamp and it is read from the bottom to the top as this is the sequence of servers the email traveled through. It should be noted that other than the Received headers, all other headers can be forged. Thus, take the information you see with a grain of salt - particularly if your investigating whether an email is authentic.

Message Header Example



Automated Method Using Microsoft Remote Connectivity Analyzer

Located at https://testconnectivity.microsoft.com, the Microsoft Remote Connectivity Analyzer is easy to use. Simply paste your message headers into the textbox provided and click the Analyze headers button. In the example screenshot below, information about the use of TLS encryption neatly found on the last column, highlighted in yellow. This shows TLS encryption was employed throughout the email's journey as it was relayed from one server to the next. Unlike the raw message header, the Microsoft Remote Connectivity Analyzer neatly organize each Received header in its report from top to bottom.

Microsoft Remote Connectivity Analyzer - Exampe Message Header Report

Summary

The use of TLS, and Enforced TLS in a lot of cases now, is becoming more and more common. Cyber criminals are continually trying to intercept and read other people's emails with malicious intent. Sometimes it is for some financial gain, other times it may be to steal someone's identity. Regardless, if you work for a company that sends or received sensitive information by email (such as corporate research information or trade secrets, patient health information (HIPAA), or customer's personally identifiable information (PII), it is highly recommended that you employ TLS. Many email providers are moving towards supporting TLS. If yours does not, you can either move to another email service provider that does, or look into supplementing your existing email solution with a third-party secure email providers.