Skip to content
Avanet

Sophos Email: deploy the Outlook encryption add-in

Sophos Email

The Sophos Outlook add-in gives senders an Encrypt action in Outlook. It doesn’t encrypt the message itself; it marks the message for Sophos Email to process. The applicable Secure Message policy still determines whether and how the message is encrypted.

In brief: prove compatibility and policy scope first, obtain the add-in from Sophos Fusion (formerly Sophos Central) with Download Outlook Add-in, deploy it to a small group through the supported Microsoft method, and test the full path to a controlled external recipient. Keep sideloading limited to proof-of-concept testing.

Check prerequisites and boundaries

Before downloading, record the tenant, target group, mail environment, Outlook clients, and owner of the Microsoft deployment. Sophos lists these compatible combinations:

  • Microsoft 365 Business with Exchange Online;
  • Exchange Server 2013 or later; Exchange Server 2013 API version 1.4 or earlier isn’t supported;
  • Outlook for Windows 2013 or later;
  • Outlook for Mac 2016;
  • Outlook on the web with Microsoft 365 only.

Non-Microsoft providers such as Gmail and other POP or IMAP accounts aren’t supported. Outlook being able to display an account doesn’t prove support. Review current Microsoft compatibility and deployment documentation before each rollout; follow Microsoft’s process if it differs.

An outbound Secure Message policy must apply to the target users and use Push Encryption or Portal Encryption. Record its scope, order, and original state. The add-in doesn’t administer portal branding, recipient sign-in, expiry or recall, and it doesn’t manage S/MIME certificates. Those remain separate operational tasks.

Download the add-in from Sophos Fusion

  1. Open Global Settings in Sophos Fusion.
  2. Go to Products and Services > Email and select Encryption.
  3. Click Download Outlook Add-in.
  4. Store the downloaded add-in file unchanged in an access-controlled location for Microsoft deployment.

Record the download time, responsible administrator, and intended deployment scope. Don’t rewrite the file or wrap it in an undocumented installer.

Perform a controlled deployment

For a proof of concept, one user may install the add-in by sideloading it. Sideloading is for testing, not production rollout. It confirms that the package can load in the intended user, mailbox, and client context.

Before centralized rollout, use Microsoft’s compatibility process to determine whether Centralized Deployment works in the organization. Then use Microsoft’s current Microsoft 365 admin center procedure to assign the add-in to the pilot group only. Staged assignment prevents a package or policy problem from immediately affecting every sender.

For on-premises Exchange without a Microsoft 365 connection, the Exchange administrator installs the organizational add-in through the Exchange Admin Center. Don’t mix the Microsoft 365 and on-premises Exchange methods. Allow for the replication reported by Microsoft, then inspect the add-in in every client type included in the pilot.

Explain the sender workflow

The user composes a message and clicks Encrypt in Outlook before sending. The selected action must remain visibly active. The user can deselect Encrypt at any time before sending.

Encrypt isn’t confirmation of successful encryption or delivery. After sending, Sophos Email processes the message according to the matching Secure Message policy. User guidance should therefore state intended recipients, permitted content, expected delivery path, and where to report a missing button or unexpected result.

Accept with a controlled send

Use a pilot sender and a controlled external recipient mailbox, with no confidential data. Test as follows:

  1. Open Outlook and confirm that the Sophos add-in appears without a load error.
  2. Compose an identifiable test message, select Encrypt, and verify its active state before sending.
  3. Send it and record the time, sender, recipient, subject, and Message-ID.
  4. In Sophos Email, verify that the intended Secure Message policy matched this sender and recipient.
  5. At the recipient, open and read the expected Push Encryption or Portal Encryption delivery completely.
  6. In a second draft, select Encrypt, deselect it before sending, and confirm the action is reversible; the draft need not be sent.

Acceptance passes only when add-in, policy match, and recipient outcome agree. An Encrypt button alone isn’t enough. A portal message also doesn’t prove correct add-in deployment if another rule caused encryption.

Troubleshoot methodically

The add-in is missing for some users: check group assignment, Microsoft deployment status, replication time, mailbox account, and client against the support matrix. Then restart Outlook or the web session. Don’t hide a broken central assignment with permanent sideloading.

The add-in is missing for everyone: inspect the package and central deployment state, reassess organizational support for Centralized Deployment, and confirm that an on-premises deployment used the Exchange Admin Center. Fix Microsoft deployment errors on the Microsoft side; downloading the Sophos file again doesn’t correct a bad assignment.

Encrypt appears, but the result isn’t encrypted: confirm that Encrypt was active when sent. Then check direction, user or group scope, rule order, and encryption method on the Secure Message policy that actually matched. It must use Push Encryption or Portal Encryption. Don’t change portal or S/MIME settings to conceal an add-in or policy-scope fault.

Only one client type fails: capture the exact Outlook version, platform, and account type. Outlook on the web is supported here only with Microsoft 365; POP, IMAP, and Gmail remain excluded. Testing a second supported client helps isolate the fault but doesn’t prove that the first client should be supported.

Roll back and remove

If the pilot fails, stop further assignments and remove the pilot group or add-in through the same Microsoft administration route used to deploy it. Remove a sideloaded test add-in from its test account. After replication, verify that Encrypt is no longer offered.

Restore the Secure Message policy only if it was changed in the same approved change. Leave it intact if other encryption workflows use it. Removing the add-in neither recalls nor decrypts messages already sent. Portal recall, portal branding, and S/MIME key management are explicitly outside this rollback.

For escalation, collect tenant and deployment type, target group, package and assignment status, mail environment, Outlook version and platform, time, sender and recipient, Message-ID, and the effective policy and method. Don’t put confidential message content or credentials in the diagnostic record.