How do I check if my IP is on a blocklist?

MXToolbox runs your IP against ~80 of the major email blocklists at once and returns each one as a pass/fail. AbuseIPDB shows the most recent abuse reports filed against your IP by other operators. For Spamhaus specifically, check.spamhaus.org runs the SBL, CSS, XBL, and PBL lookups in a single query and tells you which list flagged you and why.

Why did my mail get blocked when I have not done anything wrong?

Three common reasons. First, your IP was a 'bad neighbor' problem — somebody else on the same allocation block misbehaved and the entire range got flagged. Second, your IP was a residential or hosting address that 'should not be sending mail' according to the listing operator's allocation list. Third, your sender authentication is missing or broken — without SPF, DKIM, and DMARC, modern mail providers treat the message as spam by default regardless of the IP.

How long does it take to get off a blocklist?

It depends on the list. Spamhaus PBL listings for residential IPs are removable by the assigned ISP usually in under 24 hours. Spamhaus SBL/XBL listings for confirmed abuse can take days to weeks, longer if the underlying compromise has not been fixed. Cloud-provider internal reputation (Cloudflare's threat score, Microsoft's SmartScreen) decay slowly over time but cannot be cleared on request — they require demonstrably clean traffic over a sustained period.

Can I check the reputation of an IP I do not own?

