Skip to content
Avanet

Sophos Email: deploy and repair the Report to Sophos Outlook add-in

Sophos Email

The Report to Sophos Outlook add-in is used with Sophos Email and Sophos Phish Threat. This runbook remains assigned to the Sophos Email reporting path and also covers the add-in’s shared access error. Phish Threat campaign logic and its reporting don’t belong to Sophos Email.

It is also not the Sophos Email encryption add-in. That add-in provides an Encrypt action while composing a message and works with a Secure Message policy. The Outlook encryption add-in guide covers deployment and testing of that separate product. The add-in described here instead lets a user report an existing message with Report to Sophos.

Distinguish the Sophos Email and Phish Threat reporting paths

For an ordinary suspicious or unwanted message, the add-in sends the report to the reporting destinations configured for the organization; depending on the configuration, it also sends a copy to SophosLabs for analysis. A Phish Threat license isn’t required for this spam-reporting path.

If the add-in instead recognizes a simulated Phish Threat campaign message, a reported message is recorded as Reported Email in the campaign results and the user receives immediate positive feedback in Outlook. For installation, reporting-destination configuration, upgrades, the end-user workflow, and checking campaign results, use the Phish Threat runbook for the Sophos Outlook add-in. If Report to Sophos already fails with the access error described below in either reporting path, use the shared troubleshooting in this runbook.

Define prerequisites and a safe test

You need a valid Sophos Email or Sophos Phish Threat subscription, Sophos Fusion (formerly Sophos Central) access to check licensing and add-in deployment status, and—for organization-wide issues—administrator access to the Microsoft 365 Admin Center or Exchange Admin Center. The reporting path distinguished above determines which subscription is required.

Before changing anything, record the tenant, affected users, device, operating system, exact Outlook version and variant, time, network path, and symptom. Use an identifiable, non-confidential message approved for submission to Sophos for final testing.

Determine the impact scope first

  1. Have the same user retry after completely restarting Outlook.
  2. Where possible, have that user test the same function in Outlook on the Web (OWA) or New Outlook.
  3. Have a second user test on another device and, where practical, through another approved network path.
  4. Classify the issue as one user/device, multiple users/devices, or every user in the organization.

If the add-in loads but clicking Report displays We're sorry, we couldn't access report to Sophos. Make sure you have a network connection. If the problem continues, please try again later., follow the matching branch below. If OWA or New Outlook works while Classic Outlook fails, initially treat this as a local client or web-engine issue rather than a missing tenant-wide deployment.

Check deployment and Outlook variant

For an initial Microsoft 365 deployment:

  1. A Microsoft 365 administrator opens Settings > Integrated Apps in the Microsoft 365 Admin Center and starts the workflow for adding an app.
  2. Search the available app catalog for Report to Sophos and select that listing. Review its publisher, details, and requested permissions before continuing; don’t substitute a similarly named reporting or encryption add-in.
  3. At the assignment step, choose the available scope that matches the change: the whole organization, selected users or groups, or only the administrator for a pilot. Start with a small test group when change control requires staged rollout.
  4. Review and confirm the deployment. Microsoft can vary the labels in this workflow, so use the page’s completion confirmation rather than relying on a particular final button name.
  5. Return to Settings > Integrated Apps, open the deployed entry, and verify its deployment state and assigned users or groups. After propagation, have an assigned user restart Outlook, confirm that Report to Sophos is available on a message, and complete the approved reporting test below.

A new or changed deployment can take up to 24 hours to propagate. Don’t rule out a correct assignment until that window has passed; if needed, update or redeploy the add-in through the same administrative route.

Classic Outlook 2013, 2016, and 2019 uses an Internet Explorer-based web engine for add-ins, which can cause connection failures. For this failure path, upgrade to Outlook 2021 or Microsoft 365. OWA and New Outlook are useful comparison tests and temporary workarounds, but don’t prove that the failing Classic client has been repaired. On macOS, keep macOS and Outlook for Mac current.

