Skip to content
Avanet

Sophos Email Mailflow: systematically repair Microsoft 365

Sophos Email

If Sophos Email Mailflow fails in Microsoft 365, do not delete connectors or transport rules on suspicion. First check the domain status in Sophos Fusion, run Run a Quick Test, and compare the same message in Microsoft Message Trace and Sophos Message History. Only then repair the affected path.

Quick path: Connected with a green check means that the Mailflow connection is up. Not Connected with a red cross calls for a connection or permission check. An exclamation mark with View Details indicates a rule or connector changed directly in Microsoft 365. For a 552 error, first look for duplicate Sophos and Microsoft headers: they often show that a signature platform routed the message through Sophos again.

This runbook applies only to Sophos Email in Mailflow mode (MFR). MX records remain pointed at Microsoft 365, while Microsoft transport rules and connectors send messages to Sophos and back. In Gateway mode, MX records point to Sophos, so diagnosis and removal follow a different process. Do not apply Gateway instructions to a Mailflow domain. For deployment and planned migration, see Set up Sophos Email Mailflow for Microsoft 365.

Prerequisites and a safe starting point

You need administrative access to Sophos Fusion and an account that can grant consent for the Sophos Email app and the required Exchange Online mail-flow permissions. The Microsoft 365 domains must be eligible for Mailflow, and the required users and groups must be synchronized.

Before any change, record:

  • affected domain, sender, recipient, UTC time, Internet Message-ID, and full headers;
  • current Mailflow Connection and, if applicable, Post Delivery status;
  • names, enabled state, and priority of Sophos, signature-service, and other transport rules and connectors;
  • results from Microsoft Message Trace and Sophos Message History;
  • last known working configuration and the owner of each change.

Change only one factor per test. Do not remove the Sophos-created xgeconnector.com domain, because this can interrupt mail flow and processing. Do not delete an apparently orphaned Sophos connector until its domain assignment and the rollback path are documented.

1. Check the connection and domain status

  1. In Sophos Fusion, open Global Settings.
  2. Select Products and Services > Email > M365 Mailflow Domains.
  3. Check the affected domain:
    • green check, Connected: the connection exists;
    • red cross, Not Connected: hover and click the green check to reconnect;
    • exclamation mark, View Details: investigate a Microsoft 365 change.
  4. Click the domain’s test icon. Under Run a Quick Test, enter a controlled recipient address and select Proceed. The test can take a few minutes.
  5. If it fails, first use Run The Test Again. If the failure remains, select Reconnect.

A successful Quick Test removes the exclamation mark and restores the green check. This verifies the connection, not end-to-end delivery. Next send one controlled inbound and one outbound message and trace both in Microsoft Message Trace and Sophos Message History through to the final recipient.

If Reconnect cannot create rules or connectors

Confirm that the Sophos Mailflow application has the required role-based assignments in the Microsoft 365 tenant. In particular, the necessary Exchange Online mail-flow permissions must be available through the Exchange administrator role. Automated repair requires valid consent and these permissions.

If Reconnect still fails, do not keep deleting objects manually. Preserve the status, Quick Test result, rule and connector names, and Message-ID, then escalate to Sophos Support; manual cleanup may be required.

2. Handle an alert about changed Mailflow objects

Sophos monitors disabling, deletion, and modification of transport rules and connectors required by Mailflow. Microsoft 365 auditing must be enabled, and the Sophos Email app must have the organization permission Read activity data. For domains configured before April 12, 2022, grant this additional permission by disconnecting and reconnecting the domain; later configurations should already have it.

Alerts have High, Medium, and Low severity. All appear in Sophos Fusion. Only High and Medium also generate email to admins and super admins and change the domain status. Under Alerts, group alerts, open Mail Flow Rules, and use View Details to see the domain, time, object, and change.

  • Known distribution-list rename: Confirm that the new group name has synchronized to Sophos Fusion, then update and save it in the M365 domain settings.
  • Known intentional change: Document it and run Run a Quick Test. Keep it only if the test succeeds.
  • Unknown or unintended change: Identify the Microsoft 365 audit event and owner. Revert an understood incorrect change in Microsoft 365 and run the Quick Test. If the repair is unclear or the test fails, use Reconnect so Sophos can recreate or enable missing or disabled objects.

An alert alone does not prove that mail flow is interrupted. Conversely, a planned change is not safe merely because it is known: Quick Test and delivery tests decide.

3. Correct SPF failures after the return to Microsoft 365

In Mailflow, outbound messages travel from Microsoft 365 to Sophos and back to Microsoft 365. Microsoft can therefore fail SPF when the regional Sophos sender is not authorized in the domain’s SPF record.

An existing record may be:

v=spf1 include:spf.protection.outlook.com -all

Add the include domain published for your Sophos Fusion data region:

v=spf1 include:spf.protection.outlook.com include:<sophos-spf-domain> -all

<sophos-spf-domain> is a placeholder, not a value to publish. Obtain the current regional value from Sophos Email domain information, keep one SPF TXT record per domain, and do not change the final mechanism without review. After DNS propagation, verify the published TXT value and send an outbound test. SPF must pass for the expected route in the received headers.

4. Correct forwarding and Microsoft DLP

Externally auto-forwarded message is rejected

