Sophos Email: configure portal encryption, branding, and recall

Portal Encryption keeps an encrypted message in a web portal; Push Encryption uses recipient-specific encryption credentials. Branding, access, expiry, and sender status are provisioned from a request and then operated in a separate administration portal. This isn’t an ordinary instant policy toggle.

Boundary: this guide covers the Sophos Email portal. SMTP TLS, S/MIME, deployment of the Sophos Outlook Add-in, and encryption headers originating in Data Control are separate workflows; none configures portal branding or recall.

Prerequisites and baseline

Have a Sophos Email license with the Portal Encryption Add-on, approved portal name/logo/colors/footer, at least one approved administrator, a dedicated system address, and decisions for administrator MFA, recipient sign-in, Message Expiry Period, Sender Notification, recall, and any one-way submission requirement. Prepare external test recipients for Portal Encryption and, if used, Push Encryption.

Record the current state under Global Settings > Products and Services > Email > Encryption. If EMS mode makes the setting unavailable, don’t attempt to bypass that restriction. Record existing administrators, access features, expiry, and notifications. Warn existing recipients before migration: they must register again for the newly branded portal. Previously encrypted mail remains in the old portal during a transition lasting at most 30 days and expires there.

Prepare Portal Branding

Open Encryption, select Download Branding Guidelines, and use the current requirements.
Under Portal Branding, enter the approved Portal Name. Verify the read-only Account Name, Region, and Email Domains; ask Sophos Support to correct errors.
Under Portal Logo > Upload Portal Logo, upload your organization’s own JPEG, PNG, or GIF, no larger than 5 MB, at the fixed 450 × 204 pixels. PNG preserves transparency. Using a logo you don’t own can cause branding to be revoked and encrypted mail to be rejected.
Set Background Color and Foreground Color under Portal Colors, using the picker or RGB, HSL, or hexadecimal values.
Use Preview Branding to check the sign-in page and activation emails, then Confirm Branding.

During form rollout, some tenants show one form instead of separate Portal Branding and Feature Configuration sections. The capabilities are the same; record the variant shown rather than treating the layout as a licensing fault.

Configure administrators and recipient access

Under Feature Configuration:

In Administrators, select only approved people who manage recipient accounts, password resets, and reports. Requested Administrator Access is required for the administration portal.
Enable Multi-factor Authentication for those administrators; it uses a TOTP application.
Set Time Zone for dates in notifications and the portal.
Choose a dedicated System Email Address, such as no-reply@example.com. Never use it to send encrypted mail: doing so can create a mail loop and delivery failure.
Choose only the necessary activation-email languages; one or two avoids a suspicious-looking activation message.
Decide explicitly on Reply All, Social Connector Sign-In to Secure Message web-portal, Passkey Login, Challenge Questions, and Alternate Address.
Set 2-Step Verification via TOTP (Authenticator Apps) to required or Optional. This recipient setting isn’t administrator MFA.

Alternate Address sends recovery to the alternate address supplied during registration. The listed social connectors are Facebook, Google, Windows Live, and Office 365. Enable only recovery and identity methods accepted by your organization.

Set expiry, notifications, and recall

Under Customize sender features, select the approved Message Expiry Period, enable Sender Notification when senders need delivery, collection, and expiry statuses and recall, and add approved support text in Customize Message Template. Record a one-way submission requirement explicitly and verify it against the provisioning confirmation and a test; a branding preview doesn’t prove it is active. Put other requests in Special Instructions, but treat them as configured only after confirmation because Sophos handles them on a best-effort basis.

Recall requires Sender Notification in the branding request. Its email links to status history and makes Recall available to the sender. The product documentation doesn’t state whether or how Recall affects later portal access, reopening, or external copies, so don’t infer any such protection. Message Expiry Period and Recall are separate features: the former sets the configured availability period, while Recall is a sender action.

Effects of Data Control encryption headers

A matching Data Control rule can set or change these headers per message. These overrides don’t change the tenant-level branding request, Message Expiry Period, Sender Notification, or Recall:

X-SophosEmailEncrypt-NoAuth = true|false: true provides a portal-message link that doesn’t require recipient authentication; false doesn’t remove the authentication requirement. This header requires the Portal Encryption Add-on.
X-SophosEmailEncrypt-VerificationCode = true|false: with true, the sender receives the code after the portal-encrypted message is sent and must share it with the recipient. The recipient can generate a replacement code, which is again sent to the sender; false doesn’t request this code. This header also requires the Portal Encryption Add-on.
X-SophosEmailEncrypt-ExpiryPeriod = today|fiveDays|oneWeek|twoWeeks: only these four values are accepted, and the selected period can’t exceed the account maximum. The default maximum is 30 days and may have been changed through custom branding. For Push Encryption, only the registration message expires, not the push-encrypted message or its protected documents.
X-SophosEmailEncrypt-SendNotification = true|false: true notifies the sender when the encrypted message is sent; false doesn’t generate that notification.
X-SophosEmailEncrypt-ReadNotification = true|false: true notifies the sender when the message is read; false doesn’t generate that notification. For Push Encryption, only reading the registration message generates it, not opening a protected document.

