InboxGrade

Listed on Spamhaus XBL (Exploits Block List)

Your sending IP is listed on the Spamhaus Exploits Block List because it is emitting traffic consistent with an open proxy, trojan, worm, or other compromised host.

Impact — Critical impact

XBL is one of the most widely consumed DNSBLs on the internet — it is bundled into Spamhaus ZEN, which is used by Gmail, Microsoft 365, and virtually every commercial filter. While listed, SMTP sessions will be rejected at RCPT TO with 5xx errors referencing xbl.spamhaus.org, and bounce logs will show 554 5.7.1 Service unavailable; Client host [1.2.3.4] blocked. Because XBL implies active compromise rather than policy complaints, remote MTAs treat it as a hard block, not a soft reputation signal.

What causes it

  1. A host sharing the IP (or the IP itself) is infected with a spam-sending trojan such as a Cutwail, Gamut, or Emotet variant and is emitting mail directly on port 25.
  2. An unauthenticated or misconfigured service — open SOCKS/HTTP proxy, open SMTP relay, or exposed sendmail/Postfix instance — is being abused by third parties to relay traffic.
  3. A compromised CMS (WordPress, Joomla) or PHP mailer script on the server is being used by an attacker to send bulk mail via mail() or direct SMTP.
  4. The IP was recently allocated or reassigned by the hosting provider and inherited the prior tenant's XBL listing (CBL history carries over on the same /32).
  5. An IoT device, printer, or developer workstation behind the same NAT egress is beaconing to a known botnet C2, which XBL/CBL detects via sinkhole data.

How to fix it

Confirm the listing and read the exact reason

Query Spamhaus directly for the reverse-notation IP against xbl.spamhaus.org. A 127.0.0.4 response indicates a CBL-sourced listing; follow the returned URL for the specific detection signature (botnet family, open proxy, etc.) before touching the host.

dig +short 4.3.2.1.xbl.spamhaus.org A
dig +short 4.3.2.1.xbl.spamhaus.org TXT
# Or check interactively:
# https://check.spamhaus.org/listed/?searchterm=1.2.3.4

Find the process emitting outbound SMTP

On the suspect host, enumerate anything speaking to port 25 outbound. Correlate PIDs with running services. Botnet binaries frequently masquerade as kthreadd, [kworker], or random names in /tmp, /var/tmp, or /dev/shm.

ss -tnp state established '( dport = :25 )'
lsof -i :25 -n -P
# Look for unexpected senders:
journalctl -u postfix --since '24h ago' | grep -E 'from=|client='
grep -r 'mail(' /var/www 2>/dev/null | head

Close the vector, then rebuild trust

Patch the compromised service, rotate every credential that touched the host (SSH keys, SMTP AUTH, cPanel/WHM, CMS admins), and firewall egress on tcp/25 to only your intended relay. If the host was rooted, reimage — do not clean. Block outbound 25 at the edge for every subnet that is not an authorized MTA.

# Example: restrict egress 25 to one relay via nftables
nft add rule inet filter output tcp dport 25 ip daddr != 10.0.0.25 drop
# Or iptables:
iptables -A OUTPUT -p tcp --dport 25 -m owner ! --uid-owner postfix -j REJECT

Submit the delisting request

Once the host is clean, request removal via the Spamhaus self-service portal. Delistings are usually honored within an hour, but Spamhaus will immediately relist if sinkhole telemetry still shows the IP beaconing — do not request removal before step 3 is complete. Monitor with periodic DNSBL checks and set up alerting so you catch a relist within minutes.

# Self-service: https://check.spamhaus.org/
# Automated monitoring example:
for rbl in xbl.spamhaus.org zen.spamhaus.org; do
  echo -n "$rbl: "; dig +short 4.3.2.1.$rbl A
done

Fixed it? Run a fresh test to confirm.

Test my inbox →

Related errors