Set up Sophos Firewall Mail Protection in MTA mode

In MTA mode, Sophos Firewall accepts email itself, inspects it, and delivers it to the internal mail server or the next mail hop. Mail flow only works when the MX record, automatic MTA rule, SMTP route and scan policy, relay, TLS, and recipient verification work together.

The setup has six steps: define the mail flow and fallback path, enable MTA mode, add the mail domain, create the route and scan policy, secure relay access, and change the MX record. Then validate inbound and outbound mail flow with external commands, quarantine, spool, and logs.

When MTA mode is a good fit

Mail Protection on the firewall is most useful in deliberately designed on-premises and hybrid environments where a local Exchange or another mail server must be protected. For Microsoft 365, Google Workspace, and many cloud-only environments, Sophos Email or another cloud email gateway is usually the clearer architecture. Placing two mail gateways in sequence complicates quarantine, headers, TLS, SPF/DKIM/DMARC, and troubleshooting.

If Exchange Online must deliberately use the firewall MTA, Set up Sophos Firewall MTA with Microsoft 365 explains the complete EOP, relay, connector, MX, and SPF path.

Three Sophos Firewall functions must be distinguished:

• MTA mode: The firewall accepts, inspects, and routes email.
• Legacy mode: Transparent proxy processing for an existing SMTP path. Configure Mail Protection in legacy mode explains NAT, rules, scan policies, and validation.
• SMTP Relay in Device Access: Controls the zones from which the MTA is reachable. Inbound internet email requires WAN; outbound relay is additionally restricted to specific internal mail servers.

Retrieving existing mailbox messages over POP3 or IMAP is a separate task. Scan and test POP3 and IMAP on Sophos Firewall covers TLS trust, the optional scan policy, the firewall rule, and acceptance testing.

Prerequisites include a valid Email Protection license, working routing and DNS, a known public IP address, the internal mail server and target port, and planned TLS, quarantine, and fallback strategies. According to the current Sophos overview, MTA mode isn’t available on XGS 87/87w and XGS 88/88w.

Anti-spam, RDNS, SPF, RBL, IP Reputation, and SXL2 Live Protection require internet access. Email routing, malware scanning, MIME filtering, and SPX can continue with the appropriate license in an air-gapped environment, but an active MTA doesn’t mean every protection check is available there.

Set up MTA mode end to end

1. Define the mail flow and fallback path

For inbound mail flow, the public MX record points to the address on which Sophos Firewall accepts TCP 25. The firewall inspects the message and delivers it to the internal mail server. An old DNAT rule must not leave that server directly reachable from the internet without inspection, or the MTA can be bypassed. Publish a server with DNAT explains the general DNAT logic.

For outbound mail flow, only the intended mail server sends through the firewall. The delivery path, smarthost, PTR/rDNS, HELO, SPF, DKIM, and DMARC must match the public sender identity. A general LAN to WAN rule is too broad; the rule base should clearly identify the permitted SMTP sender. Understanding Sophos Firewall rules covers rule order.

Document the following before migration:

• current MX record, priority, and TTL;
• new public firewall address and internal destination server;
• existing DNAT and SMTP rules and mail server connectors;
• inbound and outbound test senders;
• old MX record or mail path as a fallback;
• monitoring for the mail server queue, firewall spool, and quarantine.

Reduce the TTL early if a fast rollback may be necessary. Changes to the production MX record belong in a maintenance window.

2. Configure MTA mode and basic SMTP settings

Go to Email > General settings and select Switch to MTA mode if necessary. Sophos Firewall then creates the Any-to-Any rule Auto added firewall policy for MTA for SMTP and SMTPS. Don’t edit this rule, and keep it at the top of the firewall rule list. Switching to Legacy mode deletes it; switching back creates it again.

Configure the basic settings:

1. For SMTP hostname, enter the domain name, such as example.com, not the internal mail server’s hostname. The value appears in HELO and the SMTP banner for system-generated notifications.

   Check the XML API response: The SFOS 23 documentation lists status 506 with Message.AVGeneralConfInvalidSmtpNtfyHostname for the Email Configuration XML API operation. This is an operation status, not an HTTP status code. The key is unresolved, not an English error message; it does not establish specific validation rules. If this response occurs, inspect the submitted notification-hostname value, the actual operation response, and the saved configuration before assuming the change succeeded. The additional documentation row does not prove that the runtime behavior was first introduced in SFOS 23.

2. Turn on Reject based on IP reputation to reject connections from senders with a bad reputation.

3. Under SMTP TLS configuration, select a publicly trusted certificate and only allow Allow invalid certificate for documented exceptions.

4. Turn on Disable legacy TLS protocols unless documented legacy systems require otherwise. This setting disables protocols earlier than TLS 1.1; it doesn’t automatically enforce only current TLS versions.

5. Turn on Scan outgoing mails if outbound messages must also be inspected.

Use Require TLS negotiation carefully: if SFOS can’t establish the required TLS connection, it discards email to the affected destination or from the configured sender domain. The SFOS 22/23 help warns that SMTP TLS connection and validation use the domain’s IP address rather than its name, so multiple domains on one IP can cause certificate errors. Treat this as a documentation warning, not proof of the deployed certificate-matching algorithm.

Skip TLS negotiation selects remote mail hosts or networks for unencrypted SMTP connections; the documented limit is 512 host entries. It is not a remedy for a bad certificate. Allow invalid certificate is a TLS peer-validation exception, not a switch to plaintext. Do not assume precedence if require and skip lists overlap, or plaintext fallback after required TLS fails. Keep exceptions narrow and documented, and verify the actual connection and certificate outcome on the deployed build before changing them.

