Your IP got blacklisted — diagnosing the cause and rotating to a clean IP

An IP that ends up on a public blocklist hurts in different ways depending on what you use the VPS for: outbound mail rejected silently, the carrier's SIP trunk refusing registrations, customers complaining your web service is flagged. This article covers how to find out which list flagged you, why, how to get delisted where possible, and when to ask for an IP rotation instead.

First — confirm it's actually a blacklist

Lots of things look like blacklisting and aren't. Before chasing RBLs:

• Outbound port 25 blocked by the hypervisor's default policy — not a blacklist, an ISP anti-spam control. Check the LYLIX port-25 policy in Mail prerequisites.
• SPF/DKIM/DMARC failure — your IP is fine but your mail authentication is broken; receivers spam- folder you. Different problem.
• Cloudflare/Imperva-style WAF rules on the destination — not a global blacklist, just one destination's rules.

Check the major blocklists

Free aggregator services check 50-100 lists at once. Search for "ip blacklist check" — pick any reputable result and paste your VPS IP. The ones that actually matter:

• Spamhaus SBL/CSS/XBL — the big one for mail. Listing here means most receivers will reject outright.
• UCEPROTECT levels 1, 2, 3 — level 1 is individual IP listings; 2 and 3 are CIDR-wide. Many receivers ignore 2 and 3 because they're aggressive.
• Barracuda — used by Barracuda appliances; affects business mail receivers heavily.
• Spamcop — short-lived listings driven by spam reports. Auto-delists in about a week.
• SORBS — older, less impactful than it once was.

For SIP-specific reputation (the SIP carriers maintain their own internal blocklists, separate from email RBLs), there's no public aggregator — you'd hear about it via SIP REGISTER 403 responses or all-circuits-busy on outbound.

Figure out why you got listed

Each listing has a "reason" — Spamhaus shows it on their delisting page; UCEPROTECT shows source counts. Common causes specific to a VPS context:

• Outbound mail spam — a compromised mail server, a CMS exploited via vulnerable plugin, a script that mass-mails through your IP. Check your mail logs.
• Open relay — Postfix or Exim misconfigured to relay for anyone. Embarrassingly common on legacy installs.
• Compromised account sending spam — a weak SMTP authentication password got brute-forced.
• SIP brute-force traffic — your PBX got hit by registration brute-force probes and your firewall responded by spewing replies; the source IP saw it and reported you.
• The previous owner of this IP — listings sometimes persist after an IP is reassigned. If your VPS is new and the listing predates it, the previous tenant probably caused it.

If your VPS caused it — fix the cause first

Most blocklists will not delist a listing that's still generating reports. So:

1. Stop the bleeding. If a script is spamming, kill it. If a mail server is open-relaying, stop the daemon while you fix it.
2. Identify the source. grep -i sent /var/log/mail.log | tail -100 for Postfix; equivalent for Exim. Look for unusual recipient patterns, high volume from one sender, or connections from IPs that shouldn't be authenticating.
3. Fix the underlying cause. Patch the vulnerable CMS, rotate the compromised SMTP password, disable the relay misconfiguration, harden the PBX. See Hardening a public-facing PBX or Postfix + Dovecot from scratch.
4. Confirm in logs that the problem stopped. Watch for an hour; if mail volume is back to normal, you're good.

Request delisting

Each list has its own process:

• Spamhaus — Spamhaus delisting form on their site. They want to know what caused the listing and what you did to fix it. Honest answers work better than corporate ones; they read these.
• UCEPROTECT — level 1 listings expire automatically 7 days after the last report. Express delisting is available for a fee; most operators just wait.
• Barracuda — their delisting form is on barracudacentral.org. They usually respond within 24-48 hours.
• Spamcop — auto-delists in about a week; no manual process.

When to ask LYLIX for an IP rotation

Sometimes delisting isn't realistic — multiple stacked listings, an IP with a long bad history, or a CIDR-wide listing that won't lift even after individual delisting. In that case we can rotate you to a different IP:

• Open a ticket in the Virtual Private Server department. Subject: "IP rotation request for <current IP>."
• Include the cause — what put you on the list and what you fixed. If we're going to give you a new IP, we need confidence the new one won't go straight onto the same list within a week.
• Plan for downtime / DNS propagation — your new IP needs DNS updates, firewall allowlist updates with downstream services, PTR re-configuration (see Reverse DNS (PTR)).

We do try to keep our IP pool clean — listings that aren't your fault (carrier-side, IP previously listed before you got it) we'll handle proactively. Listings that are your fault and keep recurring after rotation, we'll ask you to address the root cause first.

What you can do preventively

• Outbound mail through a relay — for transactional mail (notifications, password resets), use Mailgun, Postmark, Amazon SES. Your VPS IP never touches the recipient's MX. Reputation problems vanish.
• Rate-limit your own outbound if you do send mail directly. A web app sending 10,000 mails in 5 minutes gets flagged regardless of legitimacy.
• Monitor for compromise — fail2ban, log review, automated update of CMS plugins. Most "my IP got blacklisted" tickets start with a compromised WordPress or PBX brute-force.
• Sign with DKIM, publish SPF and DMARC — receivers are more forgiving of a borderline IP if the mail authenticates properly.