For acceptance, set only one exact header value at a time in a narrowly scoped outbound pilot rule and use harmless messages. For Portal Encryption, verify the matched rule and action plus either normal authentication, unauthenticated access, or delivery and replacement of the code through the sender. Check an expiry token against the account maximum; a Push test must demonstrate that only the registration message expires. Test SendNotification=true and ReadNotification=true separately for the expected sender notifications; in the Push test, only reading the registration message must trigger a read notification. A send notification enables neither branding nor Recall.

Submit and provision

Select Submit, then Confirm. The request can’t be edited after submission; changes require Sophos Support. Provisioning typically takes two business days, but that isn’t a guaranteed completion time.

The administrator then receives a portal link and credentials. The temporary password expires after one day. Complete setup promptly or use Forgot Password in the administration portal. Don’t start production until the confirmation and acceptance test succeed.

Test the recipient and sender workflows

Send harmless test messages to a new external recipient and an existing recipient. Confirm:

Sender Notification supplies the expected status link.
Activation uses the correct branding and portal; a new recipient can register.
Sign-in, TOTP or Optional, passkey, social connector, and recovery match the approved design.
Reply and Reply All match configuration.
Delivery, collection, and expiry states have plausible timestamps in the correct Time Zone.
Recall a second harmless message through Recall, then record only the observed status and portal-open behavior. Don’t treat the observation as a product guarantee or draw conclusions about external copies.
Verify Message Expiry Period with a suitable test or report.

Push Encryption from the recipient’s perspective

A push-encrypted delivery contains password-protected attachments and may also include the message body as a PDF. Content that Sophos places in a protected document uses the recipient’s registered Sophos Secure Message password; attachments encrypted before sending remain unchanged. One delivery can combine PDF, Microsoft Office, and ZIP files. The recipient opens them with a compatible document viewer, such as Adobe Reader, and the registered password. After opening the encrypted message in that viewer, the recipient can send a secure reply.

A portal reply can fail a downstream provider’s SPF check because the visible transmission path differs from the original sender. For Google Workspace, either rely on Sophos Email at the mail boundary or use Google’s automatic external-IP detection according to the approved mail-flow design; don’t disable SPF broadly. If TLS 1.2 is unavailable, both enforced and opportunistic TLS mail flows fail. These are transport checks, not branding settings.

Administer recipients and reports

In the administration portal, Credential Management separates the methods:

Document Encryption Passwords for Push Encryption offers Disable User 2-Step Verification, Migrate Encryption Keys, and Expire Encryption Keys. After expiry, the recipient registers a new password for future push-encrypted messages.
Web Portal for Portal Encryption offers Reset Password, Suspend Account, and Disable User 2-Step Verification. Suspension blocks access without deleting the account.

Use Summary reports for exchanges in a period, Policy reports for policy-related information such as messages nearing expiry, and Message reports for particular messages or recipients. Verify address and encryption method before acting; key migration isn’t a portal password reset.

Troubleshoot and roll back safely

Branding absent: check provisioning confirmation and tenant data. Don’t resubmit during normal provisioning; route incorrect read-only data or changes to Sophos Support.
Administrator sign-in fails: check the one-day temporary-password window, Forgot Password, requested Administrator Access, TOTP time, and selected administrator.
Recipient can’t sign in: first distinguish Portal from Push Encryption. In Web Portal, check password, suspension, and 2-step verification; in Document Encryption Passwords, check key migration and expiry.
Recall absent: verify Sender Notification was included in the provisioned request. A delivery notification or policy action alone doesn’t enable it.
Wrong time or state: compare Time Zone, recipient, Message-ID, and status history; use reports as corroboration.
Reply fails SPF or TLS: investigate mail flow and the receiving provider separately. Don’t disable portal security to hide a transport fault.

Because a submitted request can’t be edited directly, rollback is controlled remediation, not an improvised toggle. Pause production rollout, ask Sophos to provision the approved correction, suspend only affected accounts if access is at risk, and use an already approved secure exchange method meanwhile. Never upload another organization’s logo, use the system address as an encrypted sender, or disable MFA broadly. Give support the tenant, region, submission time, confirmation, affected addresses, Message-ID, timestamps, portal status, and sanitized screenshots.