Define global SMTP limits before the policies

The settings under Email > General settings apply to all emails and are processed before the SMTP and POP-IMAP policies. Reject based on IP reputation therefore isn’t an individual policy action: SFOS checks the sender IP before the SMTP policy’s spam checks. Blocked senders is also global, but only blocks inbound emails.

Under SMTP settings, Don’t scan emails greater than defines the maximum message size for the global SMTP scan. 0 means 51,200 KB, not unlimited. For larger messages, Accept, Reject, and Drop are available. Accept delivers without scanning, Reject refuses and notifies the sender, and Drop discards without notification. Document this selection as a deliberate scanning gap or delivery decision and test with a message just above and below the limit.

The SMTP DoS settings limit concurrent connections, emails per connection, recipients per email, and email and connection rates. SFOS sets the maximum connections based on RAM and processor capacity. The documented defaults are 1000 emails per connection and 100 recipients per message. Derive custom values from the actual mail volume; a limit that is too low can treat legitimate distribution lists or scanners like an attack.

Under Advanced SMTP settings, SFOS can reject invalid HELO or missing RDNS and, with Do strict RDNS checks, a hostname that doesn’t resolve back to the source IP. Don’t introduce these checks together with a broad exception. First record the actual partner, newsletter, and application paths in the log and then test them individually.

An outbound banner can use Inline, no conversion, a separate MIME part, or Off. SMTP or SMTPS scanning must be active in the matching firewall rule. Because a banner changes the body and can break an existing DKIM signature, either sign after this change or explicitly verify at the recipient that the intended signature remains valid.

Before an upgrade, also record the SMTP rate limits. The documented ranges are 1–1000 emails per connection, 1–512 recipients per email, 1–1000 emails per host per minute, and 1–100 connections per host per second. The rate defaults are respectively 1000 and 100. During migration, SFOS retains supported email and connection rates but resets values above the maximum to the default. Compare the saved values after the upgrade, not just the old configuration export.

3. Add the mail domain as an Address Group

1. Open Email > Address group > Add.
2. Set Group type to Email address/domain and Type to Manual.
3. Add the protected domain, such as example.com.
4. Save the group.

When adding the group, also enter a clear Name before saving. For an existing group, use Edit in Email > Address group; start a file import with Import. RBL (IPv4) takes IPv4 addresses and RBL (IPv6) takes IPv6 addresses. Email address/domain supports manual entries or CSV/text import. RBL matching uses the connecting IP address and the action specified in the SMTP policy; the separately documented SPF/RBL rejection behavior still applies. Keep the default Premium RBL services and Standard RBL services names unchanged unless an explicitly planned change requires otherwise.

Address Groups aren’t limited to mail domains. Group type can be Email address/domain, IPv4 RBL, or IPv6 RBL. The same address can belong to more than one group, which allows separate policy targets without copying or renaming the entry.

For larger lists, SFOS can import a CSV or text file containing up to 400 addresses or domains. Invalid and duplicate entries are skipped. After the import, check the count and a few samples before assigning the group to a production policy.

New SMTP route and scan policies are designed around domains, not individual recipient addresses. Migrated individual addresses can remain effective, but they can’t be newly added or edited in current policies.

4. Create an SMTP route and scan policy

Go to Email > Policies and exceptions > Add policy > SMTP route and scan:

1. Enter a clear name, such as Inbound example.com to Exchange.
2. Under Protected domain, select the Address Group.
3. Select Route by:
   • Static host: Fixed internal mail server IP. If it fails, the firewall tries the next host in the list.
   • DNS host: A DNS name such as mailserver.example.com. Multiple A records are used across deliveries and failed servers are skipped.
   • MX: Delivery based on an MX record.
4. For Static host, select the mail server under Host list. Create its IP host under Hosts and services > IP host if required.
5. Set Global action to Accept for the domains you deliberately protect. Reject would reject all inbound and outbound messages related to those domains and notify the sender.
6. Enable Spam protection and Malware protection according to the operating policy.
7. Enable File protection and Data protection only after understanding their impact on attachments, large messages, SPX, and DKIM.
8. Save the policy.

To update an existing SMTP route and scan policy, go to Email > Policies and exceptions, select Edit for the relevant policy, change the required settings, and save the policy. Then recheck the policy match and delivery with a controlled test message.

With Route by MX, the MX resolved by the firewall must not point back to the same firewall, or a routing loop occurs. The firewall must resolve internal destinations correctly; DNS request routes help with split DNS.

The Route inbound mail through gateway option is only needed for special designs, such as destination servers in the WAN zone, applying the original firewall rule to LAN/DMZ destinations, or selecting a specific gateway with multiple internet links. Don’t enable it without a concrete routing requirement.

5. Secure inbound access and outbound relay

Under Administration > Device access, allow SMTP Relay from every zone that must reach the MTA. Inbound internet email needs WAN; outbound email additionally needs the internal mail server’s zone, usually LAN or DMZ. Then use Email > Relay settings > Host-based relay to restrict access to the specific mail servers, scanners, or applications.

Broad host or network permissions create an open-relay risk. If printers or applications must send email, document them as specific host objects. Secure Sophos Firewall access explains the Device Access fundamentals.

The allow and block lists don’t follow a deny-always-wins principle. If the same host or network appears in both lists for Host-based relay or Upstream host, SFOS allows the relay. Remove such overlaps before activation and run a negative test from a source that isn’t allowed.

