Skip to content
Avanet

Sophos Email: choose an architecture and plan onboarding

Sophos Email

The most important Sophos Email decision comes before adding the first domain: Sophos Mailflow or Sophos Gateway. Both options are managed in Sophos Fusion (formerly Sophos Central), but they enter the mail flow at different points. Choosing the architecture early makes it possible to plan ownership, the pilot, cutover and a safe way back.

Quick decision: If you use Microsoft 365 exclusively and don’t want to redirect your existing MX records, evaluate Sophos Mailflow first. If Sophos must be the upstream email gateway, you need control over the DNS and MX routing path, or you use Google Workspace or an on-premises mail server, plan Sophos Gateway. Never configure both processing modes for the same domain at the same time.

Product boundary: Sophos Fusion, not the firewall mail proxy

This article covers Sophos Email in Sophos Fusion. On-box Mail Protection on a Sophos Firewall is a different product and operating model. Do not transfer firewall mail proxy rules, exceptions or menu paths to Sophos Email. Replacing Firewall Mail Protection requires a separate migration project with its own routing and rollback plan.

Choose the architecture

Sophos Mailflow for Microsoft 365

Sophos Mailflow integrates with Microsoft 365 through Microsoft APIs, Exchange Online connectors and mail flow rules. Messages are routed between Microsoft 365 and Sophos for scanning; this model doesn’t require MX redirection or a DNS change for domain verification. Manage its domains in Sophos Fusion under Products and Services > Email > M365 Mailflow Domains.

Mailflow is a good fit when Microsoft 365 should remain the front door and changing public mail routing is undesirable. First confirm that the Microsoft 365 subscription supports inbound connectors and that the administrator account can grant the required consent and Exchange Online mail flow permissions.

Its operational boundary matters: Microsoft still processes messages at its front door. Some Microsoft filters, particularly for high-confidence phishing, can’t be completely disabled by mail flow rules. A message can therefore reach Microsoft quarantine before it becomes visible in Sophos. For Mailflow, include both quarantines and Microsoft Message Trace in the operating procedure.

Sophos Gateway for Microsoft 365, Google Workspace and on-premises mail servers

Sophos Gateway is the upstream secure email gateway. The public MX record points to Sophos; Sophos scans inbound messages and then delivers them to Microsoft 365, Google Workspace or an on-premises mail server. For outbound scanning, the mail server routes outbound delivery through Sophos. Manage its domains under Products and Services > Email > Gateway Domains.

Gateway is a good fit when Sophos must handle the first SMTP connection from the internet, when you need your own routing or TLS decisions, or when the platform isn’t Microsoft 365. It requires access to DNS and MX as well as the routing configuration of the mail provider or mail server. Change MX only after domains, destinations, mailboxes and policies are ready.

The exact provider procedures for Microsoft 365, Google Workspace and on-premises mail servers belong in their respective setup guides. This architecture guide deliberately doesn’t anticipate regional hosts, IP addresses, ports, connector names or DNS values.

Confirm prerequisites and ownership

Record at least the following before the pilot:

  • a valid Sophos Email license and administrative access to Sophos Fusion;
  • the mail platform, protected domains and selected architecture for each domain;
  • every protected mailbox, alias, distribution list and public folder;
  • the authoritative mailbox source, such as directory synchronization or a maintained import;
  • owners for DNS, Microsoft 365 or Google Workspace, the on-premises mail server and Sophos Fusion;
  • business owners for Email Security, Data Control and Secure Message policies;
  • encryption, retention, quarantine and reporting requirements;
  • the cutover window, acceptance criteria, escalation path and rollback contacts with authority to decide.

Missing recipient objects are not cosmetic: Sophos Email needs the complete recipient inventory to process messages correctly. Compare aliases and groups as carefully as personal mailboxes. Change synchronized objects in the authoritative directory rather than using Sophos Fusion as a permanent workaround.

Onboard in phases

1. Document the inventory and mail path

Map the current inbound and outbound path for each domain. Record where MX terminates, which systems send directly, which forwarding paths exist, and who may change DNS, provider rules and mail servers. Keep pilot, production and special-purpose domains separate.

2. Prepare the domain and recipients

Add the domain in the chosen mode and connect the mailbox source. Synchronize or import mailboxes together with aliases, distribution lists and public folders. Verify the inventory before changing routing or enabling protection broadly.

