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, portal certificate, and separate SMTP TLS path.
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. In MTA mode, configure the SMTP route and scan policy and assign the template; a Default SPX template does not replace this policy.
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. Configure Mail Protection in legacy mode explains the transparent alternative.

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.

SMTP transport encryption is controlled separately under Email > General settings > SMTP TLS configuration. Require TLS negotiation enforces TLS for selected remote hosts or networks; if SFOS can’t establish the TLS connection, it discards email to that destination. Skip TLS negotiation, by contrast, forces an unencrypted SMTP connection. The TLS certificate selected there protects the SMTP path and isn’t the certificate used by the SPX portals. Plan SPX and SMTP TLS separately, then validate both in the external mail flow.

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.

Separate templates with appropriate text and company logos can be used for different customer domains. This is not just a branding choice: recipient instructions must match the password model and the domain actually assigned.

1. Open Email > Encryption > SPX templates.
2. Select Add.
3. Enter a name such as Finance-SPX-Recipient. SFOS doesn’t allow apostrophes, slashes, commas, backslashes, or quotation marks in the name.
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. For this MTA workflow, turn on Enable SPX reply portal, as required by the template help. Secure portal access as described below before testing.
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.

With Specified by recipient, the first encrypted message is sent only after password registration; receiving the registration link does not mean the SPX PDF has been delivered.

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 password is entered in the subject using 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.

After the installation has been checked, select Encrypt in Outlook for the message to be encrypted. Installing the add-in alone does not trigger encryption.

Install the Outlook Add-in in a controlled way

Users without WebAdmin access open Download client in the User Portal and select Download Sophos Outlook Add-in. Extract the downloaded archive to a temporary folder and run setup.exe there for an interactive installation. The administrative download under Authentication > Client downloads is a separate access path.

Check the MSI filename before deployment: The User Portal help for SFOS 22 and 23 names SophosOutlookAddInSetup.msi; the SPX installation instructions instead name SophosOutlookAddInSetupUTM.msi, as in the existing example below. These names have not been confirmed as interchangeable. Check the actual MSI filename in the extracted package. The following example applies only if the file is actually named SophosOutlookAddInSetupUTM.msi. For a package containing SophosOutlookAddInSetup.msi, use that exact existing filename as the argument to /i; the documented switches /qr /i and T=1 EC=3 C=1 I=1 remain unchanged. If the expected MSI is missing or the package cannot be clearly identified, stop deployment and clarify the package rather than renaming a file or assuming support for modern platforms.

For an interactive installation, run setup.exe from the package downloaded from the active firewall. Sophos documents this command for an unattended deployment:

msiexec /qr /i SophosOutlookAddInSetupUTM.msi T=1 EC=3 C=1 I=1

The public compatibility list is conspicuously old: The SFOS help documents the following historical prerequisites for unattended installation of the SPX Outlook Add-in: Windows XP, Windows Vista, Windows 7, or Windows 8, each in both 32-bit and 64-bit editions; Microsoft Outlook 2007 SP3, 2010, or 2013, each also in both 32-bit and 64-bit editions; Microsoft .NET Framework 4 Client Profile and Microsoft Visual Studio 2010 Tools for Office Runtime 4.0. This does not establish support for current Microsoft 365 Apps or modern Windows versions. Before broad deployment, check the actual downloaded package, the Windows and Outlook versions and their respective bitness, positive and negative SPX triggers, and uninstallation on a pilot device. Do not change the unexplained MSI parameters based on guesswork.

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%: recipient of the password.
• %PASSWORD%: password for opening the SPX PDF.
• %ORGANIZATION_NAME%: organisation name entered in the template.
• %SENDER%: sender of the email.
• %REG_LINK%: link for password registration.

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.

Reset restores the default notification. Save customised text beforehand; after resetting, check the subject, message body, and recipient instructions again.

Set validity periods and error notifications

Set the periods and error recipients under Email > Encryption > SPX configuration, not under SPX portal settings:

• Keep unused password for: Validity of a stored password when no SPX message is sent to that recipient. With a setting of three days, for example, the help says it expires at midnight at the end of the third day. This is an inactivity period, not a universal lifetime for every PDF.
• Allow secure reply for: Number of days in which the recipient can reply through the SPX Reply Portal; this setting belongs to the MTA workflow.
• Allow password registration for: Period after which the registration link expires. It is separate from the period for stored passwords.
• Send error notification to: Responsible recipients of SPX error notifications. Error messages also appear in the SMTP log.