An allowed host doesn’t bypass mail scanning either. If SFOS can’t scan a source IP allowed for host-based relay, it rejects it. A relay allowance therefore proves neither successful content scanning nor delivery; verify both with a real test message and the MTA logs.

The SMTP route and scan policy doesn’t support SMTP AUTH. Host-based relay is therefore the reliable option for devices. Separate Authenticated relay settings exist for users and groups, but Sophos states that they don’t support an RFC-compliant SMTP authentication standard, so client compatibility must be tested. This differs from the firewall authenticating to an upstream smarthost, for which SFOS supports PLAIN and LOGIN. Never enter an interface IP of the same firewall as a smarthost, because that creates a routing loop.

If outbound mail uses a smarthost, configure Email > General settings > Smarthost settings: select Hostname, set Port (default 25), and, only if required by that server, enable Authenticate device with smarthost and enter its credentials securely. This routes outbound mail through an intermediate MTA; it isn’t permission for clients to relay through the firewall. Keep TLS requirements and the final public sender identity consistent with that extra hop, and record the previous settings for rollback.

Upstream relay and cloud-hosted servers

Upstream host under Email > Relay settings controls which upstream SMTP sources may deliver inbound mail; Host-based relay controls the hosts permitted to use outbound relay. Configure these scopes separately. If another gateway receives public mail first, use its actual source networks in the upstream list, not the destination mail server’s address. Allow-list matches take precedence over overlapping block entries in both sections.

For a cloud-hosted server, enable SMTP Relay for its source zone, typically WAN, and restrict outbound host-based relay to the server’s actual source addresses. The cloud server must also permit the intended relay connection with the firewall. Keep the public MX pointing to the firewall separate from the delivery target resolved by SFOS: the cloud procedure mentions both MX destinations without explaining the DNS separation. Use a distinct DNS host, static target, or deliberately maintained split DNS; never let Route by MX send mail back to the firewall.

The cloud procedure also recommends switching to Legacy and back if the automatic rule is missing. This deletes and recreates the rule and changes live mail processing. Don’t use it as an unplanned repair: first record policies, queues and the fallback path, then investigate the missing rule with support. Any approved mode change belongs in a maintenance window with inbound, outbound and negative relay retests.

The older cloud and financial-data examples say to use the outgoing server name as SMTP hostname, whereas the newer MTA setup says to use the domain, not the mail server hostname. Follow the newer domain guidance for system-generated notifications; this setting does not establish the identity of every relayed message. Likewise, inbound DKIM verification uses the sender’s public DNS key and does not require you to create an outbound signing key merely because the MTA overview mentions signing alongside verification.

Multiple WAN interfaces or alias IP addresses

The MTA creates the outbound SMTP connection itself. When several public sender addresses are possible, a normal client rule therefore isn’t sufficient. Sophos distinguishes three cases: With one WAN interface and multiple alias IP addresses, create an SNAT rule with the intended public Translated source. With multiple WAN interfaces and no alias, create an SD-WAN route for SMTP, SMTP(S), and SMTPS_465. If multiple WAN interfaces and alias addresses are present, combine SNAT and the SD-WAN route.

The SNAT rule keeps the destination and service unchanged, uses the planned WAN link as the outbound interface, and translates to MASQ or the intended alias IP. The SD-WAN route uses the internet group as destination, the three SMTP services, and the intended primary gateway plus an optional backup. A backup is only useful if outbound TCP 25 is actually allowed there and that public address is also included in the mail domain’s SPF record.

For this official multiple-WAN workflow, Sophos requires the route precedence static, vpn, sdwan_policyroute and enables SD-WAN for system-generated traffic. Run these commands in the Device Console (CLI menu option 4), not in Advanced Shell. Read both initial values first, make the changes, and then verify them again:

system route_precedence show
show routing sd-wan-policy-route system-generate-traffic
set routing sd-wan-policy-route system-generate-traffic enable
system route_precedence set static vpn sdwan_policyroute
system route_precedence show
show routing sd-wan-policy-route system-generate-traffic

Route precedence is global and isn’t an isolated mail switch. Before changing it, document all overlapping static, VPN, and SD-WAN paths and both values you read. For rollback, restore the complete previous order with system route_precedence set ... and return system-generate-traffic to its initial enable or disable state. Then verify not only SMTP counters but also the source IP actually used, delivery, the SPF result, and failure of the primary gateway. Check SD-WAN routing for system-generated traffic explains the general safety and rollback process.

For the SD-WAN route, Route only through specified gateways deliberately prevents fallback to other gateways: when the selected gateways are unreachable, the firewall drops the traffic. Decide whether this is preferable to an unplanned sender IP, and test that failure path. Select IPv4 or IPv6 objects appropriate to the actual published mail path; don’t copy an IPv4 internet group into an IPv6 design.

6. Change the MX record

Only change the public MX record to the firewall address after the MTA rule, domain, policy, relay, and internal delivery path are ready. Immediately send an external test message and verify that it appears in Log Viewer or Mail logs, is delivered to the internal server, and reaches the mailbox.

If external senders can’t reach the firewall or legitimate messages are broadly rejected, restore the documented previous mail path. DNS caches mean that this rollback isn’t effective everywhere immediately. Keep both the old and new paths operational in parallel and monitor them until at least the longest previously valid TTL has expired. If the firewall accepts messages but can’t deliver them, first check routing, DNS, TLS, recipient verification, and mail server logs.

Choose protection settings deliberately

Spam, malware and data actions

