Migrate from Sophos Firewall Mail Protection to Sophos Email

This migration moves email inspection and policy from Sophos Firewall Mail Protection to Sophos Email in Sophos Fusion (formerly Sophos Central). It is not a configuration copy: map functions and recipients first, prepare Sophos Email without changing production routing, and then cut mail flow over under control. Keep the old path recoverable until the agreed rollback window ends.

⚠️ Never change MX, the outbound smart host, DNAT and several policies at once without testing. Before any firewall or routing change, take a current Sophos Firewall backup, record the original values and verify independent management access.

1. Select the architecture and stop conditions

Microsoft 365 can use Sophos Mailflow or Sophos Gateway. Mailflow uses Microsoft 365 connectors and rules; Gateway uses SMTP routing and normally an MX change. Other platforms use Gateway. Use Plan Sophos Email architecture and onboarding for the decision. A domain must have only one production Sophos inspection path.

Define the change window, owners for Sophos Fusion, Sophos Firewall, DNS and the mail server, pilot domains or mailboxes, and stop conditions. Undeliverable external mail, an open relay, duplicate processing or a routing loop are rollback triggers. A valid Sophos Email license must already be active.

2. Preserve inventory, backup and return path

For each domain, record:

• current MTA Mode or Legacy Mode/transparent proxy;
• protected domains, mailboxes, aliases, distribution lists and SSP use;
• inbound MX path, outbound smart host, relay sources, NAT, SMTP ports and TLS requirements;
• SMTP policies, order, exceptions, blocked senders, quarantine summaries and DKIM;
• spam/malware actions, file and Data Control rules, encryption/SPX and banners;
• firewall and NAT rule IDs, objects, zones, logging, mail-server target and return route.

Export or capture these values, make a current Sophos Firewall backup and write down the exact restoration order. Lower DNS TTL only under your change procedure. Do not delete old rules.

3. Map policies and approve non-equivalents

Create a row for every source policy, preserve its order and scope, and configure the target rather than merely recording a feature name:

• MTA Mode spam: under Email Security > Policies > [Email Security policy] > Settings > Anti-Spam, map Firewall None → Deliver, Warn → Tag subject line, Quarantine → Quarantine, and Drop → Delete. Configure SPF, DKIM and DMARC under Authentication with the approved action.
• Transparent proxy spam: at the same Anti-Spam destination, map Accept → Deliver, Prefix subject for spam → Tag subject line, Quarantine → Quarantine, and Drop → Delete. Reject and Change Recipient have no Sophos Email equivalent; redesign the workflow or record explicit risk acceptance—do not silently substitute Deliver or Delete.
• File/Data Control: recreate attachment rules at Email Security > Policies > Data control: [policy] > Settings > Inbound > Add rule with the Attachment file types (AFT) template. Recreate custom Data Control Lists with Content control lists (CCLs) and size/header/source checks with Message Attribute (MA). Choose and test the inbound or outbound direction, action and exceptions for each rule; a Firewall list is not migrated automatically.
• Encryption/SPX: map Firewall SMTP TLS to Email Security > Policies > Secure Message: Base Policy – Secure Message or a narrower Add Rule > Secure Message policy. Both internal and external selections are required for a scoped rule. Push Encryption is the PDF-encryption counterpart to SPX, while Portal Encryption uses Sophos Secure Message; recipient-defined passwords mean SPX settings and passwords are not copied. Validate TLS support between the mail server and Sophos Email.
• Exceptions: map a sender/recipient anti-spam exception to a narrowly scoped Email Security policy with Anti-Spam = Deliver; map a global exception to Email Security > Settings > Inbound Allow/Block > Add allow (email, domain or IP), which bypasses spam checks globally. Map SPF/DKIM exceptions to a scoped policy under Authentication, Intelix exceptions under Anti-malware, and Data/File exceptions by excluding the matching addresses or Message Attributes in the specific Data control rule. Review broad allows instead of copying them blindly.
• No direct equivalent: custom RBLs and greylisting cannot be configured in Sophos Email; Sophos Email Advanced uses the automatically enabled Sophos Delay Queue, not customer greylisting. BATV secrets and Firewall BATV behavior have no setting to migrate to this cloud service. POP/IMAP scanning is unavailable. Novell eDirectory/OpenLDAP integration has no identical migration, SNMP must be replaced with owned Sophos Fusion notifications/reports, and Firewall Hardware Monitoring remains a separate infrastructure task.

Do not go live until every row has a tested target or documented non-equivalent with explicit risk acceptance.

