Sophos Email: Configure TLS and Secure Message securely

A Secure Message policy defines how Sophos Email secures messages and what happens when the selected method cannot be used. For most TLS connections, Preferred TLS 1.3 is the robust starting point: Sophos attempts TLS 1.3 and falls back to TLS 1.2 when necessary. Only enforce Required TLS 1.3 or Required TLS 1.2 for partners whose receiving or sending system has been proven to meet that exact requirement.

Quick path: First enable TLS 1.3 and the required ciphers on your own mail server or service, then test mail flow to Sophos. Under My Products > Email Security > Policies, create a Secure Message policy, define its internal and, if needed, external scope, select direction and method under Settings, and set a small pilot group to Policy is enforced. For outbound messages, decide in advance whether a TLS failure may permit unencrypted delivery or be handled by Fallback to push encrypt the entire message. Then verify the TLS version and delivery status in Message History for each partner and direction.

Warning: TLS must be active on your own mail server or service before you configure any Secure Message method. In particular, your email gateway must support TLS 1.3 before you select Required TLS 1.3. Otherwise, the connection to Sophos can fail and both inbound and outbound email may stop.

Record prerequisites and rollback before changing anything

This guide applies to Sophos Email in Sophos Fusion (formerly Sophos Central), not on-box Mail Protection on Sophos Firewall. Secure Message policies cannot be configured in EMS mode.

Before the change, record:

the current policy name, scope, order, direction and enforcement status, plus any configured disable time;
internal users, groups or domains and the affected external addresses or domains;
TLS versions and ciphers on your mail server and the pilot peers;
whether the peer presents a certificate for its recipient domain;
the approved fallback decision for each communications partner;
test senders, recipients, message IDs, change window and owners of both mail platforms.

Sophos recommends TLS 1.3. The documented cipher string is exactly TLSv1.2+FIPS:kRSA+FIPS:!eNULL:!aNULL. TLS 1.0 and TLS 1.1 have not been supported for inbound or outbound email delivery since 1 January 2024. Your server must therefore not be restricted to those older versions.

For rollback, retain screenshots or exported details of the previous policy. You can return a new or cloned pilot policy to Policy Bypassed and restore the previous order. Do not delete a working policy before all tests are complete.

Choose the method and failure behaviour deliberately

TLS: transport encryption in the normal email client

Secure using TLS protects the SMTP connection in transit; senders and recipients continue to use their usual email client. It does not mean that the message remains in an encrypted container after delivery to the mailbox.

The TLS levels have different consequences:

Preferred TLS 1.3 attempts TLS 1.3 and uses TLS 1.2 when the peer does not support TLS 1.3. Sophos recommends this more flexible option because it is less likely to interrupt message exchange.
Required TLS 1.3 accepts TLS 1.3 only. If the peer does not support it, the message is not exchanged over another TLS version.
Required TLS 1.2 accepts TLS 1.2 only. TLS 1.3 is not a substitute in this mode; the selected version is enforced.

Without this enforcement, Sophos attempts TLS by default whenever a TLS connection is feasible. This is opportunistic behaviour: it provides compatibility but does not guarantee that every peer is reached securely. If a specific version or certificate check is a contractual requirement, give that partner a tightly scoped Required policy and perform a documented failure test.

For outbound connections using Required TLS 1.3 or Required TLS 1.2, you can also enable Verify certificate. Sophos then checks that the certificate was issued for the recipient domain. Delivery does not take place if the check fails. The external scope must therefore contain the actual recipient domain, and you must check which host and certificate its MX path presents; a similarly named partner domain is not a substitute.

Do not confuse Push Encryption or Portal Encryption with TLS

Push Encryption is outbound only. Sophos converts message content into a password-protected document; Microsoft Office, ZIP and PDF attachments use their native encryption, while other formats may be provided as PDF. On first use, the recipient creates a Sophos Secure Message password via the notification. Its link expires after 30 days. The password applies only to messages from the same region as the original message. For recipient opening, password use and secure replies, see Operate Sophos Email Portal and Push Encryption.

Portal Encryption is also outbound only and requires a Sophos Email licence with the Portal Encryption Add-on. The recipient reads and replies in Sophos Secure Message and creates an account for the first message. Branding, recipient administration, expiry and recall form a separate portal operations workflow; this article only selects the method in the policy.

Secure using S/MIME requires previously configured CAs, user and recipient certificates, and private keys. S/MIME can sign without necessarily encrypting. Certificate provisioning, trust, extraction and reset therefore belong in a separate S/MIME workflow and are not replaced by TLS Verify certificate.

For outbound TLS to a peer without TLS support, Sophos offers Allow unencrypted delivery or Fallback to push encrypt the entire message; Sophos recommends the push fallback. When the push fallback is configured and TLS negotiation fails, Sophos sends the message using Push Encryption instead of queueing it for TLS redelivery. Select unencrypted delivery only when the data classification explicitly permits it. Push fallback is appropriate only if recipients may open password-protected documents and the initial registration process is acceptable. If neither fallback is approved and TLS negotiation fails, do not expect a silent clear-text fallback.

