We Got Blacklisted Because of a Banking Trojan We Didn't Even Have

One morning, email on our primary domain just... stopped working. No bounce messages. No error a normal user would ever see. Outgoing mail vanished into nothing, and nothing was coming in either. For a small agency where half of new business arrives by email, that's not a minor inconvenience — that's the front door nailed shut. Opening the Ticket First instinct was to check the obvious stuff: DNS records, mail server config, SPF/DKIM — all fine. So we opened a support ticket with our hosting provider and waited. The answer that came back wasn't what we expected: our server's IP address had landed on the Spamhaus blacklist — one of the most widely used spam-reputation lists in the world. Once an IP is on it, a huge percentage of mail servers worldwide will silently drop or reject anything coming from that address. That's why we weren't seeing bounces — recipient servers weren't even bothering to tell us. Here's the part that stung: it wasn't anything we did. According to the hosting provider, another account on the same shared server had a banking trojan running on it, generating exactly the kind of malicious outbound traffic that gets an IP flagged. We were sharing an IP address with a compromised neighbor, and Spamhaus doesn't care whose account is actually infected — it blacklists the IP. The Real Problem: Shared Infrastructure, Shared Reputation This is the part that's actually worth internalizing if you're running anything important on shared hosting: your domain's email deliverability is tied to the security hygiene of every other account on that server — accounts you have no visibility into and no control over. You can have a spotless setup. Strong passwords, clean code, no vulnerable plugins. None of that matters if the account two slots over from yours gets compromised and starts spraying spam or malware traffic from the same IP. You inherit their blacklist. For most small businesses, this risk is invisible until the day it isn't. The 48-Hour Move Once we understood the actual cause, staying on that shared IP wasn't really an option — even after cleanup, a blacklisted IP can take time to get delisted, and there was zero guarantee another account on the same server wouldn't cause the same problem again next month. So we moved fast: Spun up a dedicated VM on Google Cloud Platform — our own IP, our own environment, no neighbors Transferred the domain to Cloudflare's registrar for better control over DNS and security settings Set up mail through Zoho Mail with a PHPMailer relay, so outbound mail from the server goes through a reputation-managed provider instead of relying on the VM's raw IP reputation That last point matters as much as the migration itself — even on a dedicated server, we didn't want our deliverability resting entirely on one IP's reputation again. Locking It Down Once we were on infrastructure we fully controlled, we hardened it properly — things that aren't possible (or aren't your job) on shared hosting: Fail2ban with guaranteed uptime. Fail2ban watches logs and bans IPs showing brute-force or scanning behavior, but if the service itself crashes, you're unprotected. We added a systemd override so it restarts automatically: # /etc/systemd/system/fail2ban.service.d/override.conf [Service] Restart = always RestartSec = 10 Persistent firewall blocks. Known-bad IPs get dropped at the firewall level and the rule survives reboots: sudo iptables -A INPUT -s <malicious-ip> -j DROP sudo netfilter-persistent save reCAPTCHA Enterprise on every form. Not directly related to the blacklist, but part of the same "stop being an easy target" push — bot traffic and automated form abuse are exactly the kind of noise that can snowball into the next incident. What We'd Tell Anyone on Shared Hosting You don't need to migrate to a VM tomorrow to take one useful thing from this. Periodically check whether your mail server's IP is on a blacklist — it takes thirty seconds: check.spamhaus.org — Spamhaus's own lookup mxtoolbo