Secure email sending is a priority for organizations that communicate sensitive data externally. One of the most common ways to send secure emails is with SMTP TLS. TLS stands for Transport Layer Security and is the successor of SSL (Secure Socket Layer). TLS is one of the standard ways that computers on the internet transmit information over an encrypted channel. In general, when one computer connects to another computer and uses TLS, the following happens:

1. Computer A connects to Computer B (no security)
2. Computer B says “Hello” (no security)
3. Computer A says, “Let’s talk securely over TLS” (no security)
4. Computers A and B agree on how to do this (secure)
5. The rest of the conversation is encrypted (secure)

In particular:

• The conversation is encrypted
• Computer A can verify the identity of Computer B (by examining its SSL certificate, which is required for this dialog)
• The conversation cannot be eavesdropped upon (without Computer A knowing)
• A third party cannot modify the conversation
• Third parties cannot inject other information into the conversation.

TLS and SSL help make the internet a more secure place. One popular way to use TLS is to secure SMTP to protect the transmission of email messages between servers.

Secure SMTP Email Delivery with TLS 

The mechanism and language by which one email server transmits email messages to another email server is called Simple Mail Transport Protocol, or SMTP. For a long time, email servers have had the option of using TLS to transparently encrypt the message transmission from one server to another.

When available, using TLS with SMTP ensures the message contents are secured during transmission between the servers. Unfortunately, not all servers support TLS! Many email providers, especially free or public ones, have historically not supported TLS. Thankfully, the trend is shifting. LuxSci found that most providers now support TLS- approximately 85% of domains tested as of July 2022.

Using TLS requires that the server administrators:

1. purchase SSL certificates
2. configure the email servers to use them (and keep these configurations updated)
3. allocate additional computational resources on the email servers involved.

For TLS transmission to be used, the destination email server must offer support for TLS, and the sending computer or server must be configured to use TLS connections when possible.

The sending computer or server could be configured for:

1. No TLS: never use it.
2. Opportunistic TLS: use it if available; if not, send it insecurely.
3. Forced TLS: use TLS or do not deliver the email at all.

How Secure is Email Delivery over SMTP TLS?

TLS protects the transmission of the email message contents. It does nothing to protect the security of the message before it is sent or after it arrives at its destination. For that, other encryption mechanisms may be used, such as PGP, S/MIME, or storage in a secure portal.

For sending sensitive information to customers, transmission security is the minimum standard for compliance with healthcare and financial regulations. TLS is appropriate to meet most compliance requirements and offers an excellent alternative to more robust and less user-friendly encryption methods (like PGP and S/MIME).

There are different versions of TLS- 1.0 and 1.1 use older ciphers and are not as secure, while TLS 1.2 and 1.3 use newer ciphers and are more secure. When an email is sent, the level of TLS used is as secure as can be negotiated between the sending and receiving servers. If they both support strong encryption (like AES 256), then that will be used. If not, a weaker grade of encryption may be used. The sending and receiving servers can choose the types of encryption they will support. If there is no overlap in what they support, then TLS will fail (this is rare).

What About Replies to Secure Messages?

Let’s say you send a message to someone that is securely delivered to their inbox over TLS. Then, that person replies to you. Will that reply be secure? This may be important if you are communicating sensitive information. The reply will use TLS only if:

1. The recipient’s servers support TLS for outbound email (there is no way to test this externally).
2. The mail servers (where the “From” or “Reply” email address is hosted) support TLS for inbound email.
3. Both servers support overlapping TLS ciphers and protocols and can agree on a mutually acceptable means of encryption.

Unless familiar with the providers in question, it cannot be assumed that replies will use TLS. So, what should you do? Ultimately, it depends on what compliance standards you must meet, the level of risk you are willing to accept, and the types of communications you send. There are two general approaches to this question:

1. Conservative. If replies must be secure in all cases, assuming TLS will be used is unreasonable. In this case, a more secure method should be used to encrypt the messages in transit and store them upon arrival. The recipient must log in to a secure portal to view the message and reply securely. Alternatively, PGP or S/MIME could be used for additional security.
2. Aggressive. In some compliance situations like HIPAA, healthcare providers must ensure that ePHI is sent securely to patients. However, patients are not beholden to HIPAA and can send their information insecurely to anyone they want. If the patient’s reply is insecure, that could be okay. For these reasons, and because using TLS for email security is so easy, many do not worry about the security of email replies. However, this should be a risk factor you consider in an internal security audit. Consider nuanced policies that allow you to send less sensitive messages with TLS while sending more sensitive messages with higher security.

What are the Weaknesses of SMTP TLS?

As discussed, SMTP TLS has been around for a long time and has recently seen a great deal of adoption. However, it has some deficiencies compared to other types of email security:

• There is no mandatory support for TLS in the email system.
• A receiver’s support of the SMTP TLS option can be trivially removed by an active man-in-the-middle because TLS certificates are not actively verified.
• Encryption is not used if any aspect of the TLS negotiation is undecipherable/garbled. It is very easy for a man-in-the-middle to inject garbage into the TLS handshake (which is done in clear text) and have the connection downgraded to plain text (opportunistic TLS) or have the connection fail (forced TLS).
• Even when SMTP TLS is offered and accepted, the certificate presented during the TLS handshake is usually not checked to see if it is for the expected domain and unexpired. Most MTAs offer self-signed certificates as a pro forma. Thus, in many cases, one has an encrypted channel to an unauthenticated MTA, which can only prevent passive eavesdropping.

The Latest Updates to Secure SMTP TLS

Some solutions help remedy these issues—for example, SMTP Strict Transport Security. SMTP STS enables recipient servers to publish information about their SMTP TLS support in their DNS. This prevents man-in-the-middle downgrades to plain text delivery, ensures more robust TLS protocols are used, and can enable certificate validation.

In addition, users can adopt TLS 1.3. NIST recommends that government agencies develop migration plans to support TLS 1.3 by January 1, 2024. LuxSci supports both SMTP MTA-STS and TLS 1.3.

How Secure SMTP TLS Email Works with LuxSci

Inbound TLS

LuxSci’s inbound email servers support TLS for encrypted inbound email delivery from any sending email provider that also supports that. For selected organizations, LuxSci also locks down its servers to only accept email from them if delivered over TLS.

Outbound Opportunistic TLS

LuxSci’s outbound email servers will always use TLS with any server that claims to support it and with whom we can talk TLS v1.0+ using a strong cipher. The message will not be sent securely if the TLS connection to such a server fails (due to misconfiguration or no security protocols in common). Outbound opportunistic TLS encryption is automatic for all LuxSci customers, even those without SecureLine.

Forced TLS

When Forced TLS is enabled, the message is either dropped or sent with an alternate form of encryption if the recipient’s server does not support TLS. This ensures that messages will never be sent insecurely. Forced TLS is also in place for all LuxSci customers sending to banks and organizations that have requested that we globally enforce TLS to their servers.

Support for strong encryption

LuxSci’s servers will use the strongest encryption supported by the recipient’s email server. LuxSci servers will never employ an encryption cipher that uses less than 128 bits (they will fail to deliver rather than deliver via an excessively weak encryption cipher), and they will never use SSL v2 or SSL v3.

Does LuxSci Have Any Other Special TLS Features?

When using LuxSci SecureLine for outbound email encryption:

1. SMTP MTA STS: LuxSci’s domains support SMTP MTA STS, and LuxSci’s SecureLine encryption system leverages STS information about recipient domains to improve connection security.
2. Try TLS: Account administrators can have secure messages “try TLS first” and deliver that way. If TLS is unavailable, the messages would fall back and use more secure options like PGP, S/MIME, or Escrow. Email security is easy, seamless, and automatic when communicating internally or with others who support TLS.
3. TLS Exclusive: This is a special LuxSci-exclusive TLS sending feature. TLS Exclusive is just like Forced TLS, except that messages that can’t connect over TLS are just dropped. This is ideal for low-importance emails that must still be compliant, like email marketing messages in healthcare. In such cases, the ease of use of TLS is more important than receiving the message.
4. TLS Only Forwarding: Account administrators can restrict any server-side email forwarding settings in their accounts from allowing forwarding to any email addresses that do not support TLS for email delivery.
5. Encryption Escalation: Often, TLS is suitable for most messages, but some messages need to be encrypted using something stronger. LuxSci allows users to escalate the encryption from TLS to Escrow with a click (in WebMail) or by entering particular text in the subject line (for messages sent from email programs like Outlook).
6. Domain Monitoring: When TLS delivery is enabled for SecureLine accounts, messages will never be insecurely sent to domains that purport to be TLS-enabled, i.e., TLS delivery is enforced and no longer “opportunistic.” The system monitors these domains and updates their TLS-compliance status daily.
7. Double Encryption: Messages sent using SecureLine and PGP or S/MIME will still use Opportunistic TLS whenever possible for message delivery. In these cases, messages are often “double encrypted.” First, they are encrypted with PGP or S/MIME and may be encrypted again during transport using TLS.
8. No Weak TLS: Unlike many organizations, LuxSci’s TLS support for SMTP and other servers only supports those protocol levels (e.g., TLS v1.0+) and ciphers recommended by NIST for government communications and which are required for HIPAA. So, all communications with LuxSci servers will be over a compliant implementation of TLS.

For customers who can use TLS to meet security or compliance requirements, it enables seamless security and “use of email as usual.” SecureLine with Forced TLS enables clients to take advantage of this level of security whenever possible while automatically falling back to other methods when TLS is unavailable.

Of course, using Forced TLS as the sole method of encryption is optional; if your compliance needs are more substantial, you can turn off TLS-Only delivery or restrict it so that it is used only with specific recipients.

If your email use cases are complicated, LuxSci’s flexibility enables the secure sending of emails to any recipient, regardless of their email service provider’s support for TLS. Contact the LuxSci sales team to learn more about our secure SMTP TLS email sending.