Before you route traffic through a leased subnet, a reputation audit isn't optional: it's the step that determines whether your emails land in inboxes, your services stay accessible, and your operations avoid unnecessary friction from day one.

This guide walks you through the full process — from running your first IP reputation check to getting delisted if needed, and setting up monitoring so problems don't catch you off guard later. The checklist and delisting steps apply to all use cases, but email infrastructure has a higher bar; sections marked for email use cases can be skipped if sending is not in scope.

Pre-use reputation audit checklist

Before configuring anything, run through this checklist for every IP block you're about to activate:

• Check all major blacklists. A single clean result from one database means nothing — coverage across Spamhaus (ZEN), AbuseIPDB, and MXToolbox's multi-list sweep is the minimum baseline (more on each below).

• Check the entire range, not just a sample. If you're leasing a /24, spot-checking five IPs isn't enough. Use tools that accept CIDR input and return results for the full block.

• Verify reverse DNS (rDNS). Missing or mismatched PTR records are a soft reputation signal that can affect mail deliverability even without a formal blacklist entry.

• Check BGP routing history. Look up the block in BGPView (bgpview.io) or Hurricane Electric's BGP Toolkit (bgp.he.net). A history of frequent ASN changes, long periods of non-announcement, or past associations with known abuse-heavy networks are warning signs worth raising with your account manager before activation.

• Verify WHOIS accuracy. Confirm the block's WHOIS record correctly reflects the current holder before you activate. Outdated WHOIS data can mean abuse reports go to the wrong contact, and some automated systems flag the discrepancy.

• Check domain-based reputation if applicable (email use cases). If you plan to use the block for email sending, run the associated sending domain through Google Postmaster Tools and Microsoft SNDS as well.

• Note the use case — email vs. non-email matters. Email infrastructure is sensitive to reputation signals that have no meaningful impact on web, API, or general infrastructure use cases. The full checklist applies regardless, but the monitoring section includes email-specific steps you can skip if sending is not in scope.

• Document your findings. Screenshot or export results before you activate the block. If a dispute arises later about pre-existing listings, you'll want a timestamped record.

If everything is clean, proceed to configure your leased subnet. If any IPs come back flagged, work through the delisting process below before going live.

Tools to check: Spamhaus, AbuseIPDB, MXToolbox

These databases and tools cover the majority of real-world IP blacklist checks used by mail servers, firewalls, and security systems.

Spamhaus (via ZEN)

Spamhaus operates several lists — and for leased blocks, the most important are:

• SBL (Spamhaus Block List) — manually verified spam sources, spam operations, and spam infrastructure. A listing here is serious and requires human review to remove.

• CSS (Combined Spam Sources) — an automated sub-list under the SBL zone, targeting snowshoe spammers, compromised hosts, and low-quality bulk senders. Has its own self-service removal process, distinct from SBL.

• XBL (Exploits Block List) — compromised and botnet-infected IPs sending spam or malware automatically. This list incorporates data from the CBL (Composite Blocking List). Self-service removal is available once the underlying compromise is resolved.

• PBL (Policy Block List) — IPs that should not be sending direct email to the internet (dynamic ranges, end-user IPs). Not a spam accusation, but a policy declaration. Relevant mainly for email use cases.

The most efficient way to check all of these at once is through ZEN — Spamhaus's combined zone that aggregates SBL, CSS, XBL, and PBL into a single query. Check via the Spamhaus Reputation Checker at check.spamhaus.org. CIDR lookups are supported.

AbuseIPDB

AbuseIPDB aggregates abuse reports submitted by network operators and security teams. Unlike Spamhaus's automated detection, AbuseIPDB reflects human-reported incidents — SSH brute force attempts, port scans, DDoS participation, and similar activity. An IP can have a clean Spamhaus profile but a high AbuseIPDB confidence score, so both matter.

Use abuseipdb.com/check and review both the confidence score and the report history. A pattern of recent reports is more concerning than old isolated incidents; confidence scores are weighted by recency and decay over time if no new reports appear.

MXToolbox Blacklist Check

MXToolbox aggregates results from 100+ blacklists in a single query — a useful broad sweep before diving into individual databases. Run it at mxtoolbox.com/blacklists.aspx.

Additional tool: APIVoid

For CIDR-range checks across approximately 50 lists simultaneously, APIVoid's IP Reputation Check (apivoid.com/tools/ip-reputation-check) accepts subnet notation and returns a 0–100 risk score. Values above 50 warrant deeper investigation per-database before activation.

Microsoft SNDS (email use cases)

Microsoft's Smart Network Data Services provides data on how Microsoft's mail infrastructure perceives your outbound traffic. If you plan to send email through the leased block, registering your IP range with SNDS gives you visibility into spam rate signals and any filtering Microsoft is applying before a formal blacklist entry occurs.

A note on SURBL

SURBL is sometimes listed alongside IP reputation tools, but it is not an IP blocklist — it's a URI/domain blocklist that checks domains appearing inside email message bodies. It's relevant to your sending domain, not to the IP block itself. If you're setting up email infrastructure, check your sending domain against SURBL separately once you begin sending.

For a deeper comparison of these tools and how to interpret results across different use cases, see our guide to IP reputation tools and best practices.

Delisting process step-by-step

If your IP reputation check turns up blacklist entries, don't panic — most listings are removable. The process varies by database, but the general structure is the same.