Choose periods according to the organisation’s reply requirements and security policy. Test registration, password inactivity, and the reply deadline separately in the pilot. Expiry on the firewall does not prove that an already delivered PDF has been deleted or can no longer be opened.

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.

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.

The selection is under Administration > Admin and user settings > Admin console and end-user interaction > Certificate. The certificate identity in its SAN or CN must match the portal FQDN entered under Hostname, and the complete CA chain must be present on the firewall. Don’t treat a certificate swap as an SPX-only change: verify WebAdmin and the other portals after the swap as well.

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

A Data Control List isn’t a freely written content rule. It is built from Sophos Content Control Lists, or CCLs, for defined data patterns. When adding the list, filter CCLs by Type and Region. Include only the patterns needed for the pilot so an overly broad selection doesn’t trigger SPX delivery unnecessarily.

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 and select that exact list under Data control list.
3. Set Data control list action to Accept with SPX and select the intended SPX template. Accept delivers without SPX; Drop discards the message without notifying the sender.
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.

For MTA mode, the help explicitly requires a configured SMTP route and scan policy and template selection under Domains and routing target or Data control list. It gives example.com as a dummy domain if no protected domain is to be specified. This is a documentation example, not a production mail domain or blanket permission for relay or routing. The policy assignment and both test cases must still be correct in this special case. The general description of the default template is not evidence that MTA can operate without an SMTP policy. None disables only the default path, not an SPX assignment in a policy.

Automate SPX via the XML API

For recurring changes, first record the mail mode, existing templates and their policy or default assignments. The XML references for SFOS 22 and 23 distinguish between Legacy and MTA objects; identical field names do not make their payloads interchangeable. The following information explains the documented contract, but is neither an executable write request nor evidence of a lab test. Source access restrictions, a least-privilege service account, TLS verification, an explicit operation, backups and evaluation of XML rather than HTTP status are covered in Securely restrict XML API access and check responses. Before writing, confirm the complete object contract in API help for the installed build; do not bridge unresolved contradictions with a guessed payload.

Global configuration: separate Legacy and MTA

Legacy: The documented example nests SPXConfiguration twice: an outer SPXConfiguration containing another SPXConfiguration. The inner element contains SPXGlobalTemplate with DefaultSPXTemplate; alongside it are HostName, AllowedNetworks with repeatable Network entries, Port, KeepUnusedPassFor, AllowPassRegistrationFor and SendNotifcationErrorTo. Do not remove the double nesting as a presumed typo or use the example as a general MTA schema.

MTA: The separate object is named MTASPXConfiguration. Its example directly contains SPXGlobalTemplate with DefaultSPXTemplate, along with the hostname, port, password validity periods and error notification, without the double Legacy nesting. For both contracts, the parameter table lists Network, DefaultSPXTemplate and HostName as optional string arrays; this does not confirm that an arbitrarily constructed array structure is valid. Cross-check the portal FQDN and allowed sources against the portal and certificate checks described above. The MTA example value None for HostName does not establish a securely disabled state.

The required parameters are KeepUnusedPassFor (a number of days documented as a string, default 30), AllowPassRegistrationFor (an integer number of days, default 10), Port (integer, default 8094, range 1025 to 65535) and SendNotifcationErrorTo. The spelling SendNotifcationErrorTo remains unchanged despite the missing letter. The allowed tokens are SenderOnly and Nobody; however, the Legacy example and the displayed default specify Sender Only. Do not silently normalise this discrepancy or infer that either value is a tested XML value from the display alone. If the contract for the deployed build remains unresolved, stop the write job.

Only the MTA table additionally lists AllowSecureReplyfor as a required field for the reply period (a string number of days, default 30). This very field is missing from the MTA example. The example therefore does not provide complete evidence of a production-ready request; do not omit the reply period without checking or invent a spelling with different capitalisation. The global template, password inactivity, registration and reply period remain separate decisions; none replaces the SMTP policy assignment.

The following XML status mappings are documented for Update SPX Configuration in the Legacy contract:

By contrast, the MTA contract for the same operation specifies 200 with Operation Successful. and 500 with Operation Fail.. Do not present the Legacy code 541 as a documented MTA response. For the Legacy mapping 541, first check actual port usage and the stored portal port rather than rerunning the job unchanged or altering SMTP TLS.

Templates: protect identity, values and notifications

SPXTemplates is documented for Legacy and MTASPXTemplates for MTA. Name is the required unique template identity, with a maximum of 255 characters, and must be matched exactly against the existing object before updating or deleting it. Description and OrganizationName are optional strings; OrganizationName also has a maximum of 255. New description text is no reason to blindly recreate an object with the same name.

