IP Blacklist Check 2026: How to Test Your Sending IP (Complete Guide + 12-Blocklist Matrix)

If your cold email is suddenly bouncing at higher rates, your inbox placement collapsed overnight, or Gmail is rejecting messages with SMTP code 550 — the first thing to check is your sending IP's blacklist status.

A single Spamhaus listing can drop your deliverability from 95% to 5% in an afternoon. The fix takes anywhere from 24 hours to a few weeks depending on which list flagged you and why.

This guide is the canonical 2026 reference: which blacklists actually matter for cold email, how to check each one fast, what to do per listing type, the full 12-blocklist coverage matrix with delisting paths, a walkthrough of ColdRelay's free /tools/blacklist-checker, and how ColdRelay's infrastructure design (hourly monitoring + dedicated IPs per customer) keeps you from getting blindsided.

TLDR — the IP blacklist landscape:

• Catastrophic listings (block at Gmail/Outlook/Yahoo): Spamhaus SBL, Spamhaus XBL, Spamhaus DBL.
• Significant listings (block at enterprise receivers): Barracuda BRBL, SORBS.
• Moderate listings (some receivers): SpamCop, UCEPROTECT L1.
• Low impact (rarely move inbox placement): UCEPROTECT L2/L3, regional/niche blocklists.
• Defensive monitoring: hourly DNSBL scans against 6 high-impact lists + alerts on first listing.
• Architectural defense: dedicated IPs per customer eliminate the shared-IP neighbor problem (the #1 cause of cold email blocklisting).

Run a free 12-list scan in 5 seconds → /tools/blacklist-checker. Get hourly automated monitoring → /sign-up.

Table of Contents

• The 30-second answer
• Why blacklists matter for cold email specifically
• How each major blacklist works
• The 12-blocklist coverage matrix
• Walkthrough: ColdRelay /tools/blacklist-checker
• Decision tree: delist or rotate
• IP types: residential / shared / dedicated
• What to do if you find a listing
• How ColdRelay's infrastructure prevents listings
• Weekly IP-reputation routine
• The delisting workflow per blocklist
• FAQ

The 30-second answer

An IP blacklist check queries public DNS blocklists (DNSBLs) to see if your sending IP is flagged as a spam source. The major blacklists for cold email:

Spamhaus is the most consequential. Being on Spamhaus SBL or XBL means most major providers (Gmail, Outlook, Yahoo) will reject your mail outright. The others affect deliverability to varying degrees but rarely cause outright rejection.

Run a free IP blacklist check against your sending IP — checks all 6 major lists in under 5 seconds.

Why blacklists matter for cold email specifically

Cold email's deliverability ceiling is set by the worst signal across your stack. SPF/DKIM/DMARC perfect? Doesn't matter if your IP is on Spamhaus — receivers reject before reading content. Domain reputation High in Postmaster Tools? Doesn't matter — IP-level rejection happens at the SMTP layer.

The math is brutal: one IP listing can negate weeks of careful warmup. And cold email setups are particularly exposed because:

1. High-volume sending from new IPs raises flags faster. A brand-new IP sending 1,000+ emails/day looks suspicious by default. Reputation-monitoring services (Cloudmark, Cisco Talos) flag the pattern.
2. Shared infrastructure means one bad neighbor lists everyone. If your cold email provider runs shared IPs (most do, except dedicated-per-customer setups like ColdRelay), a single customer's bad campaign can land your IP on a list.
3. Complaint-based blacklists (SpamCop) catch the high-volume case fast. Even a moderate complaint rate (>0.3%) at high volume produces enough reports to trigger automatic listing.

How each major blacklist actually works

Spamhaus SBL (Spamhaus Block List)

What it is: Spamhaus's manually-curated list of confirmed spam-source IPs. The most-respected DNSBL in the industry.

What gets you listed: Direct evidence of spam emission — high complaint volume from Spamhaus's own honeypots, ISP partnerships, or community reports. Listing is a deliberate human decision, not automated.

Deliverability impact: Catastrophic. Gmail, Outlook, Yahoo, Apple, and ~all major providers consult SBL. A listed IP gets mail rejected with SMTP code 550 or 554.

Fix: Submit a removal request via spamhaus.org/lookup. You have to demonstrate the underlying issue is fixed — they want to see evidence (changed sending pattern, list cleanup, IP change). Spamhaus reviews manually. Typical resolution: 1 to 7 days.

Spamhaus XBL (Exploits Block List)

What it is: Compromised hosts — open proxies, malware-infected machines, botnet members. Different category from SBL (which is intentional spammers); XBL is about hijacked infrastructure.

What gets you listed: Your IP got compromised (or shares a /24 with compromised IPs), or sent through an open relay, or matches a botnet behavior pattern.

Deliverability impact: Same as SBL — major providers reject.

Fix: Remove the compromise (clean the machine, close the open relay). Spamhaus auto-delists once their scans show the IP is clean, typically within 24 to 48 hours. No manual submission required.

Barracuda BRBL (Barracuda Reputation Block List)

What it is: Behavior-based, automated. Barracuda runs honeypots and customer-side spam-detection signals through ML to score IPs.

What gets you listed: Spam-like behavior — usually a combination of volume + complaint rate + recipient mix.

Deliverability impact: Significant at Barracuda customers (lots of mid-market enterprises). Less impact at Gmail-heavy ICPs.

Fix: Barracuda's IP removal request form — automated for most cases, 24 to 48 hours.

SORBS (Spam and Open Relay Blocking System)

What it is: Multiple lists in one — DUHL (dynamic-IP ranges), spam sources, open relays, web-form-spam sources.

What gets you listed: Most commonly the DUHL list — your IP falls in a dynamically-assigned range. Cloud-provider IPs often start in this list by default.

Deliverability impact: Moderate. Many receivers consult SORBS, but it's weighted lower than Spamhaus.

Fix: SORBS is the slowest to delist — manual review, sometimes weeks. The DUHL listing is the easiest to clear (your IP needs to be flagged as static/reserved by your provider; ColdRelay's dedicated IPs are static and won't show up here in the first place).

SpamCop

What it is: Real-time complaint-based listing. Users forward suspected spam to SpamCop; enough reports = automatic listing.

What gets you listed: A specific complaint threshold from SpamCop's user network. Even a few complaints in a short window can trigger it for new IPs.

Deliverability impact: Used by some receivers (notably Cisco's IronPort products). Moderate impact on cold email at scale.

Fix: Automatically expires after 24 hours of clean sending. No removal request needed — just stop the offending sending pattern.

UCEPROTECT (Levels 1, 2, 3)

What it is: A behavior-pattern-based list with three escalating tiers — L1 lists individual IPs, L2 lists the /24 subnet, L3 lists the whole ASN.

What gets you listed: Spam-like volume from the IP (L1), or from neighbors in the same /24 (L2), or from the whole hosting provider's network (L3).

Deliverability impact: Variable. Many receivers ignore UCEPROTECT entirely; others weight it lightly. Less consequential than Spamhaus or Barracuda.

Fix: Automatic expiry after 7 days of clean behavior. The L2 and L3 listings are out of your control — you can be clean and still be on L2 because of a neighbor.

The 12-blocklist coverage matrix

The full matrix below is what to actually monitor. Each row covers what a listing on that list means, where to delist, typical timeline, and how seriously to take the listing for cold email at major receivers (Gmail, Outlook, Yahoo, Apple).

The pattern is consistent: the catastrophic-severity rows (the Spamhaus family + Barracuda BRBL) decide whether your mail actually reaches inboxes at major providers. Everything below that line affects deliverability at the margin. Browse the full blocklist removal hub for delisting guides keyed to every list above.

Walkthrough: ColdRelay's /tools/blacklist-checker

The fastest end-to-end path is the free /tools/blacklist-checker. No signup required, no sending required, results in roughly 5 seconds.

Step 1 — find your sending IP. If you're sending through Google Workspace, your IPs are Google's shared pool (effectively impossible to check usefully — you don't control them). If you're sending through dedicated cold-email infrastructure, the IP is listed in your provider's dashboard. ColdRelay customers see the per-mailbox IP next to each domain in /dashboard; other providers expose it via their settings or via an MX lookup on the sending host.

Step 2 — paste the IP into the checker. The input accepts IPv4 (e.g., 203.0.113.45). Hit "Check IP."

Step 3 — read the results. The page shows a row per blocklist with a status badge:

• Green ("Not listed"): the IP is clean on that list. This is the expected state.
• Red ("Listed"): the IP is on that list. Click the row to expand the listing details — reason code (when the upstream list provides one), the delisting URL, and the canonical /blocklist-removal/[slug] guide for that list.
• Yellow ("Timeout"): the upstream blocklist's DNS server didn't respond in time. Retry after a few seconds — usually transient.

Step 4 — act on findings. Any red row in the catastrophic-severity tier (Spamhaus or Barracuda) means stop sending immediately and start the delisting workflow. Red rows in moderate or mild tiers are noted but not urgent.

Step 5 — re-scan after delisting. The checker is stateless — you can re-run after submitting a delisting request to confirm the IP is back to clean. DNSBL caches occasionally lag the upstream by an hour or two; if a Spamhaus delisting is confirmed but the checker still shows red, retry in 30 minutes.

For ColdRelay customers the checker is a secondary safety net — the dashboard runs the same scan hourly across every IP in the workspace and pushes an alert on first listing. For everyone else, this is the manual equivalent.

Decision tree: delist the IP or rotate to a new one

Not every listing is worth fighting through. Sometimes the right move is to abandon the IP and provision a fresh one. The decision tree:

1. Is this a Spamhaus listing on an IP with otherwise-good history? Delist. Spamhaus delisting is the more reliable path than burning the IP — a fresh IP needs 2–3 weeks of warmup to reach the reputation your existing IP probably already has.

2. Is this a subnet-level listing (UCEPROTECT Level 2, SORBS DUHL on a shared /24)? Rotate. You cannot delist a neighbor's reputation. Move to a clean IP — and if you're on shared infrastructure, this is the signal to move to dedicated.

3. Is this a fresh IP listed within its first 30 days of sending? Diagnose, then decide. Fresh-IP listings usually indicate one of: (a) the IP came from a dynamic-range cloud allocation, (b) a volume spike triggered behavioral classifiers, or (c) the warmup wasn't progressive enough. Fix the root cause first; the IP itself is recoverable.

4. Is this the third listing on the same IP in 90 days? Rotate. Recurring listings mean the IP has accumulated some baseline reputation damage that delisting alone won't fix. Cycle it out and provision fresh.

5. Is this a domain-level listing (Spamhaus DBL, URIBL on a tracking domain)? Different problem — see the domain blacklist guide. IP rotation doesn't fix domain-level issues.

The default bias should be toward delisting, not rotation — your existing IP's positive history is an asset. But "fight every listing to the end" is wrong too; some listings signal the IP is poisoned and not worth recovering.

IP types and why each gets listed differently

Not all sending IPs are created equal. The blocklists treat three IP categories very differently:

1. Residential / dynamic IPs. Cable, DSL, mobile-broadband ranges. Default-listed on Spamhaus PBL and many other dynamic-range lists. Direct-to-MX sending from these is rejected at most providers regardless of content quality. Cold email cannot be sent reliably from residential IPs — even if you bypass the blocklist issue, receivers treat the originating range as suspicious. Workspace and most cloud-provider IPs are static and not in this category.

2. Shared / pooled IPs. The cold email industry's most common architecture and the source of most listing pain. Hundreds to thousands of senders share each IP. Reputation is the average across all those senders, with sharper damage when one neighbor sends a bad campaign. Even careful, low-volume sending can end up on Spamhaus or Barracuda because of a neighbor — the listing is on the IP, not on your behavior. Examples: most cheap cold email infrastructure providers, transactional services like SendGrid's shared pool, Google Workspace's outbound IPs.

3. Dedicated / cold IPs. A single sender (you) controls the IP. Reputation is yours alone, both upside and downside. Listings happen only when your own sending pattern triggers them. Dedicated IPs require warmup from a cold (zero-reputation) state but accumulate trusted-sender reputation over weeks of clean sending. ColdRelay's architecture: every customer gets dedicated IPs on isolated Azure tenants per workspace, eliminating the shared-pool failure modes that dominate the cheap-infrastructure category.

The takeaway: the blocklist-listing risk profile is fundamentally different across these three. Residential is unusable. Shared is risky regardless of your own behavior. Dedicated puts the risk and the reputation back in your control.

What to do if you find a listing

Order of operations:

1. Stop sending immediately. Every additional message while listed compounds the reputation damage. Pause campaigns on the affected IP.

2. Identify the cause. Most common in cold email:

• Volume spike (sent 2× normal in a day = behavioral red flag)
• List-quality drop (verified addresses turning out to be invalid = bounce surge)
• Complaint surge (campaign content that triggered spam reports)
• Shared-IP neighbor problem (someone else on your IP block did damage)

3. Submit the delisting request for the specific blacklist (links above). Be specific about what changed. "Cleaned my list" is generic; "Removed 12K addresses from data-provider source X after detecting bounce-rate spike" is credible.

4. Reassess infrastructure. If you're on shared IPs and got listed because of a neighbor, the underlying problem is the shared-IP architecture. Move to dedicated IPs.

5. Slow ramp on resumption. After delisting, don't immediately resume normal volume. Start at 25% and ramp over 7 days. The IP's reputation is fragile until it accumulates enough clean history.

How ColdRelay's infrastructure prevents the listing in the first place

Three architectural choices that matter:

1. Dedicated IPs per customer. Your IP isn't shared with strangers. No neighbor problem — your reputation is yours alone, and one customer's bad campaign can't drag down another customer's IP. (This is the single biggest differentiator from cheap cold email infrastructure that runs shared pools.)

2. Hourly DNSBL monitoring across 6 major lists. Every ColdRelay IP gets scanned against Spamhaus SBL, Spamhaus XBL, Barracuda BRBL, SORBS, SpamCop, and UCEPROTECT every hour. If any list flags an IP, an alert email goes out immediately — you know about the listing before your next campaign launches.

3. Per-mailbox volume cap of 2 cold sends + 2 warmup per day. The volume that consistently keeps Postmaster Tools Domain Reputation pinned at High over months. Lower volume = lower complaint rate = lower listing risk. Every customer asks why we don't let them send more; this is the math.

4. Pre-send recipient verification. Every address you push to a campaign gets SMTP-level verified before the first send. Dead addresses get auto-suppressed, which keeps bounce rate below 1% — and bounce-rate spikes are one of the top three causes of behavioral blacklisting. (Postmaster Tools details on IP reputation →)

A weekly IP-reputation routine

Set 5 minutes aside every Monday:

1. Run an IP blacklist check on each of your sending IPs. (ColdRelay's dashboard does this hourly; the manual check is the secondary safety net.)
2. Check Google Postmaster Tools IP Reputation for each IP. Should be High. If any drifted to Medium, investigate.
3. Check Microsoft SNDS if a meaningful share of your contacts are on Outlook. Their per-IP color codes (green/yellow/red) tell you what Outlook thinks of you.
4. Spot-check bounce rate on your top-3 sending domains. Anything above 1.5% gets investigated.

That's it. The infrastructure does the hourly monitoring; you're just confirming weekly.

FAQ

My IP is listed but I'm sure I haven't been spamming — what now?

Most likely cause: shared-IP neighbor problem. Someone else sending through the same IP block triggered the listing. Confirm by checking whether the listing applies to your IP specifically or to the /24 subnet (Spamhaus and UCEPROTECT distinguish these). If it's a subnet-level listing, your only fix is to move to a dedicated IP — you can't clear a neighbor's reputation problem.

How long does Spamhaus typically take to delist?

1 to 7 days from submission. They review manually and want to see evidence the underlying issue is fixed. Vague delisting requests get ignored; specific ones with a remediation plan get reviewed faster.

Can I just rotate to a new IP and avoid the delisting process?

In theory yes. In practice, fresh IPs lack reputation and take 2–3 weeks of warmup to reach reliable inbox placement. Delisting your existing IP (if it has any positive history) is usually faster than burning it and starting fresh. The exception: if the IP's reputation was bad before listing, fresh IP is better.

Do all major email providers use the same blacklists?

Mostly. Gmail and Outlook consult Spamhaus heavily. Yahoo consults Spamhaus + their own internal signals. Apple consults Spamhaus + Cisco Talos. The smaller you go (custom MX servers, self-hosted), the more variability. As a default assumption: if you're on Spamhaus, you're rejected at major providers; if you're only on UCEPROTECT, you might be fine at Gmail and rejected at Cisco-protected enterprises.

Should I run the blacklist check before warming up a new IP?

Yes — fresh IPs occasionally come from cloud providers with neighbors that put them on dynamic-range lists (especially SORBS DUHL) by default. ColdRelay provisions IPs that are already cleaned of these listings, but if you're rolling your own infrastructure, check before sending.

What's the difference between an IP blacklist and a domain blacklist?

IP blacklists flag the sending server's IP. Domain blacklists (URIBL, SURBL) flag domains that appear inside the message body — usually links pointing to known spam landing pages. Different concerns; both matter for cold email. ColdRelay's monitoring covers both.

How is ColdRelay's hourly monitoring different from running a manual check?

Frequency + automation. A manual check tells you status at one point in time. Hourly monitoring catches listings within the first hour they appear, before you've sent your next campaign. The difference between catching a Spamhaus listing 1 hour vs. 24 hours after it appears is the difference between 50 messages affected and 5,000 messages affected.

IP blacklists are a deliverability landmine — easy to hit, hard to clear, infrastructure-level damage. The defense is architecture (dedicated IPs, low volume per mailbox) more than reaction (manual monitoring).

Test your IP free → Run the blacklist check · Cold email infrastructure with hourly blacklist monitoring → Try ColdRelay free