Set up Sophos Firewall Mail Protection in MTA mode

Sophos Firewall can not only allow email traffic as a normal firewall connection, but also work in MTA mode as a Mail Transfer Agent between the internet and the internal mail server. The firewall accepts SMTP connections, scans messages with Mail Protection and then delivers them to the defined mail server.

Today, we recommend Mail Protection on the firewall only for deliberately planned special cases, for example when a local Exchange server or another internal mail server should be protected directly through the firewall. For Microsoft 365, Google Workspace and most modern cloud mail environments, Sophos Central Email is usually the better solution. Central Email is closer to the actual mail service, integrates more cleanly with cloud mailboxes, reduces complexity in the firewall rule set and avoids many classic MTA topics such as MX changes, local spools, relay questions and troubleshooting on the firewall.

Another practical point: compared with Sophos Central Email, Email Protection on the firewall has for some time felt like an existing-environment feature that remains relevant mainly for existing on-premises mail servers. Anyone planning a new setup today should therefore first check whether a cloud mail gateway is the cleaner architecture.

This is technically powerful, but also error-prone if DNS, MX record, TLS, relay, recipient verification, policies and logs are not planned cleanly. An incorrectly configured MTA can block legitimate email, delay mailflow or, in the worst case, be misunderstood as a relay.

This article explains the practical setup for Sophos Firewall Mail Protection in MTA mode. It does not replace Sophos Central Email planning. For many Microsoft 365 or Google Workspace environments, a cloud mail gateway is often more suitable. But if a local Exchange server, a hybrid mail server or a deliberately firewall-based SMTP path is operated, a clear operating plan is needed.

When Mail Protection on the firewall makes sense

Mail Protection on Sophos Firewall is mainly useful when SMTP traffic should deliberately pass through the firewall and the firewall should do more than simply forward port 25.

Typical scenarios:

• Incoming email should first be accepted and scanned on the firewall.
• An internal mail server should not be reachable directly from the internet.
• Spam, malware, file type or content scanning should apply before delivery.
• Outgoing email should be sent in a controlled way through the firewall or a smarthost.
• Quarantine, mail spool and SMTP logs should be traceable on the firewall.

Not every mail setup should run through the firewall. If Sophos Central Email, Microsoft Defender for Office 365 or another cloud mail gateway already handles the complete mailflow, Mail Protection on the firewall should not be inserted additionally without documenting the mailflow precisely. Duplicate gateways quickly lead to unclear responsibilities for quarantine, headers, SPF/DKIM/DMARC, TLS and troubleshooting.

Distinguish MTA mode, Legacy mode and SMTP relay

With Sophos Firewall, three things must be clearly separated:

MTA mode is the normal target mode for modern firewall Mail Protection scenarios. The local SMTP Relay service, by contrast, is a Device Access topic. It should be reachable only from defined internal networks. Too broad an allowance can encourage relay abuse. Hardening local services is described in Secure Sophos Firewall access: configure Device Access correctly.

Requirements

Before setup, these points should be clarified:

• Sophos Firewall with valid Email Protection or a suitable bundle.
• Not every model supports MTA mode. XGS 87 and XGS 88 are appliances without MTA mode support.
• Public DNS zone and MX record are known.
• Internal mail server, destination port and delivery path are documented.
• Public IP address or WAN address for incoming SMTP traffic is defined.
• Firewall can route to and reach the internal mail server.
• Outgoing DNS access from the firewall works.
• Desired TLS and certificate strategy is clarified.
• Quarantine and release process is organisationally defined.

A maintenance window should be planned before changing the mailflow. Testing productive MX records without a fallback plan is risky because incoming email may quickly be delayed or rejected depending on the sender.

Define the target architecture

First, decide which direction the firewall should process.

Incoming mailflow

For incoming mailflow, external MX records point to the public address on which Sophos Firewall accepts SMTP. The firewall scans the message and forwards it to the internal mail server.

Typical sequence:

1. External sender connects by SMTP to the public MX address.
2. Sophos Firewall accepts the connection in MTA mode.
3. Mail Protection checks sender, recipient, spam, malware, attachments and policy.
4. The firewall delivers the email to the internal mail server.
5. The internal mail server delivers it to the mailbox or processes the message further.

It is important that the internal mail server does not also remain reachable unfiltered from the internet. If a DNAT rule still points directly to the mail server in parallel, part of the traffic may bypass Mail Protection. For normal server publishing, Publish a server with DNAT is the right foundation, but in MTA mode the firewall itself is the SMTP acceptance point.

Outgoing mailflow

For outgoing mailflow, the internal mail server sends through Sophos Firewall. The firewall can scan messages, forward them to a smarthost or deliver them directly, depending on the configuration.

