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 at RBL Filtering. This guide shows how I diagnosed the problem, found the offending RBLs, and fixed delivery without disabling all spam filtering.

What you see

Symptoms are repeatable and obvious. Legitimate messages fail to arrive. Users complain about missing mail from Office 365 or Google. The XGS mail log contains RBL hits and SMTP rejects.

Typical log lines you will see in 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”

Exact header examples from blocked messages:

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

Impact on email delivery is immediate. Mail is bounced or dropped at the SMTP transaction. You will see 550 responses to the sending MTA. That stops message acceptance and breaks downstream delivery. The visible failure is a hard reject, not quarantine.

User feedback often reports specific senders or providers. In my case most rejections referenced Microsoft 365 and Google outbound IPs. That points to RBL false positives rather than internal misconfiguration.

Where it happens

RBL Filtering runs in the XGS Email Protection policy that inspects inbound SMTP. It triggers during the SMTP transaction when the source IP is checked against DNSBLs. Common triggers include:

• A public MTA IP listed on one or more RBLs.
• A shared cloud mail provider IP temporarily flagged.
• An aggressive RBL such as a premium or third‑party list.

Common sources affected are large mail providers, because they use many transient IPs. The firewall log reveals the exact RBL name next to the reject. Use the XGS admin console to filter logs by “RBL” or “RBL-Block”.

Useful live diagnostic commands and expected vs actual results:

• Command: tcpdump -n -i any port 25 and look for SMTP responses.
  • Expected normal: “250 OK” on DATA end.
  • Actual when blocked: “550 5.7.1 Rejected – listed in bl.spamcop.net”
• Command: dig +short 16.42.107.13.bl.spamcop.net A
  • Expected when listed: returns 127.0.0.2 or similar.
  • Actual when not listed: NXDOMAIN

Look at the XGS logs first. If the log line names the RBL, you have the exact cause for that rejection. If logs are sparse, capture an SMTP session with tcpdump and reproduce a test from the sending provider to see the live reject.

Find the cause

Start by mapping each rejected message to its RBL hit. I follow three steps: identify the RBL entry, inspect headers for the sending path, and correlate sender IPs with the RBL results.

1. Identifying RBL entries

• Open Email Protection logs in XGS and filter for “RBL” or “RBL-Block”.
• Record the source_ip and rbl value from the log lines.
  Example saved line:
  • mail action=reject rule=RBL-Block source_ip=209.85.166.16 rbl=bl.spamcop.net

1. Investigating email headers

• Pull the raw message 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/DKIM pass but the mail was rejected, the problem is RBL classification, not authentication.

1. Correlating sender domains and IPs

• Reverse the source IP and query the RBL:
  • Example: dig +short 16.166.85.209.bl.spamcop.net A
  • If this returns 127.0.0.2, the IP is listed.
• Use whois or dig -x to confirm the IP belongs to the provider. If it is a Microsoft or Google range, treat with caution before blocking.

Root cause in my case was a reputable RBL listing cloud provider IP ranges. The firewall implemented the reject at SMTP time, so the mail never reached the internal MTA.

Fix

Fixing false positives is surgical. Do not turn off all RBL Filtering. Move only the offending parts.

Steps I use, in order:

1. Remove or disable the single RBL that caused the bulk of false positives.
   • In XGS: Protect > Email Protection > Policies > IP Reputation or RBL settings.
   • Disable the named list (for example, the SpamCop premium RBL) rather than switching off IP reputation entirely.
2. Add targeted whitelists or exceptions for trusted senders.
   • Add the sending IP or the envelope-from domain to Allowed Senders or to a bypass rule placed above RBL checks.
   • For cloud providers, use their published IP ranges rather than individual IPs.
3. Add a temporary policy to accept mail from known provider ranges while monitoring.
   • Create an accept rule for source IPs and set it to log only for a trial period.
4. Re-test with live mail.
   • Send from the affected provider and check for 250 responses.

Example of a safe DNS test used before changing policy:

• Command: dig +short 16.166.85.209.bl.spamcop.net A
  • If it returns 127.0.0.2, log the finding and then add the IP to an exceptions list for 24 hours while monitoring.

Do not wholesale whitelist all Microsoft or Google ranges without careful logging. Prefer targeted exceptions or disabling the single RBL that is misclassifying. That keeps Spam Filtering active for genuine threats.

Check it’s fixed

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

1. Verifying email delivery

• Send test messages from the previously blocked source.
• Observe SMTP session in tcpdump. Expected result:
  • SMTP server replies: “250 2.0.0 Ok: queued as “
• Check XGS logs for the message accepting event, not an RBL-Block line.

1. Collecting user feedback

• Ask the original reporter to confirm message receipt. One person’s confirmation is sufficient for the test sender.

1. Continual monitoring of logs

• Leave the added exception in place for 24–72 hours while logging is verbose.
• Monitor for any new RBL hits or unusual volume from the exceptions.
• If no new spam arrives via the exception, convert the temporary exception to a permanent allow or re-enable the RBL and rely on more targeted whitelists.

Identify the RBL from the XGS log, confirm the listing with a DNSBL query, apply a targeted exception or disable the single problematic RBL, then verify with live SMTP captures and user confirmation. That fixes False Positives while keeping Sophos Firewall Email Protection working for real threats.