Set up Sophos Firewall MTA with Microsoft 365

Sophos Firewall can operate as a separate mail gateway in front of Microsoft 365 in MTA mode. Inbound messages first reach the firewall and are then delivered to Exchange Online Protection. Exchange Online sends outbound messages back to the firewall through a connector, where they are inspected and forwarded to the internet.

This design is possible, but it is not automatically the best architecture. Sophos Central Email, Microsoft Defender for Office 365, and on-box Mail Protection partly overlap. Before making changes, decide which system is responsible for spam, malware, quarantine, TLS, DKIM, and troubleshooting.

⚠️ Broad relay access can turn the firewall into an open relay. Keep a local administrator session, the existing mail flow, and a tested fallback available before changing the MX record. Do not perform the production cutover until an unauthorized relay test is reliably rejected.

Draw the bidirectional mail flow first

The inbound path is Internet → Sophos Firewall MTA → Exchange Online Protection → Microsoft 365 mailbox. The public MX record therefore points to the firewall’s public SMTP address. The SMTP route and scan policy then delivers to the tenant-specific Microsoft target, such as example-com.mail.protection.outlook.com.

The outbound path is Exchange Online → Microsoft 365 connector → Sophos Firewall MTA → Internet. The firewall must accept relay only from the current Exchange Online Protection networks. HELO, certificate, public source IP, PTR/rDNS, SPF, DKIM, and DMARC must match this path.

Set up Mail Protection in MTA mode explains the general MTA concepts, policy fields, quarantine, and logs. This article focuses on the Microsoft 365 connection.

Example values and prerequisites

The example uses the mail domain example.com, firewall FQDN mail.example.com, documentation address 192.0.2.25, and tenant-specific target example-com.mail.protection.outlook.com. Replace them with the real domain, a fixed public address, and the actual Microsoft target. 192.0.2.25 belongs to TEST-NET and must not be used in production.

TCP 25 must work from the internet to the firewall, from the firewall to Microsoft 365, and from the firewall to external mail servers. The deployment also needs a suitable Email Protection license, MTA support on the appliance, a publicly trusted certificate, controlled DNS access, and permissions for Exchange Admin Center and authoritative DNS.

Exchange Online Protection networks change. Do not copy them from a static example; maintain them from the current Microsoft 365 endpoint list linked by Sophos. The SMTP endpoints on TCP 25 are especially relevant to this mail flow. Record an owner and review interval for the host objects.

Connect Microsoft 365 and SFOS in eight steps

1. Record the current MX record, SPF, connectors, message headers, public source IP, and fallback path.
2. Prepare MTA mode, the automatic MTA rule, certificate, and outbound scanning on SFOS.
3. Create separate IP host objects for the current EOP address ranges.
4. Allow SMTP Relay from WAN, restrict host-based relay to the EOP objects, and block all other sources.
5. Create an SMTP route and scan policy for the protected domain and tenant-specific Microsoft target.
6. Create a connector in Exchange Online from Microsoft 365 to the firewall’s public address.
7. Change MX and SPF during a maintenance window.
8. Validate inbound, outbound, and rejected relay attempts with headers, Mail logs, spool, and Microsoft trace data.

Prepare Sophos Firewall

MTA mode, automatic rule, and certificate

Turn on MTA mode under Email > General settings. SFOS creates Auto added firewall policy for MTA for SMTP and SMTPS. Don’t edit this rule, and keep it at the top as Sophos recommends. If it is missing while MTA mode is active, don’t build a custom Any-to-Any replacement. Check the mode, existing configuration, and support path first.

For SMTP hostname, enter the intended domain name under SMTP settings. Select a publicly trusted certificate under SMTP TLS configuration and leave Allow invalid certificate off. Scan outgoing mails must be on if messages arriving from Exchange Online must also be inspected.

Allow EOP sources to relay

Under Hosts and services > IP host, create a clearly named object for every current EOP IPv4 range, for example with the prefix O365_EOP_. Don’t merge the ranges into a larger network. When Microsoft changes the list, add and remove networks in a controlled change and retest them.

Turn on SMTP Relay for WAN under Administration > Device access. This zone switch is too broad by itself, so restrict it under Email > Relay settings > Host-based relay:

• Allow relay from hosts/networks: only the maintained EOP host objects;
• Block relay from hosts/networks: Any.

Sophos evaluates a matching allow entry before the overlapping block. This is why the allow list must not contain broad provider, cloud, or Any networks. Upstream host controls a separate destination relationship and does not replace this source check.

For normal inbound internet mail, the Sophos procedure sets Upstream host > Allow relay from hosts/networks to Any. This permits external SMTP hosts to deliver to protected domains; it is not the same permission as outbound host-based relay. If a defined external mail gateway already sits in front of SFOS, restrict the upstream list to its actual source networks instead.

Route and scan policy for Microsoft delivery

Create the protected mail domain as Email address/domain under Email > Address group. Then add a policy under Email > Policies and exceptions > Add a policy > SMTP route and scan with:

• the address group under Protected domain;
• Global action: Accept;
• Route by: DNS host and the tenant-specific Microsoft target;
• deliberately selected spam, malware, file, and data protection settings.

The routing host is not the public MX for example.com after it points to the firewall. Otherwise, the firewall delivers back to itself and creates a loop. Record the actual Microsoft target before changing the MX record and verify that SFOS resolves it correctly.

Create the Exchange Online connector

In Exchange Admin Center, create a connector under Mail flow > Connectors with From: Office 365 and To: Partner organization. To send all outbound mail through SFOS, apply its destination condition to every recipient domain (*). A deliberately limited subset must match the documented mail design. Use the public IP address or firewall FQDN mail.example.com as the smart host.

Require TLS for the connector. The Sophos help also shows a compatible choice that accepts any digital certificate, including self-signed certificates. For production, a publicly trusted certificate whose identity matches the FQDN is more robust and must be validated with a real connector test.

Connector validation may fail before the DNS change. It therefore does not replace the later end-to-end test or the negative relay test. After saving, use Microsoft Message Trace to verify that outbound messages actually use the intended connector and firewall.

Change MX and SPF in a controlled manner

Only point the public MX record to mail.example.com after the firewall policy, EOP relay access, internal Microsoft target, and connector are ready. Reduce the TTL before the maintenance window. Keep the old MX destination available for the documented rollback, but don’t leave it in parallel if senders could randomly bypass the new protection path.

The SPF record must authorize Exchange Online and the firewall’s public sender identity. Sophos gives v=spf1 include:spf.protection.outlook.com mx -all as a simple example. Don’t replace the current record blindly. Inventory existing senders, subdomains, include chains, and the DNS lookup limit first. Recheck DKIM and DMARC with real message headers.

Validate the complete path

The following read-only checks are useful from an external test system:

dig MX example.com
dig A mail.example.com
nc -vz mail.example.com 25
openssl s_client -starttls smtp -connect mail.example.com:25 -servername mail.example.com

Replace the example names with the real values. DNS, TCP, and TLS do not prove delivery. At minimum, test an external message to a Microsoft 365 mailbox, an outbound message from Microsoft 365, an invalid recipient, and a relay attempt from a source IP that isn’t allowed.

On SFOS, correlate Email > Mail logs, Mail spool, SMTP quarantine, Log Viewer, smtpd_main.log, smtpd_reject.log, and smtpd_error.log with the same timestamp. On the Microsoft side, Message Trace and connector status show whether EOP accepted the message or sent it through the connector. Sophos Firewall services and logs explains the log files.

Troubleshoot by symptom

External mail does not reach Microsoft 365

First check the MX record, public firewall address, TCP 25, SMTP Relay from WAN, automatic MTA rule, and Mail logs. If SFOS accepts the message but cannot deliver it, focus on DNS resolution of the tenant-specific target, the route and scan policy, TLS, and the spool.

Outbound mail bypasses the firewall

Check the connector scope, priority, and Message Trace in Exchange Admin Center. Only evaluate the SFOS relay match, policy, and public source address after the trace shows the firewall as the smart host. For multiple WAN links, see the corresponding section in Set up Mail Protection in MTA mode.

Relay is rejected or would be too broadly allowed

Compare the actual EOP source IP with the current Microsoft list and the SFOS host objects. An allowed EOP network must appear under Allow relay from hosts/networks; all other sources fall through to Block relay from hosts/networks: Any. A broad cloud or WAN allow entry is not a fix.

TLS or connector validation fails

Check the FQDN, public DNS resolution, certificate name, complete chain, validity, and STARTTLS separately. A successful openssl s_client confirms the firewall endpoint, but not the Microsoft connector scope or complete delivery. Don’t use Allow invalid certificate as a permanent workaround.

A mail loop occurs

Compare the public MX record with the target of the SMTP route and scan policy. If both point to mail.example.com, change the policy to the tenant-specific Microsoft target. Restore the documented old path until the routing is unambiguous.

Roll back safely

For rollback, first disable the Exchange Online connector or restore its documented previous state. Then restore MX and SPF and verify their public resolution. Only remove the pilot policy, EOP host objects, and relay entries on SFOS after inbound and outbound test messages work over the old path again.

Don’t blindly delete messages from the spool or quarantine. They are part of the documented transition and must be handled only after checking the sender, recipient, and intended delivery path.

Operations checklist

• Responsibilities of SFOS, Microsoft 365, and any other mail gateways are defined.
• The previous MX, SPF, connector, and mail flow are documented as a fallback.
• EOP IP objects come from the current Microsoft list and have an owner.
• SMTP Relay is usable only through tight host-based relay entries; unauthorized sources are rejected.
• The route and scan policy points to the tenant-specific Microsoft target, not back to the public MX.
• Connector, certificate, DNS, MX, SPF, DKIM, and DMARC are validated with real messages.
• Inbound, outbound, invalid-recipient, and unauthorized-relay tests pass.
• Mail logs, spool, quarantine, and Microsoft Message Trace can be correlated by time.
• EOP networks and certificate expiry are reviewed regularly.

FAQ