For inbound spam, probable spam and bulk mail, choose the action explicitly: None delivers unchanged, Warn adds the configured subject prefix, Quarantine holds the message, and Drop discards it without notifying the sender. Set the spam and bulk subject prefixes as required. These choices don’t override the separate SPF/RBL rejection behavior.

For malware, Selected antivirus action offers None, Drop and Quarantine; configure Notify sender separately. Quarantine unscannable content covers content that cannot be inspected, including corrupt, encrypted or compressed files, oversized messages and internal scan errors. A completed delivery is not proof that all attachments were scanned. Zero-Day Protection has its own maximum analysis size: larger files are not analyzed by that service. Test this limit separately from global SMTP size and file-protection drop limits.

Under Data protection, select the exact Data control list, its action and, if applicable, its SPX template: Accept delivers, Accept with SPX encrypts and delivers, and Drop discards without notification. Notify sender is a separate choice. A domain-level SPX assignment encrypts all matching outbound mail; use a Data Control trigger when only financial-data matches should be encrypted. The recipient-password example uses Specified by recipient and holds the message until password registration. Configure the template, Reply Portal and registration path together in the linked SPX runbook, then test a matching and a non-matching message rather than enabling Data protection alone.

Use custom file types and Data Control Lists

In MTA mode, create a custom file type under Email > Policies and exceptions > File type > Add from a template or from file extensions or MIME types. Enter extensions without a leading dot. Only custom file types can be edited. A newly created type also isn’t added automatically to existing policies: open the specific SMTP route and scan policy, add it under File protection, and save the policy again. A positive attachment test and a similar negative test prove the match more reliably than the object name alone.

Under File protection > Block file types, All blocks emails with attachments; it does not mean scan all attachments. None permits attachments under this file-filter setting, but does not bypass malware, spam, data protection or other checks. The policy help says selected MIME headers populate the MIME whitelist, allowing those types and blocking the remaining types. MIME headers and extensions do not prove harmless content. Verify allowed and blocked attachments on the deployed build before applying a precise whitelist recipe.

A Data Control List consists of Content Control Lists, or CCLs, for defined content types such as financial or personal data. When adding one under Email > Data control list > Add, filter CCLs by Type and Region and select only the entries that are actually needed. The action is defined only in the linked policy. Test one controlled match and one similar non-match to confirm that match and action work together without unnecessary false positives.

Spam protection is more than the action applied to spam. SPF and RBL failures are rejected directly and don’t follow the normal actions for spam or probable spam. Greylisting intentionally rejects a message temporarily and requires the sending server to retry.

For Reject based on BATV, first configure a shared BATV secret under Email > General settings > Advanced SMTP settings. Use the same secret on multiple MX systems belonging to the organization. SFOS combines it with the timestamp and sender address to create the return-path signature, which expires after seven days. Therefore, check a BATV error against the secret, system time, sender path, and signature age instead of hiding it with an unlimited broad exception.

Recipient verification prevents messages to unknown recipients:

• With callout: Queries the destination mail server. If it is temporarily unavailable, SFOS accepts recipients after a defined period instead of permanently blocking all mail flow.
• In Active Directory: Checks over Simple, SSL, or STARTTLS and has a 30-second timeout. Specify the AD server, Bind DN and Base DN. Bind DN is the full distinguished name, including the CN of the configured bind identity; Base DN is the starting point for directory searches. Use values appropriate to your directory. The help’s administrator example does not establish a requirement for Domain Admin privileges. Select a transport that meets the deployed trust and security policy; an SSL or STARTTLS label alone does not prove successful certificate validation.

Malware Protection can use single or dual antivirus scanning. To use Zero-Day Protection with single-antivirus scanning, set Sophos as the primary engine. Sophos Firewall Zero-Day Protection explains its limits and release decisions.

According to the SFOS 22/23 policy help, Single antivirus selects the primary engine for inbound mail only; outbound mail uses both engines. Dual antivirus scans with the primary engine and then the secondary engine. Select the primary engine, Sophos or Avira, globally in Email > General settings. Choosing Avira turns off Zero-day protection in SMTP policies using single-antivirus scanning; Sophos must be primary to use Zero-Day Protection with a single scan. The general-settings help describes single scanning generically as primary-engine-only, without the policy table’s direction distinction. This documentation difference is not proof of observed engine use: verify the deployed build, policy, mail direction and protection state before and after a change. Record the previous settings; restoring the engine choice does not establish that Zero-day protection was re-enabled.

The Drop message greater than policy limit under File protection isn’t the same as the global oversize behavior: larger messages are discarded at this point. SFOS also checks visible content and content in packaged formats such as docx, xlsx, pptx, odt, ods, odp, and odg. A positive test using only an unpackaged text file therefore doesn’t prove how the same information is handled inside an Office document.

With DKIM verification enabled, SFOS distinguishes a hash mismatch, an invalid signature or unavailable public key, and a missing DKIM signature. Accept, Quarantine, or Reject can be selected for each result. According to Sophos, DKIM-signed messages using RSA-SHA1 or a key outside 1024 to 4096 bits are quarantined. Test this inbound verification separately from outbound signing.

For outbound messages, processing order matters. SPX encryption, subject prefixes, File or Data Protection, and outbound banners can modify the header or body after an existing DKIM signature was added. DKIM validation then fails at the recipient. Decide whether the internal mail server, Sophos Firewall, or a later gateway signs messages.

Sign outbound messages with DKIM on the firewall

If Sophos Firewall is to sign messages itself, add a signature for each sender domain under Email > General settings > DKIM signing > Add. Domain is the FQDN of the mail domain; Key selector is the exact selector that is subsequently published in public DNS. A name such as fw01 or zurich makes later key rotations easier to understand but isn’t a security feature.