Create and scope the Secure Message policy

Open My Products > Email Security > Policies and click Add Policy.
Select Secure Message, then Continue. Enter a clear name, such as SM-Outbound-Partner-TLS13.
Under Internal, add users, groups or domains. A match in any one list is sufficient. Hover over a user’s name to verify their email address.
For a partner-specific rule, open External and add the exact email address or domain manually or from a file. Check whether the list is included or excluded; the default is Include all. The policy applies when an internal entry communicates with an external entry.
Open Settings, select Inbound or Outbound, and enable Secure inbound messages or Secure outbound messages.
Under Select the method to secure messages, choose the approved method. For TLS, then set Preferred TLS 1.3, Required TLS 1.3 or Required TLS 1.2.
If required for an outbound Required TLS partner, enable Verify certificate. Explicitly set the fallback or failure behaviour; do not infer it from the policy name.
For Push or Portal Encryption, choose the language of notification and registration messages sent to recipients.
Under Choose how to secure, decide whether to secure every message or let users trigger it with a subject tag. The fixed default tag secure: always triggers encryption, even when custom triggers are defined. Custom triggers such as secureTest: or secureFull: must appear in full and exactly at the start of the subject; a substring is not enough.
Set the pilot policy to Policy is enforced, save it and verify its priority. You can optionally set a date and time to disable it automatically.

Use Clone for several similar scopes. A clone starts as Policy Bypassed, a Base Policy clone has no users, groups or domains, and the clone has higher priority than the original by default. Verify scope, settings and order before selecting Policy is enforced.

Migrated tenants may have policies whose names start with Migrated. These contain the former TLS and encryption settings from Global Settings and the users and domains protected at migration time. They can be edited, renamed, merged or deleted, but only after comparing scope, method, fallback and priority with today’s intended state.

Interaction with Data Control

An outbound encryption action in a Data Control policy overrides the encryption method selected in the Secure Message policy. If a message unexpectedly uses Push or Portal rather than TLS, check both the Secure Message policy and matching Data Control rules. Check scope and order separately because the policy families perform different tasks.

Validate with representative recipients

For acceptance, send controlled, non-confidential messages to at least one recipient inside policy scope and one comparison recipient outside it. A partner-specific TLS test plan includes:

a peer that supports the selected TLS version and, with Verify certificate enabled, presents a matching certificate;
a peer that supports TLS 1.2 but not TLS 1.3, to exercise Preferred TLS 1.3;
an approved negative test where the TLS or certificate requirement is not met;
for configured push fallback, a recipient who completes notification, password creation and message opening;
for subject tags, one message with the exact trigger, one with an incomplete trigger and one without a trigger.

In Message History, open Filter on the left, select the Secure message category and filter by TLS version. Open the subject. In Message Details, hovering over the three-dot ellipsis under Status shows whether the connection was secured with TLS and which TLS version was authenticated. If Sophos could not verify the issuing CA signature, SMTP Text states that TLS delivery was untrusted.

A successful acceptance record includes policy name and priority, internal and external scope values, message ID, timestamp, recipient, selected method, observed TLS version, certificate result, fallback and final recipient outcome. A Message History entry alone does not prove that the recipient could read the message.

Investigate TLS failures, queueing and certificates

If Sophos Email cannot establish a required TLS connection and no configured fallback handles the message, the email is not sent. Sophos queues it for redelivery for up to seven days and then deletes it. Every TLS-related send attempt creates a history entry in the format Processing: Check TLS; after the final failure, the log records that the message was deleted because of TLS policy. This is not a suitable mechanism for testing a faulty Required setting in production for seven days.

Check in this order:

Is the expected Secure Message policy set to Policy is enforced, with the correct internal and external scope and intended priority?
Does a Data Control action override the method, or does the fixed secure: tag trigger encryption?
Do your own mail server and the peer support the selected version? TLS 1.0 and 1.1 are not fallbacks.
Are TLS and the required ciphers enabled, particularly the documented string TLSv1.2+FIPS:kRSA+FIPS:!eNULL:!aNULL?
With Verify certificate, does the presented certificate match the actual recipient domain, and can Sophos verify the issuing CA?
Do Message History, Processing: Check TLS and SMTP Text indicate a version, trust or negotiation failure?

If the cause remains unclear, collect policy name, scope, priority, message ID, timestamp, direction, recipient domain, expected and observed TLS version, and relevant history and SMTP text for Sophos Email Support. Do not include private keys, passwords or confidential message content in the ticket.

Roll back safely

If mail flow behaves unexpectedly, first return the new policy to Policy Bypassed or use the prepared disable time and restore the previous priority. Retest in both directions and confirm the previous path in Message History and at the recipient. Do not relax the TLS version, certificate verification and scope simultaneously, as that conceals the cause.

A temporary fallback to Preferred TLS 1.3, Push Encryption or unencrypted delivery is permissible only if the data owner and change owner explicitly approve that option. If clear text is prohibited, it is safer to hold the message while the partner corrects its TLS version, ciphers or certificate chain. Expand scope or clean up an old Migrated policy only after successful pilot and negative tests.