Skip to content
Avanet

Set up Sophos Email Gateway with Microsoft 365

Sophos Email

With Sophos Gateway, the public MX record points to Sophos. Sophos scans inbound messages and delivers them to Exchange Online through a restricted partner connector. For outbound mail, a second connector sends messages from Microsoft 365 to the Sophos smart host.

Safe quick path: First document the domain, recipients, Microsoft destination and rollback route. Prepare the inbound connector with TLS and IP restrictions and then its rules. Create and successfully validate the outbound connector. Only then cut over MX and outbound routing. Change SPF to match the route that is actually sending, not a future state.

This procedure is for manually configured Gateway connectors under Gateway Domains. Sophos Mailflow is a different architecture in which Sophos manages applications, connectors and mail flow rules through Microsoft APIs. Never combine both methods for one domain; doing so can cause duplicate scanning and loops.

Prepare prerequisites and values

You need Exchange administrator rights, DNS access, a Sophos Email license and a planned Gateway domain. Before making changes, export or record the current MX, SPF, connectors and mail flow rules, including their priority and status.

In Sophos Fusion, open Global Settings > Products and Services > Email > Gateway Domains and add or verify:

  • your email domain;
  • the domain’s expected MX FQDN shown under Domains in Microsoft 365 as the delivery destination;
  • the SMTP port actually used;
  • the domain-specific TXT value from Verify Domain Ownership;
  • every protected mailbox and alias.

Keep the value sources separate: the delivery-destination FQDN comes from Domains in your Microsoft 365 tenant, and Verify Domain Ownership generates the TXT value for that domain. Sophos publishes the changing regional values in its delivery-IP table, MX table, and SPF table. Copy the Outbound Relay Host from the domain’s external dependencies in Sophos Fusion. Never use a value from another region or an example in production. New Gateway trial accounts can have outbound routing disabled by default; ask your Sophos partner or sales representative to enable it when required.

1. Restrict the inbound path before changing MX

Create the partner connector

In Exchange admin center > Mail flow > Connectors, create a connector with these values:

  1. From: Partner organization; To: Office 365.
  2. A clear name such as Sophos Email Inbound Connector.
  3. Use the sender’s domain, with * as the sender domain.
  4. Select Reject email messages if they aren’t sent over TLS.
  5. Select Reject email messages if they aren’t sent from within this IP address range and enter only the current Sophos Email delivery IP addresses for your Central region.
  6. Review and save the settings. Enable the connector when the remaining protections are ready.

Also add the same current Sophos delivery IPs to the default connection filter policy in the Microsoft 365 Defender portal. This entry identifies the Sophos sources to the filter; an IP Allow List does not close a direct delivery route. The enabled partner connector enforces the accepted inbound path because it applies to sender domain *, requires TLS, and restricts delivery to those Sophos IPs.

Configure Enhanced Filtering and the EOP bypass

Enable Enhanced Filtering for Connectors (also called skip listing) on this exact inbound partner connector. Without it, Microsoft 365 can misclassify the original sender behind Sophos.

Then create this transport rule under Mail flow > Rules:

  1. Name: Sophos Email EOP Bypass.
  2. Apply this rule if: Apply to all messages.
  3. Do the following: Modify the message properties > Set the spam confidence level (SCL) to -1.
  4. Add no exception; use Enforce mode and Severity: Low.
  5. Save and enable the rule.

This broad SCL rule is acceptable only when MX plus the TLS and IP restrictions ensure that internet mail arrives after Sophos scanning. If any direct or third-party inbound path remains, stop the cutover and close that path first.

2. Create the outbound connector through Sophos

In Gateway Domains, select the domain, set Direction to Inbound and Outbound, choose Microsoft Office 365 under Outbound Gateway, and save. Under Configure External Dependencies > Outbound Settings, copy the displayed Outbound Relay Host.

In Exchange admin center > Mail flow > Connectors, create:

  1. From: Office 365; To: Partner organization.
  2. A clear name such as Sophos Email Outbound Connector, with Turn it on selected.
  3. Only when email messages are sent to these domains, using * when all external mail must pass through Sophos.
  4. Route email through these smart hosts, using the exact Outbound Relay Host copied above.
  5. Always use Transport Layer Security (TLS) to secure the connection and the documented option Any digital certificate, including self-signed certificates.
  6. Enter a recipient in an external domain and run Validate. Save only after validation succeeds.