SFOS expects a private RSA key from 1024 to 2048 bits between -----BEGIN RSA PRIVATE KEY----- and -----END RSA PRIVATE KEY-----. For new configurations, 2048 bits is the sensible choice. Don’t use RSA-SHA1. According to Sophos, the firewall doesn’t accept a 1024-bit key generated with PuTTYgen, so select 2048 bits there as well. The private key belongs only on the firewall and never in DNS, tickets, or public documentation.

After saving, publish the DKIM TXT record for the selector with the public key at the authoritative DNS provider. Only after this record resolves externally should you send a new test message through the intended outbound MTA path. The received message header must contain the expected selector and domain, and DKIM verification at the recipient must succeed. If the signature is missing, check the sender domain, policy match, and Scan outgoing mails. If verification fails, first compare the DNS record, selector, key in use, and later changes by SPX, banners, File Protection, or Data Protection.

Set up and test SPX email encryption explains how the template, trigger priority, password model, and Reply Portal work together.

Safely automate MTA settings via the XML API

For automation, global settings, Address Groups and SMTP policies remain separate targets. First read the build, active mail mode, saved values and dependent policies; prepare a backup and a targeted rollback path. Send the confirmed request with an explicit operation only for the required target. Afterwards, compare the operation response, the state read back and the appropriate mail flow test. Even after an error or timeout, first read back whether anything has already been saved rather than blindly repeating the write request. Secure XML API access explains access, secret storage and response evaluation.

The SFOS-22/23 object references are not ready-to-use production payloads. XML examples, parameter tables and WebAdmin help may specify different spellings, values or defaults. Empty default cells or Any confirm neither a safe empty value nor the behaviour of omitted fields. Unresolved $EMAILPROTECTION{…} constants are not confirmed API literals. If syntax, operation or effect is unclear, stop before writing and consult the installed build’s API help or obtain official clarification. Documentation differences alone do not establish a product change.

Keep global SMTP, TLS and relay settings separate

In EmailConfiguration, the SMTP scan limit and DoS values belong under SMTPSSettings, and the separate POP/IMAP values under POPIMAPSettings. The identically named DontScanEmailsGreaterThan must not be assigned to the wrong protocol. RecipientHeaders with repeated Header entries concerns POP/IMAP recipient detection, not SMTP routing. Banners are under GeneralSettings. Likewise, SMTPTLSConfiguration and POPSIMAPTLSConfiguration are separate contexts: TLSCertificate, AllowInvalidCertificate and DisableTLS1 cannot be addressed unambiguously using a single unqualified field name. An SMTP exception must not also relax POP/IMAP controls unnoticed. After saving, read back both contexts separately and test only the intended mail path.

According to the API table, BypassSpamCheck under SMTPSSettings describes bypassing spam scanning for authenticated traffic. The table specifies a default of Disable, whereas the XML example sets it to Enable. Do not adopt the example as a safe default configuration: before making a change, clarify which traffic is considered authenticated in the specific build and which spam check is bypassed. Keep any intended exception narrowly scoped and test its effect on matching and non-matching messages; do not assume that other scanning areas are automatically exempt.

The source of the SMTP figures matters: the API table specifies for DontScanEmailsGreaterThan a value of 1024 KB, for MaximumConnections a value of 5000 within the range 1–20000, and for MaximumConnectionsHost a value of 100 within the range 1–10000. For MaximumEmailsConnection, it specifies a default of 100, whereas the XML example uses 1000; the WebAdmin help also specifies 1000. MaximumRecepientsEmail is the spelling used in the source, with a default of 100 and a range of 1–512. For EmailsRate and ConnectionsRate, the API table specifies defaults of 1000 and 100, both with a range of 1–20000; the WebAdmin help instead limits the rates to 1–1000 per minute and 1–100 per second respectively, and determines connection maxima based on the hardware. Therefore, do not adopt table maxima as current UI limits or example values as defaults. The WebAdmin limits and upgrade checks described above remain authoritative for this workflow; automation must reconcile the values actually saved on the build.

Further syntax conflicts prevent blind imports of examples: VerifySendersIPReputation shows Enable in the XML example, but the API table specifies on/off with a default of Disable; SMTPSDosSettings is described there as an integer with a default of Disable, but appears as Enable in the example. For the banner, example text contrasts with the table values inline_plain, mimepart, off. Do not “repair” these details yourself; confirm the valid spelling and values before sending a request. Observe the existing note on Email Configuration, status 506, separately.

AdvancedSMTPSetting is also global. RejectInvalidHELOorMissingRDNS, DoStrictRDNSchecks and ScanOutboundEmails control the HELO/RDNS and outbound checks explained above. FirewallRelateInboundMails concerns the separate gateway/firewall rule path; the example specifies Disable, while the table specifies Turn on/Turn off. For the BATV secret, the example shows BATVSecret, whereas the table shows BATVsecret. Confirm case and valid values in the installed build before constructing a write payload. Use the shared secret from protected storage; do not copy the example secret or any secret into a ticket, repository or request log. Plan secret changes across all affected MX systems, then check BATV and normal sending.

In RelaySettings, HostBased and UpstreamHost each have their own AllowRelay and BlockRelay lists. These contain HostsOrNetworks and repeated HostsOrNetwork entries. The same leaf name therefore does not mean the same relay scope. AuthenticatedRelaySettings separately contains AuthenticatedRelay and UsersOrGroups with UsersOrGroup. The open or guest groups shown in the vendor example are not a safe selection. Use only the planned identities and host objects, remove list overlaps, then test permitted sending and unauthorised relay from a separate source.

