Set up Sophos Email Gateway with Exchange on-premises

With Exchange on-premises, mail flow has two separate paths: inbound messages first reach the regional Sophos MX targets and are then delivered to Exchange. Exchange sends outbound messages through the regional Sophos smart host. Configure and test the two directions separately.

This guide does not apply to Microsoft 365 or the automated connector management provided by Sophos Mailflow. A local Exchange server needs its own receive and send connectors; do not reproduce Microsoft 365 connectors for this purpose.

Quick path: Record the current settings and rollback path, configure the domain in Sophos Fusion for Inbound and Outbound, restrict Exchange reception to the regional Sophos delivery IP addresses, create a Send Connector to the copied Outbound Relay Host, trace both directions, and only then disable old filtering routes.

Prepare inputs and the rollback path

Record these values in the change before making any modification:

the mail domain, such as example.org, and all recipients to be protected;
the publicly reachable Exchange destination as an FQDN or IP address, such as mail.example.org, and the SMTP port actually in use;
the public source IP addresses or CIDR networks used by Exchange for outbound connections, such as the replaceable documentation address 192.0.2.25/32;
the regional Sophos MX targets, delivery IP addresses, Outbound Relay Host, and SPF domain from the current external dependencies for your tenant;
existing receive and send connectors, their scopes and precedence, and the firewall and NAT rules;
the current MX and SPF values, including TTLs.

Sophos values are region-dependent. Copy them from your own Sophos Fusion tenant, not from an example or another region. Use Sophos’s current lists for Gateway delivery IP addresses, MX records, outbound relay hosts, and SPF domains. The tenant also shows the relay under Gateway Domains > domain > Configure External Dependencies > Outbound Settings. Keep the old DNS values and connector settings as a tested rollback path before the pilot. Lower the DNS TTL in advance according to your change procedure, rather than during an incident. Sophos notes that connector changes can take up to 24 hours to propagate, so do not interpret an immediate test alone as final propagation.

Configure the domain and inbound path

Prepare Sophos Gateway

In Sophos Fusion, go to Global Settings > Products and Services > Email > Gateway Domains, then add or open the domain.
Enter the domain, traffic direction, delivery destination, and its SMTP port. The complete workflow requires the Inbound and Outbound direction.
Select Verify Domain Ownership, publish the displayed domain-specific TXT value as a TXT record at the domain root, and then select Verify. Use the displayed name or @ as the record name.
Continue only after Sophos confirms domain verification. A failed check usually means the TXT value is wrong or DNS propagation is incomplete.
Add or synchronize the mailboxes that Sophos Email must protect.

The delivery destination is the publicly reachable Exchange endpoint, not the Sophos MX name. Its FQDN or IP address and port must match the published SMTP service and firewall forwarding exactly.

Restrict Exchange reception

On the firewall and the Exchange receive path, permit only the regional Sophos delivery IP addresses as sources for the Sophos delivery route. Obtain the exact addresses from the tenant’s current external dependencies. Omitting one can prevent Sophos delivery; adding an unrelated or overly broad network weakens bypass protection.

On the Exchange Receive Connector used for Sophos, set the local binding to the intended local Exchange IP and listening port, and set the remote IP ranges separately to only the regional Sophos delivery IP addresses; do not use 0.0.0.0/0. Normal receipt for recipients in Exchange accepted domains is distinct from SMTP relay permission: accepted-domain handling does not require, and this connector must not receive, general relay rights. If Receive Connectors overlap, determine which connector will match every Sophos source address before cutover.

First verify that this path is reachable without removing the old protection path. Then replace the DNS provider’s MX records with the regional Sophos MX targets. Spelling, preference, and region must match the tenant values exactly.

Configure the outbound path through Sophos

Authorize the outbound source in Sophos

Open the domain under Gateway Domains and select Edit.
In Configure Domain, confirm the Inbound and Outbound direction.
Under Outbound Gateway, select Custom Gateway.
Add at least one public IP address or CIDR network from which Sophos will actually see outbound connections, then save. Private Exchange addresses behind NAT are not the visible source here.
Open Configure External Dependencies > Outbound Settings and copy the region-dependent Outbound Relay Host.

Keep source ranges as narrow as possible. An unnecessarily large CIDR can authorize unrelated systems as senders, while an incorrect NAT address causes relay rejections.

Switch the Exchange Send Connector

