TLS: Secure Email Delivery

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 “Lets talk securely over TLS” (no security)
  4. Computer A and B agree on how to do this (secure)
  5. The rest of the conversation is encrypted (secure)

In particular:

  • The meat of 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
  • The conversation cannot be modified by a third party
  • Other information cannot be injected into the conversation by third parties.
  • TLS (and SSL) is used for many different reasons on the Internet and helps make the Internet a more secure place, when used. One of the popular uses of TLS is with SMTP for transmitting email messages between servers in a secure manner.


The mechanism and language (i.e. protocol) by which one email server transmits email message(s) to another email server is called SMTP (Simple Mail Transport Protocol). For a long time now, email servers have had the option of using TLS to transparently encrypt the message transmission from one server to the other.

Use of TLS with SMTP, when available, ensures that the message contents are secured during transmission between the servers.

Use of TLS requires that the server administrators:

  1. purchase of one or more 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 these reasons, many email providers, especially free or public ones, have in the past not supported TLS at all. Over the last few years, however, the trend has been to add TLS everywhere. Now, the majority of providers do support TLS.

For TLS transmission to be used, the destination email server must “advertise” 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 it is available, if not, send insecurely.
  3. Forced TLS — use TLS or do not deliver the email at all

What about TLS at AHS?

Inbound TLS

AHS inbound email servers support TLS for encrypted inbound email delivery from any sending email provider that also supports it.

For selected organizations AHS also locks down its servers so that it only accepts email from them if it is delivered over TLS (Forced TLS).

Outbound Opportunistic TLS.

AHS 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. If the TLS connection to such a server fails (due to misconfiguration or no security protocols in common), the message will not be sent.

Outbound opportunistic TLS encryption is automatic for all AHS customers.

Support strong encryption, up to AES 256 and better

AHS servers will use the strongest encryption supported by the recipient’s email server that is also considered strong. AHS 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).

Forced TLS

AHS servers use “Forced TLS” with recipient servers that support TLS and those servers are using TLS-Only delivery. This ensures that messages will never be delivered to such servers in the case that they stop supporting TLS suddenly.

Forced TLS is in place for all AHS customers sending to certain vendor organizations that have requested that we globally enforce TLS to their servers.

Email Marked Secure

AHS has a process that has been in place for a number of years that allows customers to send encrypted messages using Cisco Registered Envelope Service (CRES).  If you are sending a message to an organization that we do not have forced TLS set up for, CRES may encrypt the message based on a number of different criteria:

  1. Encrypt based on content –  If your message contains what appears to be Protected Health Information (PHI) or business sensitive data based on filters that have been set up in the system, you message will be encrypted.
  2. Encrypt based on flags in the subject or body of the message – Your message can contain specific words that flag the system to encrypt your message using CRES.  This will occur even though we may have forced TLS configured for the organization your are sending your message to.  These flags include:
    • [marked for secure delivery]
    • [secure]
    • [securetest]
    • [send secure]
    • [sendsecure]
    • [cgnsecure]
  3. Encrypt based on group – If you or your group is a member of a “mandatory encryption list”, the system to encrypt your message using CRES.  This will occur even though we may have forced TLS configured for the organization your are sending your message to.