In SmarthostSettings, UseSmarthost enables the outbound intermediate hop; SmarthostList with repeated Hostname entries selects the destinations, and Port selects the destination port. The API table specifies 1–65535, but no port default; 25 appears in the example and as the default in the WebAdmin help. AuthenticateDevicewithSmarthost is separate: securely provide Username and Password only if authentication is required. The API table specifies Disable as the default for both enablement switches, whereas the example enables both. passwordform="encrypt" is the password syntax used in the example, not permission to reuse encrypted values from another firewall. Stop the request if provenance or import requirements are unclear. Afterwards, check the destination, TLS, authentication and delivery through this hop, not just relay permission.

Make targeted changes to Address Groups and SMTP policies

For the MTA, the example object is MTAAddressGroup, not the similarly named AVASAddressGroup from the other mail context. Name identifies the group. GroupType determines the appropriate list: the API table distinguishes RBLIPv4, RBLIPv6, IPAddress and EmailAddressOrDomain, along with the entry fields RBLName, IPAddressNetwork and EmailAddressDomain. The mail domain example uses EmailAddressList with repeated EmailAddressDomain entries and EmailImportType set to Manual. For Import and EmailAddressFile, clarify the file upload procedure appropriate to the build: the description inconsistently assigns the file field to manual import. HTTP success confirms neither all imported entries nor the final group membership. Read back the count, skipped entries and specific domain values before a policy uses the group.

For Delete Address Group, the SFOS-22/23 pages provide status rows, but no parameter definition or deletion example. Neither the exact Remove object identity nor a working request can be derived from this. Do not simply insert Name or the creation object into a Remove payload. First check usage in mail, spam and archiving configurations; obtain the exact operation and its complete request from the installed API help or through official clarification. Until then, do not perform automatic deletion. After an approved deletion, check again that exactly the intended group has been removed and that required references and mail flow remain intact.

In SMTPPolicy, Name is the policy identity; DomainList with DomainName binds the protected domains. RouteBy, DNSHostName and RouteList with HostName, routingid and routingorder describe different delivery paths, not additional domain names. The API table specifies MX as the route default, but the example contains alternative route text rather than a single value. Check routing against actual DNS resolution beforehand to prevent a loop back to the firewall.

The nested sections SpamProtection, MalwareProtection, FiletypeFilter and DataProtection have independent status fields. The API table specifies OFF as their default, although the example sets them to ON. A global action of Accept therefore does not automatically enable all checks. Likewise, the domain SPX field SPXEncryption and the match-specific DataProtectionSPXTemplate are not interchangeable; DataProtectionPolicy must reference an existing, appropriate Data Control List. Check engine, Zero-Day and BATV prerequisites, and the SPX password model, beforehand. The table describes recipient verification as outbound, while the WebAdmin help describes it as inbound; do not infer a new verification direction from this. Direction-specific positive and negative tests and saved policy values determine whether the planned protection design has been implemented.

For the Data Control List, the XML example shows MTADataControlList, containing Name and Signatures with repeated Signature entries. The table labels name and signaturename are not confirmed instructions to serialise these as lowercase XML tags. Confirm MTA mode beforehand, read the available signatures and select only appropriate CCLs. The list alone does not create a protection action: only the binding through DataProtectionPolicy and the action in the SMTP policy implement the design. Afterwards, read back the list and binding, and test a controlled match and a similar non-match.

Do not equate DKIM and exceptions with routing

In DKIMVerification, VerifactionStatus, actually spelt this way in the example, controls enablement. ActionForVerifactionFail is a different selector from ActionForSignatureInvalid or ActionForSignatureNotFound: the first concerns hash/signature verification failures, the second a missing or syntactically invalid public DNS key, and the third a missing signature. Do not silently correct the spelling errors in the first two tags. The XML example specifies Pass, whereas the parameter table and WebAdmin help specify Accept alongside Quarantine and Reject. This does not confirm interchangeable API values; clarify the build’s API contract before sending a request and test all three inbound cases separately.

In DKIMSigning, Domain identifies the signing domain, not Name; the deletion reference also requires Domain. When adding or editing, KeySelector and PrivateRSAKey are mandatory fields. According to the WebAdmin help, a domain can have multiple signatures, whereas the deletion reference specifies only the domain: if multiple selectors exist, clarify the exact deletion scope beforehand rather than assuming selector-specific deletion. Store private keys and API credentials securely and remove them from responses and logs; afterwards, check DNS and the newly received signature as described above.

The global inbound list uses MtaBlockedSenders with BlockedEmailAddresses and repeated EmailAddress entries; the API table permits individual addresses or wildcard domains such as *@example.com. This list does not replace a complete anti-spam policy and applies only to inbound messages in the MTA context described here. Read the scope and existing entries before making a change, then test a matching and a non-matching sender.

Separately, the API describes AntiSpamTrustedDomain with DomainList and repeated DomainName entries as an exception for bypassing mail scanning for trusted domains. This source does not specify exactly which scanners are bypassed. Therefore, do not invent a GUI path, guarantee that “all scans are off”, or confuse trusted domains with protected routing domains. Before adding or removing entries, clarify the exact domain list, required exception and scanning effect on the installed build; keep the scope narrow and verify it with a review date and matching and non-matching messages.

