Set up Sophos Firewall SPX email encryption

With Secure PDF Exchange, or SPX, Sophos Firewall converts an outbound email and its attachments into a password-protected PDF file. Recipients don’t need their own encryption client. Depending on the selected password model, they receive a one-time password, use a stored password, or register one themselves.

Four elements must work together for reliable operation: an SPX template, an unambiguous trigger, a secure password channel, and, if needed, the SPX Reply Portal. A positive and a negative mail flow are then tested. Delivery of a PDF alone proves neither that the correct policy triggered nor that password registration and secure replies work.

SPX in eight steps

1. Check the Email Protection license, MTA mail flow, model support, and certificate.
2. Decide whether a protected domain, a Data Control match, or the sender triggers encryption.
3. Create a custom template under Email > Encryption > SPX templates > Add.
4. Deliberately select the password type, PDF encryption, notification, and Reply Portal.
5. Secure the FQDN, allowed networks, and port under Email > Encryption > SPX portal settings.
6. Assign the template in the SMTP route and scan policy or as an intentional default template.
7. Test the PDF, password channel, registration, and reply with an external recipient.
8. Run a negative test without an SPX trigger and document Mail logs, MTA logs, and rollback.

⚠️ An empty Allowed networks field for the SPX Portal doesn’t mean “no access”; it falls back to Any. Sophos also recommends a dedicated port for the Reply Portal. The portal FQDN, certificate, allowed sources, and password channel must therefore be defined before the production test.

When SPX fits

SPX is useful when external recipients should receive confidential content as a protected PDF without installing an encryption client. It can be used in both MTA mode and Legacy mode. This workflow uses MTA mode because domains, Data Control, and routing can be connected transparently in the SMTP policy.

SPX isn’t transport encryption between mail servers and isn’t end-to-end encryption between two mail clients. The firewall processes the plain text, creates the PDF, and controls the password or registration. The PDF can then continue to exist outside the firewall in mailboxes, archives, or downloads. The recipient scope, retention, and password delivery are therefore part of the security design.

Prerequisites are:

• a valid Email Protection license;
• an already tested outbound mail flow through Sophos Firewall;
• a documented external test recipient;
• a trusted FQDN and a matching certificate for the SPX portals in use;
• a separate secure channel for passwords when recipients don’t register them;
• a recovery path for removing template and policy assignments again.

According to the current Sophos help, SPX isn’t available on XGS 87/87w. Full MTA mode is additionally unavailable on XGS 88/88w. Set up Mail Protection in MTA mode explains mail flow, licensing, relay, and model limits.

Define the trigger and priority

SPX can be triggered in three ways. If several methods are configured, Sophos Firewall applies this order in MTA mode:

1. Protected domain: The SPX template selected under Domains and routing target applies to outbound messages from the matching protected domain.
2. Data control list: Only if no SPX template is set at domain level can a Data Control match apply the template selected for the list.
3. Sender trigger: Only when neither the domain nor Data Control supplies a template does the sender method configured under Default SPX template apply.

A domain assignment is broad and only fits when every matching outbound message should actually be encrypted. Data Control suits defined content types but must be tested for false positives with real positive and negative examples. The sender trigger leaves the decision to the sender but requires a clearly documented mail client workflow.

One primary trigger is defined for each mail flow before configuration. A second method must not silently override another.

Create the SPX template

The example uses the Finance-SPX-Recipient template. The name is a documentation value and must be adapted to the purpose and organization.

1. Open Email > Encryption > SPX templates.
2. Select Add.
3. Enter a name such as Finance-SPX-Recipient.
4. Set the organization name for notifications.
5. Select Encryption standard and PDF page size according to the organization’s requirements.
6. Under Password type, select the planned password model.
7. Review the subject, message body, and recipient instructions and adapt them if necessary.
8. If secure replies are required, turn on Enable SPX reply portal.
9. Turn on Include original body into reply only if the original message may be included in the reply.
10. Save the template.

Deliberately select the password model

Sophos Firewall offers four models:

• Specified by sender: The sender sets the password. The firewall removes it before delivery and doesn’t store it. The password must reach the recipient through a separate secure channel.
• Generate one-time password for every email: The firewall generates a new password for each message and sends it to the sender. The sender delivers it separately to the recipient. The password isn’t stored.
• Generated and stored for recipient: The firewall generates a recipient-specific password, sends it to the sender, and reuses it until it expires.
• Specified by recipient: A recipient who hasn’t registered receives a registration link, sets a password, and uses it until expiry for further SPX messages from the organization.

For an ongoing partner relationship, Specified by recipient is often the easiest workflow to understand. A one-time password may be more suitable for a single particularly sensitive delivery. Different stored password models shouldn’t be mixed unintentionally for the same recipient because the recipient must otherwise identify the matching password for each message.

With Specified by sender, the subject can use the pattern [secure:<password>]<subject text>. The sender must then deliver the password separately. Sophos provides an Outlook Add-in for Microsoft Outlook under Authentication > Client downloads.

The current Sophos help uses two different header spellings for other mail clients: X-Sophos-SPXEncrypt: yes on the template page and X-Sophos-SPX-Encrypt: yes on the general Encryption page. This discrepancy isn’t treated as a copy-and-paste recipe. Before a production client rollout, verify which spelling works on the deployed SFOS build. Where possible, a policy, Data Control, or the Sophos Outlook Add-in is the more traceable trigger.

Design the notification without creating another data leak

Available notification variables include:

• ENVELOPE_TO
• PASSWORD
• ORGANIZATION_NAME
• SENDER
• REG_LINK

Simple HTML formatting and links are supported. The text must explain who sent the message, how the password is obtained securely, and how long registration or replies remain possible. Credentials or confidential email content don’t belong in an additional unprotected notification.

Secure the SPX portals

Password registration and portal access are defined under Email > Encryption > SPX portal settings:

1. Under Hostname, enter the FQDN through which external recipients actually reach the portal.
2. Under Allowed networks, set only the required source networks. Any is only appropriate when arbitrary external recipients must reach the portal and the risk is consciously accepted.
3. Document the port. The Password Registration Portal uses TCP 8094 by default.
4. Use a dedicated port for the SPX Reply Portal.
5. Set the validity periods for unused passwords, secure replies, and registration links.
6. Enter the recipients for SPX error notifications.

If Allowed networks remains empty, SFOS uses Any because the SPX Reply Portal is enabled in the WAN zone by default. If the Reply Portal isn’t required, Sophos documents using an unused trusted private address, such as 169.254.0.1, as the only allowed network to turn it off. This documentation value must not match an address used in production.

CAPTCHA is always active on the SPX Portal and can’t be disabled. Control CAPTCHA on Sophos Firewall deliberately explains the limits of the other portal CAPTCHA settings.

WebAdmin, User Portal, VPN Portal, Captive Portal, and both SPX portals use the same central certificate selection. A change can therefore affect several services at once. Plan the certificate, SANs, recovery path, and real portal URL with Manage certificates on Sophos Firewall. A Let’s Encrypt certificate on Sophos Firewall may suit a public name.

Connect the template to the SMTP policy

For MTA mode, select the SPX template in the matching SMTP route and scan policy under Email > Policies and exceptions.

Use a domain as the trigger

Under Domains and routing target, assign the template to the protected domain. It then applies to matching outbound messages. Test a broad domain assignment first with one pilot sender and one external test recipient.

Use Data Control as the trigger

1. Create a clearly named list under Email > Data control list or review the existing list.
2. Turn on Data protection in the SMTP route and scan policy.
3. Assign the intended SPX template to the Data Control List.
4. Run one positive content test and one similar negative test.

If an SPX template is already set under Domains and routing target, it takes priority over the Data Control template. A Data Control List match also only proves the configured content match. The real mail flow must show whether the correct message was encrypted.

Use a sender trigger