4. Prepare Sophos Email completely

Add or synchronize domains and every recipient, then reconcile aliases and groups against the source inventory. Prepare SSP, administrator quarantine and roles. Create target policies with narrow scopes and the intended order, initially in pilot scope or non-enforcing state. Use Set up Sophos Email Gateway for Gateway, or Set up Sophos Email Mailflow for Microsoft 365.

Copy tenant- and region-specific hosts, IP addresses and DNS values only from Configure External Dependencies in your own tenant. Never reuse sample or ticket values.

5. Prepare temporary firewall interoperability

This stage is needed only when Sophos Email must deliver through Sophos Firewall to an on-premises or third-party mail server after cloud inspection. Skip it for Microsoft 365 or Google Workspace when no firewall hop is required.

Create the disabled DNAT rule explicitly: Original source = current regional Sophos Delivery IPs from Configure External Dependencies; Original destination = the WAN interface/address receiving delivery; Original service = the delivery port Sophos Email connects to; Translated destination (DNAT) = the real internal mail-server host/IP; Translated service (PAT) = the SMTP port on which that server actually listens (often SMTP/25). Only use PAT when those two services differ, and set the matching inbound interface. Never put the internal server in Original destination or the public/WAN object in Translated destination.

Create the associated firewall rule disabled and above broader matches: Source zones = WAN-facing zone(s), Source networks and devices = those Sophos Delivery IPs, Destination zones = the post-NAT zone containing the mail server, Destination networks = the pre-NAT WAN destination used as the DNAT rule’s Original destination, and Services = the original delivery service/port accepted on WAN—not the translated SMTP/PAT service. Enable logging. These fields intentionally describe different pre- and post-NAT stages; do not make them identical for apparent consistency. Confirm return routing, and allow relay on the mail server only for the intended Sophos path.

The new hop must not pass through the old MTA or proxy inspection again. The Sophos Email delivery target must not resolve to the public Sophos MX or route through a smart host back to Sophos Email. Define one outbound path: mail server/provider → Sophos Email → internet.

6. Cut over in stages

Recheck backup, recipients, policy state, target reachability, rule order and rollback approval. For a local destination, enable the prepared DNAT and firewall rules first and confirm the expected rule hit. For Mailflow, enable the prepared Microsoft connectors and rules only after conflicts are resolved. For Gateway, change public MX only now, using the values displayed in the tenant.

Test inbound mail first. Only after external → Sophos Email → destination works unambiguously should you change the outbound smart host or connector to Sophos Email. Update SPF, DKIM and DMARC for the final sending path according to the tenant, and verify all three in received-message headers and DNS. Freeze unrelated DNS, rule and policy changes during acceptance.

7. Validate flow and protection

Capture unique Message-IDs and timestamps for every domain:

1. external mail to a personal mailbox;
2. mail to an alias or distribution list;
3. an outbound reply and a new message to a controlled external account;
4. harmless authorized tests for expected spam, malware/file and Data Control actions;
5. TLS, quarantine, reporting and SSP access checks.

Prove each message in Message History and in Microsoft Message Trace, the provider trace or mail-server logs. On Sophos Firewall, verify DNAT and firewall rule IDs, port and target. Success means final delivery, exactly one Sophos inspection and the intended policy action—not merely an open TCP connection.

Troubleshoot in this order: MX/DNS propagation, domain and mailbox status, connector or smart host, DNAT and destination zone, rule order and rule ID, port/TLS, relay authorization, policy scope, then filter actions. A missing Message History record usually indicates routing, not a need for a broad exception.

8. Roll back or retire safely

On abort, restore the old outbound smart host or connector first and publish the previous MX values, but treat the DNS change as asynchronous. During at least the previous MX TTL plus the authoritative DNS propagation window, keep both inbound acceptance paths functional: the old destination must still accept traffic from caches using the old MX, while Sophos Email, its domain/routing configuration, and any required temporary DNAT/firewall/relay path must continue accepting traffic from caches using the new MX. Ensure neither path sends back into the other. Send control messages through both paths and use DNS observations, Message History and server logs to count traffic on each.

Disable the new inbound path only after the cache window has elapsed and logs show no more deliveries through it; do not disable temporary firewall rules at the moment the old MX is republished. Only after stable operation for the agreed rollback window should you disable old SMTP policies. Following another acceptance test, remove unneeded NAT/firewall rules, objects and relay permissions. Retain the backup, policy map, DNS values, Message-IDs and acceptance record. Never remove a path while cached MX answers, POP/IMAP or another unmapped function still depends on it.