Repair one Windows user or device

Change one cause at a time and retest after each step:

  1. If Internet Explorer is installed, open Internet Properties. Under Security, make sure Protected Mode is enabled for Internet and Restricted sites, and that Internet Explorer isn’t in compatibility mode.
  2. Under Security > Trusted sites > Sites, add https://*.sophos.com, confirm the dialogs, and completely restart Outlook.
  3. Close Outlook completely. Delete the contents of %LOCALAPPDATA%\Microsoft\Office\16.0\Wef\, reopen Outlook, and test.
  4. On Windows Server only, open Server Manager > Local Server, set IE Enhanced Security Configuration to Off for administrators, restart Outlook, and test. Don’t apply this exception to ordinary Windows endpoints.

These actions reset local web-engine and cache state. They don’t replace a missing user assignment or unblock a network connection.

Check multiple Windows users or devices

When multiple devices are affected, have the network team inspect the proxy, firewall, Conditional Access, and TLS/SSL inspection. TLS inspection must not apply to *.sophos.com or *.hydra.sophos.com. Keep exclusions as narrow as possible and test through the normal corporate path afterward.

The affected context must be able to reach:

  • https://cloud-assets.sophos.com — a blank page is the expected response;
  • https://phish-outlook.cloudstation.*.prod.hydra.sophos.com;
  • https://graph.microsoft.com — required for Azure AD/Entra ID and/or SSO authentication.

For AD/SSO users, also confirm that Entra ID issues the user token and that proxy or Conditional Access rules don’t block token requests from domain-joined computers. Implement wildcards in the form required by the network control; don’t replace them with an invented fixed region.

Handle an organization-wide failure

If every user is affected, first inspect deployment status, target scope, and the latest change in Settings > Integrated Apps. Give a new assignment up to 24 hours to replicate. After that, the administrator can update the existing deployment or redeploy the add-in in a controlled manner and test with a small user group first.

In parallel, check whether the same failure occurs in OWA and New Outlook. If those variants also fail after assignment and propagation are confirmed, treat the incident as a network, authentication, or service issue and collect evidence instead of clearing local caches on every device.

Clear macOS cache and sign-in tokens

  1. Close Outlook.
  2. Delete cached add-in data under ~/Library/Containers/com.microsoft.Outlook/Data/Library/Caches/.
  3. Reopen Outlook and test.
  4. If the error remains, open Keychain Access, search for adal or office, and remove only stale tokens. Then authenticate again.
  5. Confirm that macOS and Outlook for Mac are current; earlier versions can have WebKit rendering issues.

Outlook for Mac doesn’t provide Recover Deleted Items for this workflow. If a reported message must be recovered, use OWA or the browser. Clear caches and tokens only for the affected user, not tenant-wide.

Validate the result and escalate

Restart Outlook completely. Have the user open the approved test message, click Report to Sophos, confirm the prompt with Yes, and verify that reporting completes without the stated access error. A loaded add-in alone isn’t a successful test. If using a workaround, record that only OWA or New Outlook works and that Classic Outlook remains faulty.

Don’t use an active Phish Threat campaign message for the technical function test, because reporting it changes the campaign results. If the simulation path must be tested explicitly, the campaign owner coordinates the test and also checks the immediate positive feedback in Outlook and that the reported simulated message is recorded as Reported Email in the campaign results. Optionally, check this under Campaigns > [Campaign] > By User. A successful spam-reporting test doesn’t prove that this campaign path works, and vice versa.

To correlate the test message with Sophos Email processing or investigate a separate delivery result, follow the Message History troubleshooting guide.

For escalation, collect the tenant, user scope, devices and platforms, exact Outlook version and variant, time with time zone, deployment and assignment state, completion of the 24-hour window, results in Classic Outlook, New Outlook, and OWA, affected network path, TLS inspection state, reachability of all three endpoints, and caches or tokens already cleared. Don’t include confidential messages, credentials, or complete tokens in the diagnostic record.