An ever increasing number of mail services and services now support "opportunistic" TLS encryption for emails. When an email is delivered from one mail server to another, it can use an encrypted tunnel to send the email. Since this requires a certificate for the server and additional overhead in both computational time and network load, many services do not support TLS, and most still do not require TLS connections.
The SecureMail Gateway offers multiple methods to secure your emails. When sending to a recipient that has an S/MIME email certificate (i.e. another GlobalCerts customer), the system will utilize automatic S/MIME encryption. When sending to a recipient with no certificate capabilities, it will default to using SecureMessenger secure web portal for delivery. However, the SMG can also utilize SMTP over TLS (STARTTLS) to encrypt messages to recipients if available. The SMG administrator can specify certain recipient domains to enforce TLS encryption with, rather than using SecureMessenger.
Steps to set up a TLS connection with a partner domain:
Navigate to "Network Configuration" -> "Mail Options"
In the section labelled "TLS Connection Settings" enter the partner domain(s).
Click the "Set" button. Changes will take effect in 1 minute or less.
Send a test message to ensure it sends successfully.
NOTE: 'domain.com' will also match all sub-domains like 'sales.domain.com'. You may also enter particular users ('email@example.com') rather than entire domains. If you enter a blank line in this section, it will require TLS with EVERY recipient domain.
To ensure that your emails remain encrypted from end to end, it is important that you determine that all 'hops' in the recipient's inbound mail path enforce the use of secure TLS connections or are adequately secured. Mail flows involve multiple server hops before emails finally reach the end user, and ALL of these relays should enforce strong TLS encryption. It is not enough to check that their receiving (MX) server supports TLS. For instance the organization may use a cloud based Anti-Spam/Anti-Virus as their inbound mail service which may support opportunistic TLS with incoming connections, but it may not utilize a TLS connection when relaying the message to the on-premise mail server.
If the recipient domain's mail server does NOT support at least a 112-bit encrypted connection, the message will bounce back to the sender with a non-delivery report (NDR):
503 5.7.0 encryption too weak 0 less than 112
If you would like to require stronger encryption or need something more specific, please contact us for assistance.