Select a Default SPX template under Email > Encryption > SPX configuration. It applies to sender-triggered SPX encryption only when the SMTP policy doesn’t already supply a template at domain or Data Control level. None disables this default path.

Validate the encrypted mail flow

Record the test time, sender, recipient, subject, and expected trigger. Then test at least these cases:

1. Positive test: An outbound message triggers exactly the intended SPX template.
2. Password test: The recipient receives the password or registration link through the planned channel and can open the PDF.
3. Content test: The subject, body, and attachments appear in the PDF as expected and are readable.
4. Reply test: If enabled, the reply link leads to the expected FQDN and a test reply reaches the original sender.
5. Negative test: A similar message without the trigger isn’t sent as an SPX PDF.
6. Expiry test: Registration, stored password, and reply period behave predictably after the defined validity period.
7. Certificate test: The browser and external recipient receive a complete trusted certificate chain for the portal FQDN in use.

For initial correlation, use Email > Mail logs, Log Viewer, and the MTA files smtpd_main.log, smtpd_error.log, and smtpd_panic.log. Correlate an error message with the same test email and timestamp. Sophos Firewall services and logs explains access and additional log files.

In HA, logs reside on the node that processed the traffic. After a controlled failover, test a new SPX email, password registration, and reply separately. Don’t assume that an existing portal session or an ongoing registration process continues without interruption. See Sophos Firewall HA clusters for the HA fundamentals.

Narrow down errors systematically

The message isn’t encrypted

Check the direction, protected domain, actual SMTP route and scan policy, and trigger priority. For Data Control, also check Data protection, the list match, and template assignment. For a sender trigger, a default template must be set and must not be overridden by a domain or Data Control template. The two documented header spellings aren’t a reason to deploy both untested in production.

The registration link or portal isn’t reachable

Check the FQDN, public DNS resolution, port, certificate, Allowed networks, and link validity. An empty Allowed Networks value is treated as Any and therefore isn’t a secure disabled state. If the client reaches another host or portal, the URL, NAT, or certificate assignment doesn’t match the planned path.

The PDF can’t be opened

First match the password type to the specific message. A one-time password only applies to that email. With stored or registered passwords, expiry or multiple password models can be the cause. After an SPX Password Reset, the sender must again deliver the new password securely to the recipient.

The secure reply doesn’t arrive

Check Enable SPX reply portal in the template, the reply period, portal FQDN, port, certificate, and allowed sources. Then inspect Mail logs and MTA logs for the specific reply. Successfully opening the PDF doesn’t prove that the return channel works.

DKIM validation fails after SPX

SPX changes the body and attachments. If a message is signed before this change, the signature can become invalid at the recipient. Define whether the internal mail server, Sophos Firewall, or a later gateway signs after all planned modifications. The processing chain and an external test belong together.

Roll back safely

1. First remove the specific SPX assignment from Domains and routing target or the Data Control List.
2. If used, set Default SPX template to None.
3. Run an outbound negative test and confirm that no new SPX PDF is created.
4. Only withdraw the Reply and Registration Portal if no other active SPX policy depends on it.
5. Restore temporary public port, DNS, or portal access to the documented previous state.
6. Delete the template only after no policy or active operational workflow references it.
7. Preserve Mail logs and MTA logs for the last encrypted and first unencrypted test.

Create a current Sophos Firewall backup before changing production mail and portal paths. SPX can continue to work in air-gapped environments, but external DNS, certificate, and portal dependencies must remain separately reachable. See SFOS features without internet access for product limits.

Operations checklist

• The license, model, MTA mail flow, and external recipient have been checked.
• The trigger and trigger priority are documented.
• The password type and secure delivery channel fit the use case.
• The portal FQDN, certificate, port, and Allowed Networks are tightly scoped.
• The domain, Data Control, or default assignment is unambiguous.
• Positive, negative, password, PDF, and reply tests have passed.
• Mail logs and MTA logs can be correlated with the test message.
• HA failover and node-local logs are covered by the operating procedure.
• The owner, expiry periods, review date, and rollback are documented.

FAQ