3. Define policies before cutover

At minimum, define ownership and scope for Email Security, Data Control and, when required, Secure Message. Start with understandable rules and documented exceptions. Decide quarantine notifications, encryption and outbound protection before production cutover, not after a business message has been blocked.

4. Run a limited pilot

Choose representative internal and external test partners and, where the architecture permits it, a clearly bounded pilot group. Test normal messages, attachments and replies in both directions. Include an alias or distribution list. Mailflow can protect a subset of mailboxes; the exact group assignment belongs in the dedicated Mailflow setup guide.

5. Cut over under control

Enable only one architecture for each domain. For Gateway, the MX change is the final step after internal destinations, the outbound path, recipients and policies are ready. For Mailflow, the connectors and mail flow rules created by Sophos must be complete and conflict-free in Microsoft 365. Freeze parallel routing changes during acceptance testing.

Decide behavior during a service interruption

Depending on the Email configuration, Account preferences shows either Selectively scan or Enforce scan, never both at the same time. During a rare service interruption, Selectively scan delivers messages without delay while running only essential scans. Enforce scan spools messages until service recovers so that all scans run, at the cost of delayed delivery.

Before production cutover, document the chosen availability-versus-complete-scanning posture, its accountable owner and measurable acceptance criteria. Selectively scan prioritizes delivery but accepts that not all scans run; Enforce scan prioritizes complete security scanning but accepts a delivery delay.

After an interruption, verify selectively scanned messages in the message details in Message History. For Enforce scan, review delivery delay and queue recovery through the normal message and provider traces, and confirm that the backlog was delivered and the agreed acceptance criteria were met.

Protect cutover and rollback

A way back is more than an old MX value. Before cutover, approve a rollback sheet containing:

  • original values and owners for DNS, MX, connectors, rules and smart hosts;
  • an abort condition, such as undeliverable external messages or a routing loop;
  • the order for restoring the old route and disabling the new one;
  • control messages after every rollback step;
  • contacts for Sophos Fusion, the provider, DNS and the internal mail server.

Do not manually delete the Microsoft/Sophos application, connectors or mail flow rules based on this overview. Use only the documented and approved provider-specific offboarding workflow once it is available. Before any authorized change, record the existing state, then verify message routing after every change. Until that procedure is established, escalate the removal instead of improvising. For Gateway too, the rollback above is planning guidance only; execution must follow a documented and approved provider-specific workflow.

Prove that it works

Domain and mailbox status

In M365 Mailflow Domains or Gateway Domains, confirm that the expected domain is shown as protected. Then compare protected mailboxes with the target inventory. Sampling isn’t enough when aliases, distribution lists or public folders are business-critical.

Inbound and outbound test messages

For every domain, send at least one inbound message from a controlled external account and one outbound message to that account. Check sender, recipient, timestamp and final delivery. Trace both in Message History. For Mailflow, add Microsoft Message Trace; for Gateway, also inspect the provider or mail server trace.

If a message is visible on only one side, don’t immediately weaken a filtering policy. First determine whether the domain or mailbox status, routing, connector, DNS, recipient inventory or delivery is at fault. This prevents security exceptions from being used to fix a routing problem.

Reports and quarantine

Open Message History, generate or schedule an Email Report, and inspect the administrator quarantine. For Mailflow, include Microsoft quarantine in the operating procedure. Decide who can release messages, report misclassifications and review report trends. Onboarding is operationally complete only when history, reports and quarantine have an owner.

When acceptance fails

  • Domain or mailbox isn’t protected: Check the mailbox source, synchronization run, domain assignment and license.
  • Inbound fails but outbound works: Check the public mail path, MX or mail flow rules, and provider trace.
  • Outbound fails but inbound works: Check the outbound route, connector or smart host.
  • Message is quarantined only by Microsoft: Check Microsoft Message Trace and Microsoft quarantine; don’t infer delivery from Sophos Message History.
  • Duplicate processing or a loop: Immediately check whether Mailflow and Gateway, or old and new connectors, are active together; trigger the approved rollback if necessary.

Provider-specific connector, DNS, licensing and directory synchronization errors are covered by separate detailed guides. Collect timestamps, sender, recipient, Message-ID and both trace results instead of trying uncertain settings.