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 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. Use the required Exchange Online entry for *.mail.protection.outlook.com and *.mx.microsoft on TCP 25 (endpoint ID 10 in the Worldwide instance), not the much larger set of all Exchange Online addresses. Use the corresponding list for another Microsoft cloud instance. 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 SMTP range in that Microsoft entry, for example with the prefix O365_EOP_. Don’t merge the ranges into a larger network. If SMTP is published or routed over IPv6, cover the listed IPv6 ranges as well; otherwise, make sure an unintended IPv6 path cannot bypass the IPv4 check. 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 separately defines the networks from which inbound messages for protected domains are accepted; it does not give those sources unrestricted outbound relay access.

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, go to Mail flow > Connectors > Add a connector and select Connection from: Office 365 and Connection to: Partner organization. Under Use of connector, select Only when email messages are sent to these domains and enter * to route all outbound mail through SFOS. A deliberately limited domain list must match the documented mail design. Under Routing, select Route email through these smart hosts and use the public IP address or firewall FQDN mail.example.com. These fields follow the current Sophos Microsoft 365 procedure.

Under Security restrictions, turn on Always use Transport Layer Security (TLS) to secure the connection (recommended). The Sophos procedure then selects Any digital certificate, including self-signed certificates. That choice enforces TLS but verifies neither a trusted CA nor the name. For production, follow the Microsoft connector documentation: select Issued by a trusted certificate authority (CA) and also require the subject or SAN name mail.example.com. Replace the name with the real firewall FQDN and validate it with a 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 every source that actually sends to the internet. Sophos gives v=spf1 include:spf.protection.outlook.com mx -all as a simple example: mx authorizes the MX hosts’ addresses, while include:spf.protection.outlook.com remains necessary if Exchange Online also sends directly to the internet for this domain. If all external mail invariably leaves through SFOS, don’t authorize an unused Microsoft direct path merely by habit. Never replace the existing record blindly; first inventory other sending services, subdomains, include chains, and the Microsoft-documented SPF limit of ten DNS-triggering mechanisms. Then use real message headers to confirm that SPF passes for the observed final sending IP and that DKIM and DMARC remain aligned.

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

Rollback restores the recorded previous state, not an assumed default. First restore the Exchange Online connector’s exact previous enabled state, scope, routing, and TLS settings; disable it only if it was created for this change. Then restore the recorded MX targets and priorities and the complete previous SPF TXT value. Confirm that authoritative DNS and several public resolvers return the old values.

Keep the pilot policy, EOP host objects, and relay entries in place until inbound and outbound test messages work over the old path again and the previous DNS TTL has elapsed. Then remove only the items created for this change; leave pre-existing or shared objects unchanged.

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