Clarify beforehand:

• Is the public firewall IP allowed to send email directly?
• Are SPF, DKIM and DMARC correct for the selected sending path?
• Is a provider smarthost required?
• Must outgoing SMTP traffic be limited to specific internal systems?
• Where are rejected or delayed messages monitored?

For outgoing mail traffic, use a separate, traceable rule and policy structure. A general LAN to WAN rule without clear restriction is usually too broad for mail servers. The basics of rule order and security profiles are covered in Understand and build Sophos Firewall rules cleanly.

Prepare MX change and external tests

A Mail Protection change becomes critical only when external senders really use the new path. Therefore, MX record, DNS TTL, external reachability and rollback should be checked before the production switch.

Before the change:

• Document current MX record, priority and TTL.
• Reduce DNS TTL early if a quick fallback might be needed.
• Clearly distinguish the old mail path and the new Sophos Firewall address.
• Identify old direct DNAT rules to the mail server.
• Define test recipients and test senders.
• Define fallback plan: old MX, old DNAT rule or temporary smarthost.
• Prepare monitoring for spool, quarantine and mail server queue.

Useful external checks from a system outside your own network:

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

The commands do not replace a complete mailflow test, but they quickly show whether DNS, port 25 and STARTTLS are basically reachable. example.com and mail.example.com must be replaced with the real domain and the real mail host.

After switching, send an incoming test email immediately and document the full path:

• Connection visible in Log Viewer?
• Entry present in smtpd_main.log?
• Recipient verification successful?
• Delivery to internal mail server completed?
• Message arrived in the mailbox?
• No parallel direct delivery bypassing the MTA?

If the firewall accepts email but does not deliver it, the MX should not be reverted immediately. First clarify whether it is an internal routing, DNS, TLS or mail server problem. But if external senders cannot connect to the firewall or legitimate email is broadly rejected, a quick fallback to the previous mail path is often more sensible than prolonged experimentation in the production MX path.

Enable MTA mode

The basic settings are located in Sophos Firewall under:

Email > General settings

This is where the email mode is selected. For this guide, MTA mode is relevant. After switching, check whether the existing policies, host objects and mail domains still match the intended operation.

In existing environments, do not simply switch between Legacy mode and MTA mode without testing the mailflow. Processing, logs and policy logic differ. Before a migration, document the current firewall configuration, MX records, mail server connectors and relay settings.

Configure SMTP routing and domains

For incoming email, the firewall must know which domains it should accept and where it should deliver them.

Typical sequence:

1. Under Email > Policies and exceptions or the Mail Protection areas, plan the affected domains and destination servers.
2. Enter mail domain, for example example.com.
3. Define internal mail server or host object as delivery destination.
4. Check whether the firewall reaches the mail server on the destination port.
5. Check TLS requirements and certificates.
6. Send test email from external to a known recipient.

DNS is particularly important for internal mail servers. The firewall must be able to resolve internal destinations correctly, and external senders must reach the public MX entry. If internal DNS resolution plays a role, Set up DNS Request Routes on Sophos Firewall helps.

Plan policies for spam, malware and attachments

Mail Protection is only as good as the policies that actually apply. A policy should not only be created, but also named with a clear purpose.

Important policy questions:

• Which domains or recipient groups are affected?
• Is incoming, outgoing or bidirectional mail traffic processed?
• What happens with spam, malware, suspicious attachments or unwanted file types?
• Are emails blocked, quarantined, delivered or marked with headers?
• Who may check quarantine and release emails?
• Which false positive processes exist?

If Zero-Day Protection is used, suspicious email attachments can be analysed additionally. The limits, reports and release decision are explained in Understand and operate Sophos Firewall Zero-Day Protection.

Secure relay and Device Access

A common mistake is confusing MTA mailflow with an open SMTP relay. The firewall must not be usable as a relay from arbitrary networks.

Check:

• Under Administration > Device access, SMTP Relay is reachable only from required internal zones.
• If ACL Exception Rules are used, sources are tightly defined.
• Only defined internal mail servers, scanners or application servers may relay through the firewall.
• WAN, guest networks and untrusted zones do not have broad SMTP Relay access.
• Logging is active so that abuse or misconfigurations are visible.

If printers, scanners or applications need to send email, a dedicated internal relay path should be documented for them. Such systems should not speak directly to arbitrary external SMTP destinations if the environment can avoid it.

Test mailflow

After setup, one successful send is not enough. Several tests should be performed and the results documented.

Test incoming

Check at least:

• External MX record points to the expected address.
• Port 25 is reachable externally.
• Firewall accepts the connection in MTA mode.
• Email is forwarded to the internal mail server.
• Recipient exists and receives the message.
• Spam or malware test is handled as expected.
• Quarantine or log entry is traceable.