Yes — all the public blocklists let anyone query any IP. This is how spam filters work. The same tools (MXToolbox blacklist check, AbuseIPDB, Project Honey Pot's HTTPBL) accept any IPv4 or IPv6 address. The result is informational only; you cannot request removal of an IP you do not control.

IP reputation and blocklists — why your IP gets blocked, how to fix it

What "reputation" actually is

Reputation isn't a number stored centrally; it's a collection of opinions held by different operators about a given address. Spamhaus has one opinion. Microsoft's mail servers have another. Cloudflare has a third. AbuseIPDB has a fourth. Each one is built from different signals, used for different decisions, and updated on a different timeline.

When something on the internet silently refuses your traffic — your email going to spam, a website challenging you with CAPTCHAs every page, a financial service declining to load — the most common explanation is one of these reputation systems, not a routing or DNS problem. The IP is reachable. It's just not trusted.

How reputation gets built

Different scorers use different signals, but a few inputs show up in almost every system:

Spam reports. A user clicks "junk" on an email; the sending IP gets a mark on the recipient's scoreboard. At Gmail/Outlook/Yahoo scale, this happens millions of times a day and feeds into private reputation systems no public blocklist sees. A consistent >0.1% complaint rate is enough to start getting throttled.
Honey-pot traps. Email addresses that have never been published anywhere except as bait, URLs hidden in HTML comments, form fields visible only to scrapers. Anything that contacts a trap is, by definition, harvesting or attacking. Project Honey Pot has been running this since 2004; their data feeds many other lists.
Authentication failures. SSH brute-force attempts, repeated WordPress/wp-login.php probes, expired credentials hitting an API at machine cadence. fail2ban-style detectors aggregate these into per-IP scores.
Connection patterns. Massive parallel requests from one IP, residential IPs sending mail (most home networks legitimately don't), Tor exit nodes, known commercial VPN ranges, datacenter IPs sending consumer-style HTTP traffic, IPs scanning random ports. None of these is automatically malicious — but each raises baseline suspicion.
Bad-neighbor effects. If a /24 block has many flagged IPs, the whole block gets treated with suspicion. This is especially common on cheap VPS providers and residential proxy networks where customers churn rapidly and the same IPs cycle through many tenants.
RBLs and DNSBLs. Real-time blocklists query themselves via DNS — a mail server asks 1.2.3.4.zen.spamhaus.org and the answer (or absence of one) tells it whether the IP is listed and why. This is by far the cheapest way for a small mail server to participate in the global reputation ecosystem.

The blocklists that actually matter

Spamhaus. The bedrock for email. SBL (snowshoe and known spammers), CSS (compromised hosts sending spam), PBL (residential/dynamic ranges that "should not be sending mail" per their ISP's declaration), XBL (malware-infected machines, incorporates the older CBL). If you're on any Spamhaus list, your mail is going nowhere at Gmail, Microsoft, or any mail provider that consults Spamhaus — which is essentially all of them.
Composite Blocking List (CBL). Botnet-traffic listings, now folded into Spamhaus XBL. Listings are automated based on observed traffic; delistings are self-service via the CBL website once the infection is cleaned.
SORBS. Older, broader, less authoritative. Includes lists for "dynamic" address pools and known-open proxies. Still consulted by some mail servers; can be stricter than necessary and slower to delist.
Barracuda Central / BRBL. Powers Barracuda mail appliances. Affects corporate mail more than consumer mail.
Project Honey Pot's HTTPBL. Comment spam, form spam, and harvester focus. Where most "is this IP a web spammer?" lookups end up. The lookup is HTTP, not DNS, but the principle is the same.
AbuseIPDB. Crowdsourced abuse reports, queryable via REST API. Widely used by security teams. Reports tag the IP with categories (SSH brute force, web app attack, fraud orders) and a free-text reason.
Cloud-provider internal reputation. Cloudflare's threat score (visible in their dashboard but not externally), AWS WAF's managed lists, Akamai Prolexic data, Microsoft SmartScreen. These affect a huge fraction of traffic but aren't queryable from outside their respective ecosystems.

How to check whether you're listed

For an IP you control, run all the checks in parallel rather than one at a time — half the lists agree, the other half don't, and you want the whole picture.

MXToolbox blacklist check — queries ~80 RBLs in one go and shows you each result. The right first stop for email-related listings.
check.spamhaus.org — Spamhaus-specific lookup. Distinguishes between SBL, CSS, XBL, and PBL, with the reason text inline.
AbuseIPDB — shows individual abuse reports filed by other operators. Useful for understandingwhy the IP is listed, not just whether.
Shodan — what services the IP exposes to the public internet. An IP with unexpected open ports is one explanation for a bad reputation.
Command line: dig +short 1.2.3.4.zen.spamhaus.org — the raw DNSBL query. Returns 127.0.0.x where x encodes which sublist; no answer means clean.

Getting delisted — the right order to do things

Fix the underlying cause first. A botnet-style listing means a machine on your network is compromised. Delisting before cleaning means relisting within hours. For mail, a "you're sending too much spam" listing means your mailing list has a stale or purchased subscriber problem.
Confirm sender authentication. Run our email auth checker on your domain. Without SPF, DKIM, and DMARC properly configured, modern mail providers treat your mail as suspicious regardless of the IP's reputation. SPF alone is no longer enough.
Submit the delisting request. Each blocklist has its own form. Spamhaus' is a same-day automated process for many listings; manual ones take 1–3 business days. CBL is fully automated. SORBS can take weeks. AbuseIPDB entries decay automatically (90-day TTL) but you can also request expedited removal with evidence.
Warm up the IP carefully. A new sender (fresh VPS, new mail domain) starts with no reputation, which big providers treat as suspicious. Don't blast a 10,000-recipient newsletter on day one. Send small volumes (50–200/day) to engaged subscribers for the first 1–2 weeks, then ramp.
Monitor DMARC reports. Once DMARC is set with rua=mailto:dmarc@yourdomain.com, you'll start receiving aggregate reports from receivers telling you who is accepting and who is rejecting. This is how you know the reputation is recovering before the blocklist site catches up.

The "should I just move?" question

Sometimes the cleanest fix isn't delisting — it's moving. A poisoned residential IP from a consumer ISP is essentially unusable for sending mail no matter what you do, because Spamhaus PBL will keep listing it for as long as the ISP says "this range is residential." A datacenter IP with a long history of bad neighbors will struggle forever. In both cases, the cheapest path is moving the relevant workload to a reputation-aware service:

Email: SendGrid, Postmark, AWS SES with a dedicated IP, Resend, Mailgun. Their IPs come pre-warmed and they monitor reputation continuously. You pay a small per-message fee instead of fighting blocklists.
Outbound web automation / scraping: commercial residential proxy providers. Their IPs are clean by curation, not by accident.
Self-hosted services: sit them behind a reputable CDN. Cloudflare and Fastly absorb most of the trust-related friction so your origin's reputation barely matters.

Checking IP reputation with IPFerret

IPFerret surfaces a few reputation-adjacent signals on the home page when the geo-IP provider supplies them — the "privacy" flags from upstream cover VPN, proxy, Tor exit, hosting datacenter, and known relay status. For deeper investigation:

/whois/<ip> gives the abuse contact registered for the allocation — that's the email you'd write to about misuse from that IP, or the inbox you'd file a delisting appeal at if it's your own range.
/asn/<asn> shows who operates the entire range. Bad neighbors share a network operator; the ASN page reveals whether the problem is one IP or the whole block.
Bulk reverse DNS — paste a list of IPs you've seen attacking you, get the PTR hostnames. Spammer infrastructure often shares naming conventions (e.g. mail-out-N.spammyhosting.com).

IP reputation and blocklists