How to check if a VPS IP is blacklisted

The first thing that breaks on a freshly rented VPS is rarely the server itself. It is outbound email bouncing, or your IP silently refused at the SMTP handshake, because someone else abused the range before you got it. If you send transactional mail, run an SMTP server, or just want to know whether your IP carries baggage, you need to know how to check if a VPS IP is blacklisted. This guide covers the exact DNSBL checks, the reputable lookup services, and what to do when you find your IP on a list. It applies to any Linux VPS with a dedicated IPv4, including Ubuntu 24.04 and Debian 12.

Prerequisites

• A Linux VPS with a dedicated IPv4 (Ubuntu 24.04, Debian 12, or AlmaLinux 9).
• Root or sudo access over SSH.
• Access to your DNS control panel if you need to fix SPF/DKIM alongside the blacklist.
• No prior mail setup required. You can run these checks on any VPS.

What does it mean when an IP is blacklisted

A blacklist, also called a DNSBL or RBL, is a public DNS-based list of IP addresses known to send spam or malware. Mail servers query these lists in real time during the SMTP conversation. If your IP appears on one, the receiving server can reject your mail with a 5xx error, or silently drop it into spam.

Blacklisting is not always your fault. On a VPS with full root access, a single compromised account or an open relay can get you listed within hours. On shared or recycled IP ranges, you can inherit a listing from the previous tenant. This is why checking a fresh IP before sending any real mail is a step you should never skip.

There are hundreds of DNSBLs, but only a handful matter. The major ones are Spamhaus ZEN, SpamCop, Barracuda, and SORBS. Commercial receiving systems also maintain private reputation scores, but the public lists are what you can actually query yourself.

Checking DNSBL lists manually with dig

The most reliable way to check a blacklist is to query the DNSBL zone directly. Every major RBL publishes its own DNS zone. You reverse the IP octets, append the zone, and look for an A record. A response of 127.0.0.2 or similar means the IP is listed.

For the Spamhaus ZEN list, run this on your Linux VPS or local machine:

dig +short 2.0.0.127.zen.spamhaus.org

If you get an empty response, the IP is not on that list. If you get 127.0.0.2, 127.0.0.3, or 127.0.0.4-127.0.0.7, it is listed. The returned code tells you the reason: 127.0.0.2 is SBL (spam source), 127.0.0.3 is CSS (customer abuse), and 127.0.0.4 plus 127.0.0.9 are PBL (end-user policy).

To check a real IP, say 203.0.113.25, against Spamhaus, reverse it and query:

dig +short 25.113.0.203.zen.spamhaus.org

Verify: an empty reply means clear. A 127.0.0.x answer means listed. Repeat the same pattern for other lists by swapping the zone suffix. Barracuda is list.barracudanetworks.com, SpamCop is bl.spamcop.net.

Using online lookup tools

Manual dig checks are precise, but they do not cover every list. For a full sweep, use a reputable aggregate service. These query dozens of DNSBLs at once and show you which are active.

The services worth using in 2026 are:

• MXToolbox (mxtoolbox.com) - the default choice. Run a blacklist check on any IP, see all major RBLs with status and lookup time.
• Spamhaus lookup (check.spamhaus.org) - authoritative for the Spamhaus zones and the reason codes behind a listing.
• Barracuda Reputation (barracudacentral.org) - useful because Barracuda runs its own private reputation for its mail gateway customers.
• TrustMyIP Black (trustmyip.com) - a lightweight checker that also reports whether an IP is in any blocklist category.

What to look for: any result marked "LISTED" or showing an error on a list you actually depend on. Ignore obscure lists with a handful of entries. The ones that matter for mail delivery are Spamhaus, SpamCop, Barracuda, and SORBS. A listing on an obscure German blocklist is cosmetic. A listing on Spamhaus PBL is a real problem for SMTP VPS operators.

Why a fresh VPS IP can already be blacklisted

This is the part that surprises most people. You rent a brand new VPS, the provider hands you an IPv4, and your first test email bounces. The IP was not clean because the range was previously used for bulk mail, or an earlier tenant ran a spam campaign from the same subnet.

IPv4 is a scarce resource. Providers recycle ranges, and a VPS with a dedicated IPv4 from a recycled block can carry legacy reputation damage. Large cloud providers clean their RBL footprints regularly. Smaller providers, especially in markets where IPv4 is tight, may not be as diligent.

This matters even if you never send mail. Some DNSBLs, notably Spamhaus PBL, list entire end-user ranges. If a receiving service checks your IP before any transaction, a listed PBL can slow down or block non-mail traffic too, though this is rare.