Test outgoing

Check at least:

• Internal mail server sends through the expected route.
• Firewall rule and mail policy apply.
• SPF, DKIM and DMARC match the sending path.
• Destination server accepts the message.
• Bounces or deferred messages are monitored.
• No other internal systems send directly to external destinations unexpectedly.

Check logs

Log Viewer helps with quick visual checks. For deeper analysis, the mail log files are important. The mapping is listed in Sophos Firewall troubleshooting: services and logs.

Relevant log files:

During urgent troubleshooting, note the test time, collect sender, recipient, subject, source IP and Message-ID, and then correlate Log Viewer and log files by time.

Quarantine, spool and storage

Mail Protection creates local data. Depending on volume, messages end up in quarantine, spool or temporary areas. This makes storage space, SSD health and the recovery plan more relevant than with a pure firewall rule.

Practical operating questions:

• Who checks quarantine and how often?
• How are false positives released?
• When is a message deleted instead of released?
• How is a growing mail spool detected?
• Is there monitoring for storage space and System Health?
• Is a short mailflow test planned after firmware updates?

For storage and reporting topics, Clean up Sophos Firewall storage and reports and Check Sophos Firewall SSD Health fit. In HA environments, also note that mail quarantine and processed mail data can be node-specific operational data. The HA basics are covered in Sophos Firewall HA cluster variants.

Troubleshooting

External email does not arrive

First check DNS and reachability: MX record, public IP, port 25, NAT leftovers, MTA mode and responsible mail domain. Then check in Log Viewer and smtpd_main.log whether the connection reaches the firewall. If no connection is visible, the problem is probably before Mail Protection.

Firewall accepts email but does not deliver it

Then internal mail server, routing, DNS, destination port, TLS, recipient verification or policy are more likely. Check whether the firewall can reach the mail server and whether the mail server accepts the connection. Reject logs and mail server logs should be evaluated together by time.

Many emails remain in the spool

A growing spool often points to delivery problems: internal mail server not reachable, TLS requirement does not match, DNS resolution fails or destination server rejects the message. In this case, do not only redeliver individual messages, but look for the cause in the routing and SMTP path.

An important rule order case is easy to miss: if an automatically or manually created firewall rule is above the MTA rule and matches SMTP traffic, the actual MTA rule is no longer evaluated. Emails can then remain stuck in the mail spool even though DNS, port 25 and mail server basically look correct.

Check:

1. Open Rules and policies > Firewall rules.
2. Check rules above the MTA or SMTP rule.
3. Check newly created automatic rules, IPsec rules, hotspot rules or manually Top-positioned rules.
4. Run the SMTP test again and compare Log Viewer, mail spool and smtpd_main.log.

The rule must not be moved down blindly if it serves other production purposes. The decisive question is whether it unexpectedly intercepts SMTP traffic before the MTA rule.

Quarantine digest missing for alias addresses

If users use alias addresses, quarantine settings should not be checked only for the primary email address. According to Sophos, quarantine settings are not applied automatically to alias addresses by default. If digest emails or releases are missing for alias recipients, alias addresses must be considered together with the primary address in the quarantine or user context.

Legitimate sender is detected as spam

False positives should not immediately be answered with broad exceptions. First check sender domain, SPF/DKIM/DMARC, headers, reputation, policy match and affected recipients. If an exception is necessary, it should be tightly limited and documented with a review date.

Internal systems cannot relay

Check whether SMTP Relay under Administration > Device access is allowed from the correct zone and whether the source matches the ACL. Then check mail logs. If a scanner or application should relay, the source should be documented as a host object and not an entire network enabled unnecessarily.

Mail behaves differently after firmware update

After firmware updates, MTA mode, policies, certificates, mail spool, quarantine and relevant logs should be checked. For larger updates, Check Sophos Firewall before SFOS 22 upgrade is also suitable.

Operating checklist

• Mail Protection licence and appliance support checked.
• MTA mode deliberately selected and documented.
• MX record, public IP and internal destination server are correct.
• MX change, external tests and rollback are prepared.
• No parallel unfiltered DNAT rule bypasses the MTA.
• Incoming and outgoing policies are clearly named.
• Firewall rule order does not prevent the MTA rule from applying.
• SMTP Relay is allowed only from defined internal sources.
• Quarantine and false positive process are defined.
• Alias addresses are considered in the quarantine and digest process.
• Mail spool, storage space and System Health are monitored.
• Logs are retained locally, in Sophos Central or via Syslog for long enough.
• A mailflow test is performed after firmware updates.

For longer retention and correlation with other security events, check Central Firewall Reporting or Send Sophos Firewall Syslog to SIEM.

FAQ