For Delete Trusted Domain, the parameter table specifies DomainName as a mandatory array that can contain multiple values, but provides no deletion example. Therefore, do not adopt the nesting shown in the Add example for a deletion request without verification; confirm the target values and complete request structure beforehand in the installed API help or through official clarification.

The global engine selector is MalwareProtection with PrimaryAntiVirusEngine, whose default in the API table is Sophos. It is not the identically named nested policy element and does not itself enable the scanning sections. Check the effects on single/dual scanning and Zero-Day Protection in the affected policies before and after a change, as described above.

Use object-specific responses to aid diagnosis

The following mappings come from the SFOS-22/23 status rows. The numbers are XML operation codes, not HTTP codes; Message.* identifiers are unresolved source keys, not confirmed message text or unambiguous error causes. The general API safety guidance above also applies here: reconcile the actual response with the saved state before every retry, do not remove dependencies speculatively, and stop if a partial state is unclear.

• Add Address Group: 502 → Message.AddrGrpRecordExists, 541 → Message.AddrGrpImportFailed, 542 → Message.AddrGrpEmptyFile1, 543 → Message.AddrGrpSomeEmailNotImported. The last three rows make import reconciliation particularly important; do not assume that the entire file was rejected or accepted. Edit Address Group lists only 200 → Message.AddrGrpUpdateSuccess and 500 → Message.AddrGrpUpdateFail in these sources; do not present the Add codes as documented Edit responses.
• Delete Address Group: 504, 505 and 506 each refer to Message.AddrGrpForeignKeyExists; 507 refers to Message.AddrGrpEmailArcKeyExists. The identical symbolic mapping does not determine which reference is affected. Check usage and the actual groups present; these responses do not replace the missing deletion contract.
• Add Data Control List and Update Data Control List: each lists 502 → Message.DLPAddSameName and 545 → Message.MTAModeDisableCheck. The Update key also contains “Add”; do not rename it. Check names, mode and the saved list without determining a cause from the key alone.
• Add SMTP Policy and Edit SMTP Policy: each lists 541 → Message.SMTPProfileduplicatedomain, 542 → Message.DomainDuplicateCheck and 545 → Message.MTAModeDisableCheck. Only Add SMTP Policy lists 502 → Message.SMTPProfileduplicateName. For 543, the source distinguishes Message.SMTPProfileSenderGenSPXAdd for Add and Message.SMTPProfileSenderGenSPXEdit for Edit. Check domain bindings, names, mode and SPX dependencies against the actual state; do not trigger automatic renaming or relaxation of protection.
• Email Configuration: 505 → Message.ASConfigSubOperationFail appears in both versions. Before a retry, read back all affected SMTP, POP/IMAP and TLS subsections; do not assume complete success or a complete rollback. The additional SFOS-23 row 506 → Message.AVGeneralConfInvalidSmtpNtfyHostname remains subject to the qualifications above.

Validate mail flow

Run these commands from a system outside your own network:

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

Replace example.com and mail.example.com with the real values. These commands test DNS, TCP 25, and STARTTLS, but not relay authorization or complete delivery. openssl s_client remains interactive after the handshake; stop it with Ctrl+C.

Test at least these cases:

• external message to a valid recipient;
• with Recipient verification enabled, an external message to an invalid recipient;
• outbound message through the intended mail server;
• spam or malware test appropriate for the policy;
• STARTTLS and the presented certificate chain;
• quarantine action and delivery after release;
• blocked relay attempt from an unauthorized source;
• no direct delivery bypassing the MTA through an old DNAT rule.

Record only observed acceptance results: The valid test message must show Delivered in Mail logs and be traceable by Message-ID to the destination mailbox. Expect the invalid recipient to be rejected only when recipient verification is enabled, the selected verification method is functioning through a reachable authoritative verification path, and rejection is configured. For With callout, distinguish this negative test from the documented exception: SFOS accepts recipients when the destination mail server is unreachable for a specified duration. The documentation does not specify that duration; do not assume the same exception for In Active Directory. With verification disabled, rejection is not the expected result of this negative test. The unauthorized relay attempt must not create a message, and releasing the quarantined message must show subsequent delivery for the same Message-ID.

For the first review, use Email > Mail logs, Email > Mail spool, Email > SMTP quarantine, and Log Viewer. For deeper analysis, record the test time, sender, recipient, subject, source IP, and Message-ID, and correlate them with these files:

• MTA: smtpd_main.log
• rejects: smtpd_reject.log
• scan errors: smtpd_error.log
• internal MTA errors: smtpd_panic.log
• anti-spam: sasi.log
• legacy SMTP proxy: awarrensmtp.log
• POP/IMAP proxy: warren.log

Sophos Firewall services and logs explains the mapping and Advanced Shell access.

In Mail logs, Result identifies the delivery status, while Reason describes the scan or policy reason. Rejected means SFOS discarded the message and notified the sender. Dropped discards it without notification; Bounced appears after several failed delivery attempts. Don’t treat these states as equivalent because they produce different feedback and troubleshooting paths. Other results include Delivered, Quarantined, and manually Deleted; reasons can be filtered for Malware, Spam, File filter, Unscannable, Data protection, SPX, SPF, RBL, Zero-day protection, DKIM, and BATV, among others.

Operate quarantine and the mail spool

Under Email > SMTP quarantine, filter by time, sender, recipient, subject, and quarantine reason:

• Release: Deliver the message.
• Delete: Delete the message.
• Release and report: Release and report only false positives classified as Spam or Probable spam to SophosLabs.

Virus-infected messages and messages classified as malicious by Zero-Day Protection can’t be released. Deleting Zero-Day Protection entries requires write permission for that function. When quarantine is full, older messages are purged.