Both contracts require PDFEncryption, PageSize and PasswordType. The exact selectable values are:

• PDFEncryption: AES/128 or AES/256.
• PageSize: A/4, Letter or Legal. The displayed default A4 is not the documented selection token A/4.
• PasswordType: SpecifiedBySender, GeneratedOneTimePasswordForEveryEmail, GeneratedAndStoredForRecipient or SpecifiedByRecipient. The displayed default Specified by sender is not a recommendation for an XML token.

NotificationSubject, NotificationBody and InstructionsForRecipient are optional strings. According to the contract, the two notification fields apply only to password models with generated or recipient-registered passwords, not to SpecifiedBySender. Only the MTA template adds SPXReplyPortal and IncludeOriginalBodyIntoReply: both are optional, with default Disabled and allowed values Disabled or Enable. The example Enable/Disabled denotes a choice, not a single value to send. Do not confuse the Reply Portal requirement in the MTA GUI workflow described above with the optional API field and its default.

Notification text is localised, while technical placeholders are retained unchanged. The API examples additionally show %CURRENT_RECIPIENT% and, in the subject, %%ENVELOPE_TO%% or %%ORGANIZATION_NAME%%; do not automatically rewrite these as the variables enclosed in single percent signs listed above. Before making a change, back up the actual stored template and check variable resolution with a new test message. Stock HTML, historical PDF reader instructions and example passwords from the reference are not a required template for custom notifications. HTML, quotation marks and line breaks must be serialised in a controlled manner and checked after saving. Likewise, do not adopt the |n visible in the MTA example as a universal escaping method without build-specific confirmation.

The documented mappings are identical for Legacy and MTA templates:

The Message.* identifiers remain unresolved message keys from the reference, not verified runtime text. For 502, check the exact identity and existing content; do not automatically switch from Add to Update. For Update-541, investigate the actual spam, Data Control and SPX assignments without inferring a universal conflict mechanism from the symbol. For Delete-504, first clarify the references in policies and the global configuration; the rollback sequence described below remains mandatory. Before each retry, reconcile the response with the actual stored state, and check the target object even after 200. Operational effects are validated only by new positive and negative test emails together with password and reply tests.

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.

Start correlation in Email > Mail logs. Under Reason, SPX encryption identifies SPX-encrypted messages and SPX failure identifies undelivered SPX messages; under Result, filter further by values such as Delivered, Dropped, or Quarantined. Match sender, recipient, subject, and time window to the test note. For detail errors, continue with Log Viewer and the MTA files smtpd_main.log, smtpd_error.log, and smtpd_panic.log. Sophos Firewall services and logs explains access and additional log files.

SPX failure isn’t another name for SMTP quarantine. A message appears under Email > SMTP quarantine only when a spam, malware, unscannable, DKIM, or other policy action actually quarantines it. During testing, don’t simply release a quarantined message before documenting the reason and triggering policy; doing so can confuse a scan or policy failure with an SPX failure.

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 selected Data control list, Data control list action: Accept with SPX, and its SPX template. 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.

Mail logs show SPX failure

In Email > Mail logs, narrow the affected row by time, sender, recipient, and subject, then confirm Reason: SPX failure. Correlate the displayed error with smtpd_main.log, smtpd_error.log, and, for severe process errors, smtpd_panic.log at the same time. Only then change the password model, template, delivery, or portal path. If Result is Quarantined instead, investigate the triggering scan or policy action under Email > SMTP quarantine.

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.

For a targeted reset, enter the affected recipient’s email address under Email > Encryption > SPX password reset and check it before triggering the reset. Coordinate the reset and secure delivery of the new password with sender and recipient, then open a new SPX test message. This does not promise that older PDFs can be opened with the new password.

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. For a Data Control trigger, restore Data control list action in the SMTP policy from Accept with SPX to its documented previous action.
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. Roll back separately changed SMTP TLS requirements only against their own recorded 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, central portal certificate, port, and Allowed Networks are tightly scoped; SMTP TLS is documented separately.
• The domain, Data Control, or default assignment is unambiguous.
• Positive, negative, password, PDF, and reply tests have passed.
• The SPX encryption and SPX failure Mail log filters and the MTA logs can be correlated with the test message; quarantine actions are distinguished from them.
• HA failover and node-local logs are covered by the operating procedure.
• The owner, expiry periods, review date, and rollback are documented.

FAQ