Set up and safely disconnect Sophos Email Gateway

With Sophos Email Gateway, Sophos becomes the upstream SMTP gateway: inbound messages reach Sophos first and are then delivered to your mail provider or mail server. For outbound scanning, your system sends through Sophos. A safe deployment therefore needs two distinct routes, a prepared fallback path and tests in both directions.

Quick path: Add mailboxes, add the domain under Products and Services > Email > Gateway Domains, verify it with a DNS TXT record, define the inbound destination and outbound gateway, review policies, prepare the provider-specific routes, and only then change public MX. Then deliver one message in each direction and prove both in Message History and in the provider or mail server trace.

Establish the product boundary first

Gateway isn’t the same as Sophos Mailflow for Microsoft 365. Mailflow connects through Microsoft 365 integrations; Gateway changes the SMTP routing path. Never enable both processing modes for the same domain at the same time, because messages can be processed twice and create duplicate Message History entries.

Mail Protection on a Sophos Firewall is also a different product. Firewall mail proxy rules, exceptions and menu paths don’t apply to Sophos Email in Sophos Fusion (formerly Sophos Central). If Gateway replaces an existing firewall mail proxy, document that proxy as a separate source system and retire it only after Gateway acceptance succeeds.

Record prerequisites and the way back

Before the first routing change, you need:

a valid Sophos Email license and administrative access to Sophos Fusion;
a supported mail provider or reachable mail server;
the protected domain and complete mailbox, alias and group inventories;
change access to DNS, provider routing or the mail server, and the upstream firewall where applicable;
the current inbound MX path, existing outbound route and their original values;
the public inbound delivery target and public sender IP addresses or networks for outbound relay;
a cutover window, abort criteria, and owners for Sophos Fusion, DNS and mail operations.

The rollback sheet must contain more than the old MX value. Record smart hosts, connectors, permitted relay sources, firewall rules, SPF references and the restoration order. Values in Configure External Dependencies are region- and domain-specific; copy them from your own tenant, not from examples or old tickets.

Set up Sophos Email Gateway

1. Provision mailboxes before routing

Add protected mailboxes through directory synchronization, manually in the UI or by CSV. Compare personal mailboxes, aliases, distribution lists and shared addresses with the target inventory. Don’t begin the MX change until the recipient inventory is complete.

2. Add the domain and verify ownership

In Sophos Fusion, open Global Settings.
Select Products and Services > Email > Gateway Domains.
Click Add Domain. For the first domain, use the displayed Set up email gateway settings prompt instead.
Under Email Domain, enter your domain, for example example.com.
Select Verify Domain Ownership and create the displayed TXT record exactly at the authoritative DNS provider.
After DNS publication, click Verify and close the dialog only after verification succeeds.

The TXT record only verifies ownership; it doesn’t alter mail flow. Every Gateway domain must be verified separately, and an unverified domain can’t be saved. If verification fails immediately after the change, allow for DNS propagation and compare the name and value character by character instead of creating a second, different record.

3. Define direction, destination and relay sources

For the domain, select Inbound Only or Inbound and Outbound. Inbound and Outbound is appropriate for full outbound scanning, Smart Banners and useful reporting, provided your mail system supports sending through Sophos.

Inbound destination offers two models:

Mail Host: the public IP address or FQDN of the router, firewall, front-end mail server or provider target to which Sophos delivers.
MX: the FQDN used for mail-exchange resolution. This model is required when you need multiple destinations.

The destination host must not resolve back to the public Sophos MX for the protected domain. Otherwise, Sophos sends the message back to itself and creates a loop.

For Inbound and Outbound, select the outbound gateway type that matches your system. For a Custom Gateway, enter at least one public IP address or CIDR range belonging to the systems that actually send. Keep the permission as narrow as possible; private addresses or broad third-party networks aren’t valid relay identities. Your server or service can send to Sophos over SMTP port 25 or 587. Use the port and authentication method shown for your tenant and supported provider procedure.

4. Follow the provider-specific branch

Expand Configure External Dependencies. Under Inbound Settings, select your provider and apply the MX values and Sophos delivery IP addresses then displayed. Next, open Outbound Settings and use the displayed relay host for the outbound route:

These choices have their own connector, routing and security rules. Follow the values displayed after selecting the provider and the provider’s current instructions without duplicating the provider-specific procedure here. Don’t transfer connector names, hosts, IP addresses or TLS options from another provider.

5. Review policies and optional BATV

After Save, go to My Products > Email Security > Policies, open at least the Base Policy for spam protection, and review scope, actions and exceptions. Other global email settings are under Products and Services > Email. A default isn’t a business approval; quarantine and delete actions must match your operating policy.

Enable Bounce Address Tag Validation (BATV) only when every outbound message in scope passes through Sophos. Direct delivery around Sophos creates untagged bounces. For the first seven days after enabling BATV, Sophos recommends a tolerant failure action such as Deliver, Tag subject line or Quarantine, not Delete. Tighten the action only after controlled observation.

Cut over and roll back under control

Before cutover, save the current configuration, test reachability of the inbound destination and confirm that the outbound route can be restored. Activate the prepared provider routes, then change public MX as the final step to the Sophos values shown under Inbound Settings. Freeze parallel connector, DNS and policy changes during acceptance.

Trigger rollback if, for example, external messages are undeliverable, relay is rejected or a loop occurs. Restore the previous inbound MX path and outbound route in the documented order, disable the faulty new path, and repeat the control messages. Don’t delete the Gateway domain yet: DNS caches may still send messages to Sophos.

Prove inbound and outbound mail flow

Run separate tests with unique subjects for every domain:

Send from a controlled external account to a protected mailbox.
Reply from the protected mailbox or send a new message to the external account.
Record sender, recipient, time, Message-ID and final delivery.
Find both messages in Message History and confirm the expected direction and processing.
Confirm the corresponding hop in the provider trace or mail server log as well.

Success means more than “delivered.” Inbound must show external → Sophos → internal destination; outbound must show internal → Sophos → external. Also test an alias or distribution list and inspect administrator quarantine. If a message is absent from Message History, investigate routing and relay before weakening a protection policy.

Disconnect a Gateway domain safely

Offboard in reverse dependency order without deleting the active path too early:

Record current MX, TXT, SPF, relay, connector and firewall values.
Prepare direct inbound delivery and outbound delivery without Sophos at the destination provider.
Restore public MX to the current provider and move the outbound route from the Sophos relay to the approved direct path.
Send control messages both ways and prove them at the provider or mail server.
Wait until DNS answers return the new path and no trailing legitimate traffic appears in Sophos Message History.
Open the domain under Gateway Domains, select Delete domain in Domain summary, and confirm with Delete.
Remove unneeded Sophos delivery IPs, relay permissions and Sophos SPF references. Also remove the ownership TXT record if no other active Sophos connection needs it.

Don’t delete the domain until direct mail flow is proven in both directions. During a provider change, add the new provider’s required SPF domains first; simply removing Sophos from SPF can damage outbound delivery.

Troubleshoot DNS, relay, ports and loops

Domain verification or MX remains wrong

At authoritative DNS, verify that the TXT name and value exactly match Verify Domain Ownership. Then compare the publicly returned MX answer with Inbound Settings. A mixture of old and new MX targets can split traffic; correct the record set as a unit and allow DNS propagation before reassessing.

Inbound doesn’t work

Check Message History first. If the message isn’t there, MX or sender routing probably doesn’t point to Sophos. If Sophos shows it but the internal system doesn’t, check Inbound destination, its DNS resolution, SMTP reachability and the upstream firewall. Don’t open port 25 or 587 indiscriminately in every direction; the hop documented in Sophos Fusion and by the provider determines what is required.

Outbound is rejected as relay

The sending system’s public source IP must match the gateway or CIDR authorized in Sophos. Also check the relay host, port, provider connector and NAT. A broad relay permission isn’t a fix; it increases abuse risk.

Loop or duplicate processing

For duplicate processing, check whether Gateway and Mailflow are both active for the domain. For a loop, check whether the Sophos delivery destination points back to Sophos or old and new smart hosts act as competing routes. Freeze routing changes, preserve Message-IDs and hops, and execute the documented rollback. Retest only after there is one unambiguous route.