For external automatic forwarding, Microsoft 365 rewrites the envelope-from address (P1 From) using SRS. If Header-From remains an external domain not configured in Sophos Email, Sophos can reject the outbound message because that Header-From domain is not configured. Sophos does not broadly relay externally originated mail because that would create an open-relay-like risk and damage sender reputation.

  1. In Microsoft 365 Security Center, open Policies & rules > Threat policies > Rules > Enhanced filtering.
  2. Select the connector that permits inbound messages from Sophos Email.
  3. Enable Automatically detect and skip the last IP address and apply it to the organization.
  4. Configure the affected outbound forwarding to use a local mailbox in the protected domain as sender.
  5. Repeat the test with the same original sender and destination; compare headers, Message Trace, and Message History.

Do not solve this by adding arbitrary external domains to Sophos or creating a broad relay exception.

Microsoft DLP sends duplicate notifications

If a Microsoft DLP rule fires on both Mailflow passes, exclude the documented Sophos Email sender IP addresses specifically from that Microsoft rule:

  1. Sign in as a Microsoft 365 administrator at the Microsoft Purview DLP portal.
  2. Edit the affected policy and triggering rule under Advanced DLP rules > Customize advanced DLP rules.
  3. Select Add exception > Except if sender IP address is and enter only the current regional Sophos IP addresses from the domain information linked above.
  4. Save and repeat for each affected DLP rule.
  5. Use a controlled message to confirm that the intended DLP evaluation remains active but produces only one notification.

Do not broaden the exception to unnecessary address ranges. DLP then remains effective for other sender paths.

5. Investigate error 552 and signature services

The typical NDR is:

552 5.6.0 Headers too large (32768 max)

First inspect the complete headers. Duplicate groups such as X-Sophos-Antispam, X-LASED-Hits, X-Microsoft-Antispam-Message-Info, or X-Microsoft-Antispam-Message-Info-Original indicate repeated processing. With CodeTwo or Exclaimer, it often follows this incorrect route:

Microsoft 365 > Sophos > Microsoft 365 > signature service > Microsoft 365 > Sophos > Microsoft 365 > recipient

The permanent target route processes the message once in each external service:

Microsoft 365 > signature service > Microsoft 365 > Sophos > recipient

Review the Microsoft 365 connectors and rules for the signature service and Sophos. The CodeTwo or Exclaimer path must run before the Sophos outbound path; remove or constrain overlapping rules that send returned mail to Sophos again. Configure the third-party rule according to that vendor’s current best practice. Then use Message Trace and headers to prove exactly one signature-service pass and one Sophos pass.

Limited workaround when no routing loop exists

If there is no duplicate route but a large Microsoft diagnostic header still exceeds the limit, create a rule in Exchange Admin Center under Mail flow > Rules:

  • Apply this rule if: A message header > includes any of these words; header X-Sophos-Email-ID, included word True.
  • Do the following: Modify the message properties > remove a message header; header X-Microsoft-Exchange-Diagnostics-untrusted.
  • Leave other settings at their defaults. Place the rule after the Sophos Email prefilter and redirect rules. With their default priorities 0, 1, and 2, use priority 3.

Export or document the rule order first. Afterwards test one affected and one normal message. This rule removes header data and does not replace loop correction. Removing large Microsoft headers in Sophos with the regular expression .* is also only a temporary workaround; if Sophos headers are duplicated, repair the routing instead.

Expected behavior: sensitivity labels appear twice

For outbound messages, Microsoft 365 can apply the same sensitivity label twice. It sends the message to Sophos for scanning and, after return, to the recipient; label processing occurs on both tenant passes. If Message Trace shows exactly that intended route without a loop, the duplicate label is expected Mailflow behavior and does not prove a second Sophos scan. Do not change connectors solely because two labels appear.

Validation, rollback, and escalation

A repair is complete only when:

  • the domain shows Connected under M365 Mailflow Domains and Quick Test succeeds;
  • one inbound and one outbound control message agree in Microsoft Message Trace and Sophos Message History and are delivered;
  • headers show only the expected number of Sophos, Microsoft, and signature-service passes;
  • SPF passes and forwarding or DLP tests produce exactly the expected result;
  • no new High or Medium Mailflow alerts appear.

For a deliberate manual rollback, disconnect the domain in M365 Mailflow Domains by clicking the cross beside Connected. Sophos then removes the apps, connectors, and rules created for that domain; this can take a few minutes. Before reconnecting, verify removal of the domain-specific Sophos objects under App registrations in Microsoft Entra Admin Center and under Mail flow > Rules and Mail flow > Connectors in Exchange Admin Center. Then reconnect with valid consent.

Distinguish a Gateway RBL block before Mailflow detection

If an inbound message is rejected, the Sophos Gateway logs show an RBL rejection, but Sophos Message History has no corresponding Mailflow event, the still-active Gateway connection may have applied its real-time block list before Sophos could detect the Mailflow connection and forward the message. Correlate the same message and UTC timestamp across the Gateway logs, Microsoft Message Trace, and Mailflow Message History. In this pattern, the missing Mailflow event is not proof that the Mailflow connector failed.

Do not respond by broadly bypassing or globally disabling an RBL. Do not prolong parallel processing either: once inbound and outbound Mailflow are validated, promptly remove the old Gateway connection according to the migration plan.

This is a controlled repair step, not ad hoc cleanup. For a production domain, define a maintenance window, alternative route, and abort criterion first. During a Gateway-to-Mailflow migration, retain the documented Gateway path only as a planned rollback; Gateway and Mailflow must not route the same production domain through Sophos at the same time, or duplicate scanning and routing loops can result. If objects remain, ownership is unclear, or Reconnect fails with correct permissions, stop manual changes and give Sophos Support the domain, Message-IDs, UTC times, headers, traces, Quick Test result, and object inventory.