Only users who have authenticated with the firewall at least once receive quarantine digests. By default, SFOS doesn’t apply digest settings to alias addresses; assign them with the primary address under Email > Quarantine settings > Change user’s quarantine digest settings or on the user object. The digest can then include spam sent to primary and alias addresses. Messages sent to aliases still don’t appear in the User Portal itself.

Set up and test the Sophos Firewall quarantine digest explains configuration, user assignment, the release link, and complete functional testing.

Email > Mail spool contains messages that haven’t yet been delivered or have failed. SFOS retries delivery for three days and discards messages after another four days; discarded messages remain visible in Mail logs. A growing spool is therefore an alert for routing, DNS, TLS, policy, or mail server problems, not a reason to repeatedly select Retry without diagnosis.

The status filter distinguishes Queued, Failed, SPX blocked, Zero-day protection, and Error. SPX blocked waits for the recipient to create a password; Zero-day protection waits for analysis. Only messages in the error queue can be downloaded or deleted. Deleting or retrying Zero-Day Protection messages requires read-write permission for Zero-Day Protection Activity. If a button is missing, first compare the status and administrator profile instead of working around it with a service restart.

Quarantine and spool use local storage. Monitor free space, SSD status, and System Health; see Clean up storage and reports and Check SSD Health. In HA, logs and reports are separate for each node and aren’t synchronized, so check both nodes. Sophos Firewall HA clusters covers the fundamentals.

Troubleshooting

External email doesn’t arrive

Check MX, A/AAAA, public IP, TCP 25, and SMTP Relay from WAN. Then verify that MTA mode is active, the protected domain matches the policy, and no old DNAT or higher-priority firewall rule changes the expected path. If smtpd_main.log shows no connection, the problem is probably before Mail Protection.

The firewall accepts email but doesn’t deliver it

Check the internal mail server, route, DNS, target port, TLS, and recipient verification. Static host, DNS host, and MX use different resolution and failover paths. Correlate the firewall’s reject and error logs with the mail server logs.

Many messages remain in the spool

First inspect Email > Mail spool and the MTA logs. A common cause is a rule above the automatically generated MTA rule that already matches SMTP. Under Rules and policies > Firewall rules, check new rules positioned at Top, automatically generated IPsec or hotspot rules, and other overlaps. Don’t move a rule blindly; its actual SMTP match is what matters.

Only after the new overlapping rule has been confirmed as the cause, move it far enough down under Rules and policies > Firewall rules for the intended SMTP rule to be evaluated again. Then retest delivery and the spool with a controlled message; other required connections must continue to use their intended rules.

NC-177930 was fixed in SFOS 22.0 MR2: messages remained in the spool after a mailpoller crash. Include the firmware version in the diagnosis when the issue occurs on an older release. Use the SFOS 22 upgrade check to decide on the target build, prepare the change, and retest mail flow afterwards.

Sophos Fusion reports Invalid API request

On SFOS 22.0 MR1, Release and Delete could fail when the firewall was opened through Sophos Fusion (formerly Sophos Central). The Invalid API request symptom is tracked as NC-182056; NC-181904 identifies the fix for failed release through Sophos Fusion. The safe workaround is to sign in directly to the local WebAdmin and perform the action under Email > SMTP quarantine. SFOS 22.0 MR2 Build 546 fixes the issue. If it still fails there, check the admin profile, Sophos Fusion access, and local permissions separately. For an update, follow the complete approval, preparation, validation, and troubleshooting process in Sophos Firewall firmware update: preparation and best practices.

Reject based on RBL can’t be enabled

NC-144563 is a version-specific case for SFOS 20.0.2 MR2 Build 378: If the default RBL groups under Email > Address group have been renamed, Reject based on RBL can’t be enabled when creating an SMTP route and scan policy. In an existing policy, the option can’t be turned on again after it has been disabled. No fixed version is documented.

The default groups are named Premium RBL services and Standard RBL services. First document the exact build and current group names. If both conditions match, restore the original names of the default RBLs, reopen the policy, and check the option. Don’t confuse custom RBLs with these two system groups.

On other builds, or when the default names are unchanged, a grayed-out option doesn’t prove NC-144563. Check the policy type, Spam protection, Email Protection license, and the remaining configuration separately.

A legitimate sender is classified as spam

Check the sender domain, SPF/DKIM/DMARC, headers, reputation, policy match, and affected recipients. Only then create a narrow exception with a review date. Create and test email exceptions safely covers the complete scope, testing, and rollback workflow.

Internal systems can’t relay

Check the source zone under Administration > Device access, the host object under Email > Relay settings > Host-based relay, and the MTA logs. If a scanner expects standard SMTP AUTH, Host-based relay is usually more reliable. Test the separate, non-RFC-compliant Authenticated relay with the specific client.

Operations checklist

• License, model support, DNS, and required internet services are verified.
• MX, TTL, public and internal mail paths, and rollback are documented.
• The automatic MTA rule is unchanged and remains at the top.
• No old DNAT rule bypasses Mail Protection.
• Address Group, routing destination, and policy match are tested.
• Inbound SMTP Relay from WAN and outbound host permissions are separated correctly.
• The effects of SPF/RBL, recipient verification, TLS, DKIM, SPX, and banners are understood.
• External positive and negative tests were completed.
• Quarantine, spool, storage, and logs are monitored.
• Mail flow is retested after firmware updates.

For longer retention and correlation, use Central Firewall Reporting or send Sophos Firewall logs to a SIEM.

FAQ