The fix is not to panic. A listing on a single RBL is usually removable. A listing on many RBLs from the same past tenant is harder and may justify asking the provider for a different IP, or moving to a provider with cleaner ranges. This is one practical reason to pick a rent Linux VPS provider that keeps its IPv4 inventory clean.

How to check sender reputation separately from RBLs

A blacklist check tells you about blocklists, but not about reputation. Reputation is the broader score that Google, Microsoft, and Yahoo compute from your sending history, complaint rates, and engagement. An IP can be off every DNSBL and still have terrible reputation, which lands your mail in spam quietly.

To check reputation you need different tools:

• Postmaster tools from Google (postmaster.google.com) - shows your domain reputation, spam rate, and delivery errors if you send enough volume through Gmail.
• Microsoft SNDS (senderscore.microsoft.com) - does the same for Outlook.com and Hotmail.
• Sender Score (senderscore.org) - a 0-100 score based on your IP sending behavior. Above 90 is good, below 70 is a warning.
• Talos Intelligence (talosintelligence.com) - Cisco's reputation lookup, operational data for the IP.

Run these in parallel with the DNSBL checks. A clean RBL result with a low Sender Score tells you the issue is your sending pattern, not the IP itself. That is a different fix: slow the volume, warm up the IP, and fix your SPF, DKIM and DMARC alignment.

How to fix a blacklisted VPS IP

The removal process depends on which list you are on. There is no single "delist" button. Each RBL has its own removal page and its own criteria. But the sequence is always the same: find the listing, fix the root cause, request removal, then verify.

For Spamhaus, go to check.spamhaus.org, enter your IP, and follow the "Request removal" link for the specific zone. Spamhaus delisting is usually automatic for PBL if you stop the offending traffic, but SBL and CSS require a manual review and may take days.

For SpamCop and Barracuda, the removal pages are simpler. SpamCop delists after a period of clean traffic, usually 24 hours. Barracuda requires you to log in and request a review, and they will re-check your sending history.

Before you request removal from any list, make sure the cause is gone:

ss -tlnp

Check for an open relay on port 25, a compromised web app sending spam, or an exposed mail submission port. If your server was compromised, clean it first. Requesting delisting while the spam source is still active will just get you re-listed within a day.

While you wait, test your IP again with the dig command from the earlier section to confirm the listing clears.

Preventing blacklisting on a VPS

Prevention beats removal. The practices below keep a clean IP clean, which matters if you plan to run SMTP VPS work or any mail service on your Linux VPS.

• Disable open relay. Ensure your mail server only accepts mail for your own domains, and require SMTP auth for outbound.
• Never expose port 25 to the world unless you run a real mail server. Use submission on 587 with STARTTLS for clients.
• Set up and validate SPF, DKIM, and DMARC before sending any volume. Alignment is a major factor in both reputation and blocklist scoring.
• Install fail2ban to block brute-force attempts on SSH and mail auth. A compromised account is the fastest route to a blacklist.
• Monitor your sending volume daily. A sudden spike from a compromised script is what lands IPs on Spamhaus CSS.
• Keep the OS updated. Many blacklist events start with a vulnerable web app or an out-of-date mail server.

If you outgrow a single range and need more IPs, ask your provider about additional IPv4 addresses. On a provider with good range hygiene, this is a straightforward add-on.

Troubleshooting: common problems with blacklist checks

You ran the checks and got confusing results. Here are the failures I see most often.

Error: dig is not installed. On a minimal Ubuntu or Debian install, dnsutils may be missing. Install it:

apt update && apt install -y dnsutils

On AlmaLinux or Rocky, the package is bind-utils:

dnf install -y bind-utils

Error: query timed out. Your local DNS resolver may block the RBL zones. Retry with an external resolver:

dig @8.8.8.8 +short 2.0.0.127.zen.spamhaus.org

Error: listed on a list you have never heard of. Most aggregate tools report dozens of RBLs, many of which are defunct or irrelevant. Focus on Spamhaus, SpamCop, Barracuda, and SORBS. A listing on an obscure list is not worth a removal request.

Error: MXToolbox shows clean but your mail still bounces. The receiving server may use a private reputation service, not a public RBL. Check the exact bounce message in your mail log and look up which list it references:

grep -i "blocked\|reject\|spam" /var/log/mail.log | tail -20

FAQ

Related articles

• Why VPS emails land in spam and how to fix it
• Warming up a new sending IP: a realistic 30-day schedule
• SPF, DKIM and DMARC on a self-hosted SMTP server
• Why shared SMTP relays hurt deliverability once you scale