Disable or remove other outbound connectors only after the Sophos connector validates. Do not disable special-purpose routes such as archiving without reviewing their scope and priority. Changes can take time to propagate.

For Microsoft 365 GCC High, do not use Sophos’s standard Microsoft Office 365 gateway selection if outbound messages are rejected. Select Custom Gateway and add the required subnets from Microsoft’s current GCC High Exchange Online endpoints. Do not copy IP ranges from an old list.

3. Cut over DNS and routing under control

Lower DNS TTL well before the maintenance window and record the original values. Use this order:

  1. Verify Enhanced Filtering and the connection-filter entry. Enable the inbound partner connector first and confirm that sender domain *, TLS, and the Sophos delivery-IP restriction are active; then enable the SCL rule immediately before the MX change.
  2. Change the public MX records to the current names in the Sophos regional MX table. Send a uniquely identifiable message from an external account to a protected mailbox and confirm that exact message in both Microsoft 365 Message Trace and Sophos Message History.
  3. Validate the Sophos outbound connector while preserving the documented previous connector for rollback. After validation, deliberately set production routing: keep the Sophos connector enabled with recipient scope * and disable every overlapping standard outbound connector. Review special-purpose routes such as archiving separately.
  4. Only after that connector state/scope switch, send a uniquely identifiable message from Microsoft 365 to a controlled external address. Confirm that exact message in Microsoft 365 Message Trace and in the outbound view of Sophos Message History. Do not accept a test sent before the switch as proof of the Sophos route.

Publish one SPF TXT record for each domain. While Microsoft 365 and Sophos are both demonstrably sending, add the current regional Sophos include to the existing record. Once only Sophos sends, the Microsoft include can be removed. Use -all only when every legitimate source is known and routes through Sophos; ~all is less disruptive during a controlled transition. Also verify DKIM signing and alignment after cutover, because a correct transport path alone doesn’t prove sender authentication.

Validate and roll back

For each domain, test inbound and outbound mail with a controlled external address. In Microsoft 365 Message Trace, verify the expected sender, recipient, time, Message-ID, delivery status and final delivery; ordinary Message Trace is not used here as proof of connector or rule processing. In Sophos Fusion, open Reports > Message History, inspect inbound and outbound directions, and match those details to the exact same test messages. Cutover is complete only after both systems contain each post-switch test.

If mail is undeliverable or loops, use the prepared rollback rather than adding more rules:

  1. For outbound mail, re-enable the previous working connector, then disable the Sophos outbound connector before sending any rollback test. Confirm external delivery only after this connector-state transition.
  2. For inbound mail, first disable the broad Sophos-only SCL rule, disable the Sophos-IP-restricted inbound connector, and remove the Sophos entries from the connection filter. Only then restore the original Microsoft MX. Account for DNS propagation: verify the authoritative MX response and repeat controlled external delivery tests until they use the restored route.
  3. Change SPF only after the real sending path has changed back.
  4. Delete nothing until DNS propagation, queues and both traces have been checked.

Troubleshoot by symptom

  • Inbound appears only in Sophos: Check the destination FQDN, SMTP port, mailbox inventory, current delivery IPs and partner-connector TLS negotiation.
  • Inbound reaches Microsoft directly: Check MX propagation and alternate MX or forwarding paths. Never let the SCL rule conceal an unprotected direct route.
  • Outbound bypasses Sophos: Check connector scope *, status, competing connectors and precedence.
  • Connector validation fails: Copy the relay host again from Sophos Fusion, check TLS settings and use a genuinely external test recipient.
  • SPF fails: Inventory real senders and check for multiple SPF records, the wrong regional include or premature use of -all.
  • GCC High mail is rejected: Check Custom Gateway and the currently published GCC High Exchange Online subnets.
  • Mail loops or is scanned twice: Review Gateway and API-managed Mailflow connectors together with old smart hosts, forwarding and mail flow rule priorities. Disable the last enabled path and retest in both traces.

For escalation, collect timestamps, sender, recipient, Message-ID, connector names, rule priorities and matching entries from Message Trace and Message History. This allows routing to be investigated without weakening protection through a broad exception.