Step 1: Identify the root cause. Before submitting any delisting request, understand why the IP was listed. Check the listing details — Spamhaus and AbuseIPDB both provide the reason and, in many cases, the timestamp of the triggering event. If the listing predates your lease, note this. If it's recent, confirm the block hasn't been partially activated somewhere before you took over.

Step 2: Submit a delisting request to each database separately. There is no universal delisting — each blacklist operator manages its own removal process.

• Spamhaus SBL: This is a manual process handled by Spamhaus researchers. Critically, only the network owner (the entity that controls the IP range at the RIR level) can initiate SBL removal — not the end user leasing the block. If you encounter an SBL listing, contact your IPbnb account manager immediately. We will coordinate with the block owner to initiate the removal request on your behalf.

• Spamhaus CSS and XBL: Both support self-service removal through the Reputation Checker at check.spamhaus.org. One request covers both lists when both are present. Removal typically processes within minutes once the system confirms the underlying issue is resolved. Do not request removal until the problem is fixed — repeated requests without remediation can result in loss of self-service delisting access.

• Spamhaus PBL: If the IP genuinely runs a mail server, a single-IP exclusion can be submitted directly from the listing page. Subnet-level removals must be handled by the ISP or block owner via the Spamhaus ISP Portal.

• AbuseIPDB: There is no formal removal process for individual reports. Registered users can submit a takedown request on each IP's page, and all registered users have access to this feature. Confidence scores naturally decay over time as reports age, so if no new incidents are reported after you activate the block, scores will decrease on their own.

Step 3: Wait for propagation. Removal processing ranges from minutes (automated CSS/XBL) to several business days (manual SBL reviews). Don't route live traffic through the block while a delisting is pending.

Step 4: Verify removal. Re-run your IP reputation check using the same tools from Step 1. Only proceed once all listings are cleared.

Step 5: Contact your IPbnb account manager if needed. For listings that require network owner involvement (particularly Spamhaus SBL), that appear to pre-date your lease, or that aren't resolving through standard channels, escalate to our team. We will help coordinate with the block owner and, where possible, facilitate the process or arrange a block substitution. You don't have to navigate this alone — it's part of what the platform is for.

IPbnb reputation guarantee

IPbnb performs a baseline reputation audit on all blocks listed for lease on the platform before they go live. This includes a check across major blacklists and a review of the block's recent abuse history.

However, the internet is not a closed system — a block can receive a new listing between the time of our audit and the time you activate it. This is uncommon, but it happens, particularly with blocks that have been sitting inactive. Dormant IPs can accumulate spam trap hits because major mailbox providers recycle abandoned email addresses and repurpose them as traps; any traffic to those addresses, even accidental, can trigger a listing.

For this reason: if you receive a leased block through IPbnb and discover pre-existing blacklist entries that weren't present at the time of lease signing, contact our support team. We'll help coordinate with the lessor and, where possible, facilitate the delisting process on your behalf or arrange a block substitution.

We recommend running your own pre-activation audit regardless — it takes under 15 minutes and eliminates surprises. If you're leasing to support email infrastructure where deliverability is critical, tell us at the time of inquiry so we can prioritize blocks with the cleanest available history.

Ongoing monitoring setup

Cleaning an IP address once isn't enough if you're planning to use the block for anything that generates significant traffic. New listings can appear at any point, and catching them early — before they affect your operations — is far easier than managing the fallout after the fact.

Set up automated blacklist monitoring

Services like MXToolbox Monitor and HetrixTools allow you to register IP ranges and receive alerts when a new listing appears. Most offer free tiers covering basic blacklist monitoring for smaller ranges; larger blocks or higher alert frequency typically require a paid plan.

Register with Microsoft SNDS and JMRP (email use cases)

If you're using the block for email sending, register your IP range with Microsoft's Smart Network Data Services (SNDS) and, optionally, the Junk Mail Reporting Program (JMRP). JMRP is now managed through the SNDS portal and forwards complaint copies to a designated address when Outlook.com users mark your mail as junk — giving you visibility into complaint rates before they escalate into a formal block.

Set up email authentication before your first send (email use cases)

Configure SPF, DKIM, and DMARC records before sending a single message. These records signal to receiving mail servers that your mail is authorized and authenticated, and they are increasingly treated as a prerequisite — not an improvement — by major mailbox providers. A clean IP without authentication will still produce deliverability problems. If your sending domain is not yet configured with all three, complete that setup before activating the block for any email traffic.

Plan for IP warming if the block has been dormant (email use cases)

A clean block with no recent sending history has no established reputation with mailbox providers. Starting with high-volume email traffic immediately can trigger spam filters even without a blacklist entry. Gradually ramp up volume over the first two to four weeks, prioritizing your most engaged recipients first. If you're using a new block as a replacement for an existing one, warming is less critical — but still advisable if there's been a significant gap in sending activity.

Review AbuseIPDB reports periodically

Even for non-email use cases, periodic checks on AbuseIPDB are worthwhile. A sudden spike in reports can indicate a compromised machine in your infrastructure or a misconfigured service generating anomalous traffic.

Set a calendar reminder for quarterly full audits

Automated monitoring catches new listings, but a manual quarterly review — running the full checklist from the top of this guide — is good practice for any block you're managing long-term.

Once your block is clean and monitoring is in place, you're ready to move to the next step: configuring your leased subnet.

Leasing an IPv4 block through IPbnb? Review the full lease process or read our IP reputation tools guide for a deeper look at how to interpret results across different use cases.