Resolving false positives in Sophos Firewall Email

I run Email Protection on a Sophos XGS to protect an on-prem mail server. Recently, legitimate mail started getting rejected. The pattern pointed to RBL filtering. This guide shows how I tracked down the problem, found the RBLs involved, and fixed delivery without turning off spam filtering altogether.

What you see

The symptoms are hard to miss. Legitimate messages do not arrive. Users complain about missing mail from Office 365 or Google. The XGS mail log shows RBL hits and SMTP rejects.

Typical log lines from the XGS Email Protection log:

• mail action=reject rule=RBL-Block source_ip=13.107.42.16 rbl=bl.spamcop.net message="Listed in RBL"
• smtp response="550 5.7.1 Rejected - listed in bl.spamcop.net"

Blocked messages can also show headers like these:

• Received: from mail-ol1-f16.google.com (209.85.166.16)
• X-Sophos-RBL: bl.spamcop.net listed

The impact is immediate. Mail is bounced or dropped during the SMTP transaction. You get 550 responses to the sending MTA, so the message never reaches the internal mail server. This is a hard reject, not quarantine.

In my case, the rejections mostly pointed at Microsoft 365 and Google outbound IPs. That points to RBL false positives rather than a local mail problem.

Where it happens

RBL filtering runs in the XGS Email Protection policy that inspects inbound SMTP. The source IP is checked against DNSBLs during the SMTP session. Common triggers include:

• A public MTA IP listed on one or more RBLs.
• A shared cloud mail provider IP that has been flagged.
• An aggressive third-party RBL.

Large mail providers are the usual pain here because they use a lot of transient IPs. The firewall log shows the exact RBL name next to the reject. Use the XGS admin console to filter logs for RBL or RBL-Block.

Useful checks:

tcpdump -n -i any port 25

Expected on a healthy session:

• 250 OK at the end of DATA.

When blocked, you will see:

• 550 5.7.1 Rejected - listed in bl.spamcop.net

dig +short 16.42.107.13.bl.spamcop.net A

Expected when listed:

• 127.0.0.2 or similar.

Expected when not listed:

• NXDOMAIN

Start with the XGS logs. If the reject line names the RBL, that is the cause for that message. If the logs are thin, capture an SMTP session with tcpdump and reproduce a test from the sending provider to see the live reject.

Find the cause

Map each rejected message to the RBL hit. I worked through it in three steps: identify the RBL entry, check the message headers, and compare the sender IP with the DNSBL result.

1. Identify the RBL entry

• Open Email Protection logs in XGS and filter for RBL or RBL-Block.
• Record the source_ip and rbl values from the log line.

Example log line:

• mail action=reject rule=RBL-Block source_ip=209.85.166.16 rbl=bl.spamcop.net

1. Check the message headers

• Pull the raw headers from the sender or quarantine. Look for Received lines and authentication results:
• Received-SPF: pass (google.com: domain of example@gmail.com)
• Authentication-Results: dkim=pass; spf=pass
• If SPF and DKIM pass but the mail was rejected, the issue is RBL classification, not authentication.

1. Compare sender domains and IPs

• Reverse the source IP and query the RBL:

dig +short 16.166.85.209.bl.spamcop.net A

• If that returns 127.0.0.2, the IP is listed.
• Use whois or dig -x to check that the IP belongs to the provider. If it is a Microsoft or Google range, treat it carefully before blocking it.

In my case, the root cause was a reputable RBL listing cloud provider IP ranges. The firewall rejected the mail at SMTP time, so nothing reached the internal MTA.

Fix

Fixing false positives is surgical. Do not turn off all RBL filtering. Deal with the part that is causing the damage.

The steps I used were:

1. Remove or disable the single RBL that caused the bulk of the false positives.
2. In XGS: Protect > Email Protection > Policies > IP Reputation or the RBL settings.
3. Disable the named list, such as the SpamCop premium RBL, rather than switching off IP reputation completely.

1. Add targeted whitelists or exceptions for trusted senders.
2. Add the sending IP or envelope-from domain to Allowed Senders, or use a bypass rule placed above the RBL checks.
3. For cloud providers, use their published IP ranges rather than one-off addresses.

1. Add a temporary policy to accept mail from known provider ranges while you watch the logs.
2. Create an accept rule for source IPs and set it to log only for a trial period.

1. Re-test with live mail.
2. Send from the affected provider and check for 250 responses.

One safe DNS check before changing policy:

dig +short 16.166.85.209.bl.spamcop.net A

If it returns 127.0.0.2, log the result and add the IP to an exception list for 24 hours while monitoring.

Do not whitelist all Microsoft or Google ranges without logging. Use targeted exceptions, or disable the single RBL that is misclassifying the mail. That keeps spam filtering in place for actual threats.

Check it’s fixed

Verification has three parts: message flow, logs, and user confirmation.

1. Verify email delivery
2. Send test messages from the previously blocked source.
3. Watch the SMTP session in tcpdump. The expected response is:

• 250 2.0.0 Ok: queued as

1. Check the XGS logs for an accepting event, not an RBL-Block line.

1. Get user confirmation
2. Ask the original reporter to confirm the message arrived. One confirmation is enough for the test sender.

1. Watch the logs for a while
2. Leave the exception in place for 24–72 hours while logging is verbose.
3. Watch for new RBL hits or odd traffic through the exception.
4. If no new spam arrives, make the exception permanent or re-enable the RBL and rely on narrower whitelists.

Identify the RBL from the XGS log, confirm the listing with a DNSBL query, apply a narrow exception or disable the bad list, then verify with live SMTP captures and user confirmation. That fixes the false positives without gutting Sophos Firewall Email Protection.