On Exchange, create an SMTP Send Connector for internet recipients, select Route mail through smart hosts, and use Add to enter exactly the Outbound Relay Host copied from Sophos Fusion. Configure each Exchange control for its own purpose: address spaces determine which recipient domains this connector routes; source transport servers are the Exchange servers that host the connector—mail selected for the connector is routed to one of them, which establishes delivery to the smart host; cost breaks selection ties between equally specific matching address spaces; and the scoped-connector setting limits the connector’s availability in Exchange topology to its Active Directory site, not its recipient routing. Follow Microsoft’s version-specific instructions for Exchange 2019, Exchange 2016, or Exchange 2013.

During acceptance and cutover, disable every old filtering Send Connector whose address spaces overlap the Sophos connector, regardless of its source-server list; retain its documented configuration, not an enabled competing route, for rollback. If a pilot must keep both connectors enabled, give them genuinely non-overlapping address spaces. Disjoint source-server lists do not partition messages by their originating Exchange server and are not safe isolation. Do not rely on cost alone: Exchange evaluates address-space specificity before cost. After successful testing, keep the old overlapping connector disabled or remove it so messages cannot bypass Sophos Gateway.

Check SPF, DKIM, and both directions

Once Sophos delivers outbound mail, update the domain’s existing single SPF TXT record with the regional value from the linked Sophos SPF-domain list. A Sophos-only replacement has the exact placeholder form v=spf1 include:<spf-domain> -all. During parallel operation, keep every existing authorized mechanism and insert include:<spf-domain> before the record’s one terminal all, for example v=spf1 include:old.example include:<spf-domain> -all. Replace <spf-domain> with the regional value; never publish the angle-bracket placeholder, never append a second terminal all, and never create a second SPF record. Choose hard fail -all only when you are confident every actual sender is represented in that one record; otherwise use ~all. This choice depends on sender coverage, not on Sophos being the only route. Check DKIM separately and configure it in Sophos if required; changing SPF does not replace DKIM signing.

Use unique subjects for acceptance tests and record the sender, recipient, and time:

Inbound: Send from an external domain to a protected mailbox. In Sophos Fusion, the message must appear under Reports > Message History, then in Exchange message tracking and the destination mailbox.
Outbound: Send from a protected mailbox to an external domain. Set the direction in Message History to outbound and inspect the entry, then confirm acceptance by the external recipient and check Exchange message tracking.
Bypass and relay: Direct delivery to Exchange from an unauthorized source and a relay attempt to an unrelated domain must not be accepted through the restricted Sophos receive path.

An entry in only one system is not end-to-end success. Use timestamps and the Message-ID to correlate Exchange tracking, Sophos history, and the recipient result.

Troubleshoot methodically

Inbound message is absent from Sophos: Check MX targets, preference, DNS propagation, and region. An old MX can still let traffic bypass the gateway.
Visible in Sophos but not Exchange: Check the delivery destination and port, firewall/NAT, regional Sophos delivery IP addresses, Receive Connector scope, and Exchange queues. Also exclude a mailbox missing from Sophos.
Outbound message remains in Exchange: Check DNS resolution and reachability of the copied Outbound Relay Host, the selected Send Connector and its source servers, and Exchange queues.
Relay is rejected: Determine which public source IP Sophos actually sees and compare it with the IP/CIDR values under Custom Gateway. Do not broadly enlarge the range.
TLS fails: Check the smart-host and delivery-destination names, certificate chain, validity, name match, and TLS negotiation supported by both sides. Do not permanently disable TLS to hide a name or certificate problem.
Some messages use the old path or loop: Check overlapping Send Connector address spaces, costs/precedence, and old filtering connectors. Old MX targets and upstream relays can also create a loop.

After each correction, repeat the test for the affected direction and compare new timestamps. If flow is still absent, capture the Message-ID, time window, connector state, queue error, and matching Sophos Message History entry for escalation.

Roll back safely

Roll back only the failing direction. For inbound incidents, restore the saved previous MX values and keep the previous receive path active until DNS has propagated. For outbound incidents, first restore the saved former sender mechanisms by merging them into the domain’s single SPF record while temporarily retaining include:<spf-domain>, and allow for DNS propagation according to the change plan. Then re-enable the known previous Send Connector and unambiguously disable the new Sophos Send Connector so there are no competing routes.

Remove firewall and Receive Connector changes only after the restored inbound path demonstrably works. Remove include:<spf-domain> from the domain’s single SPF record only after validating the restored outbound route, while preserving the restored sender mechanisms. Then retest inbound and outbound, inspect both queues, and document remaining DNS caches. This prevents a partial rollback from becoming an open relay or a second uncontrolled sending route.