BACKGROUND IMAGE: iSTOCK/GETTY IMAGES
It's hardly a surprise that people want secure email communications, but the truth is that some email messages might not be secure. That's not very reassuring, and the reason you can't be certain about email security is because organizations generally rely on implicit rather than explicit security to protect email communications.
When sending an email, users write in clear text, add attachments as necessary and then hit send. We expect our email systems will protect the contents of messages until they arrive at their destinations without being intercepted, read by third parties or otherwise compromised.
With implicit security, we trust the session encryption that has long guarded our online work -- the Secure Sockets Layer (SSL) protocol and its more recent replacement, Transport Layer Security (TLS). We assume that as long as our messages and attachments are carried within an SSL/TLS encrypted session, they are safe.
The problem? Encrypted sessions are not a required part of the Simple Mail Transfer Protocol (SMTP), and SMTP will ultimately deliver your email to any recipient outside your company's email system either way. SMTP supports encrypted sessions for secure email, but it isn't mandatory. As the user sending the message, you have no idea if you are getting a secured connection end to end.
In comparison, with explicit security, a message and its contents are encrypted before it is handed off to the email messaging system for delivery.
Following the path of an email
Before we go into more detail, let's follow the email path from user to recipient to see where secure email becomes an issue.
From client to email server. No worries here. The connection between the user and the email system, whether it's cloud-based or an on-premises company email system, is virtually guaranteed to be a secure connection. If users have any doubts about the connection to their cloud email, they can just check the URL in the email system to confirm it begins with HTTPS rather than HTTP, with no s. That s indicates that you are using a secure SSL/TLS session.
Email server communication within the same organization. It's usually safe to assume that your email is being transported via a secure connection. All but the smallest organizations will likely have multiple email servers and domains. Because all the servers are controlled by the same management team -- it is presumably a relatively easy job for security architects to make sure all the security support is up to date and that messages being passed from server to server use SSL/TLS encrypted channels.
Company email server to outside email server. This is where reliance on implicit security can run into trouble -- when users message people outside the organization assuming a secure email status.
As was mentioned earlier, the age-old SMTP carries your message between systems. And simple means simple. The original SMTP protocol uses TCP port 25 to carry unencrypted traffic. For years, it has been possible for servers to request encrypted sessions via TCP port 465, but you can't be certain this is how your traffic is being handled.
Generally, when systems don't support your desired level of security, they back off and request a lower level until both the sending system and the receiving system find a set of security protocols they agree upon. That's great for interoperability across systems, but it might not be great for users' perception of secure email. Ultimately, the systems could back off to a point where messages are simply transmitted as plain text for any intermediary to see and copy.
A point worth noting
Finally, even if users know -- because their techs told them -- that the company's email system will only talk to a secure SMTP receiver, that is of limited value because the receiving SMTP server may yet hand the message off again before it reaches the recipient, and there's no way to confirm whether any subsequent relay happens over a secure connection.
So if the messages or attachments your users send are confidential or contain sensitive messages on a regular basis, you should confirm with your internal network security team that implicit security is really secure. Users should have security explicitly confirm that all messages are sent via secured SSL/TLS channels.