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.

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.

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.

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

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.

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. With recipient verification enabled, the invalid recipient must be rejected; when verification is off, a reject isn’t the expected outcome 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