How to read an IP blacklist report before you buy or lease a block

Before you buy or lease an IPv4 block, someone will run it through a blacklist checker, and the result is usually a long column of list names with green ticks and red crosses. Read carelessly, that report can scare you off a perfectly usable block or wave a damaged one through. This guide explains how to read it properly and turn it into a clear decision.

Check the whole block, not one address

Many quick checks test a single IP, often the first address in the range. That tells you very little about a /22 or a /20. Listings are applied per IP or per range, and problems tend to cluster where a particular previous customer sat.

Ask for, or run, a report that covers every address in the block. Most bulk tools accept a list of IPs or a CIDR range. For each hit, the report should show:

• the list that returned it
• the exact IP or range listed
• the listing reason or record reference, where the list publishes one
• the date of the check, since reputation data changes daily

A report that gives only a total, such as “7 listings”, with no per-address detail is not enough to make a decision on.

Know which listings carry weight

Multi-list checkers often query dozens of DNS blacklists, and they are not equal. Some are used widely by mail providers and filtering products, many are niche, and some are no longer maintained but still appear in older tools. Weight them accordingly.

Lists that most operators take seriously include the Spamhaus datasets (SBL, CSS, XBL and DROP), the Barracuda Reputation Block List and SpamCop. Others escalate aggressively: UCEPROTECT Levels 2 and 3, for example, list a whole range or an entire ASN because of activity from neighbouring addresses. Those listings describe the network the space sat in rather than the specific IPs you are getting, and their impact depends on whether the receiving systems you care about use them. If you do not recognise a list, find out who runs it, whether it is still active and how it decides listings before giving it weight.

Also separate policy listings from reputation listings. The Spamhaus PBL is a policy list: it marks space that should not send mail directly to mail servers, typically residential or dynamic ranges. A block that previously served broadband customers may still be on it. That is a configuration matter, which the holder can have updated once the space is used for servers, not evidence of abuse. Reputation listings, based on spam, malware, attacks or criminal hosting, are the ones to understand in detail.

Read the pattern, not just the count

The same number of hits can mean very different things. Look at how they are distributed:

• Scattered single-IP hits on automated lists usually point to individual hosts with a past sending problem. They are common on space that has been in use, and automated listings tend to lapse once the activity stops.
• Clusters within one /24 suggest a single previous customer, such as a bulk mailer or a compromised group of servers. Find out whether that customer has gone.
• Range listings on manual lists, such as a Spamhaus SBL record covering a whole subnet, mean a researcher concluded the space was tied to an abusive operation. These need the most attention.
• Network-wide or ASN-level listings describe the current or previous network more than the addresses. They may fall away when the block moves to a new, clean ASN, but confirm that rather than assume it.

Look beyond mail blacklists

DNS blacklists mainly protect email. If you plan to run web services, VPNs, APIs or customer-facing platforms, other reputation sources matter as much:

• threat-intelligence scores, such as AbuseIPDB ratings, which reflect reported attacks, scanning and brute-force attempts
• IP-type classifications that tag addresses as hosting, proxy or VPN space
• geolocation records, which may still point to the previous holder’s country
• the routing history of the block, showing which networks announced it and whether it was ever hijacked

A block that is clean on every mail list can still be challenged by a fraud-prevention service because of how it was used before. Ask for these checks alongside the blacklist report, especially if the space is going behind user logins or payment flows.

Turn the report into a decision

Once you understand the listings, sort the block into one of three outcomes:

1. Proceed. No reputation listings, or only isolated automated hits and policy entries that can be cleared after transfer.
2. Proceed with conditions. Listings that are explainable and fixable. Agree that the seller or lessor delists before transfer or lease start, include a warranty on listing status at handover, and set out a remedy if serious listings appear afterwards.
3. Walk away or renegotiate. Open manual listings on ranges, DROP listings, or a history that suggests the space was used for sustained abuse.

Whichever outcome you reach, keep the report with the deal file. It records the condition of the block at the time you took it on, which matters if a dispute about listings arises later.

Finally, run the check again shortly before transfer or lease start. Reputation changes, and a report you reviewed a month ago may no longer reflect the block you are about to receive.

How TACS can help

Our IP security audit checks every address in a block against the major blacklists and threat-intelligence sources and explains which findings matter for your use case. If you are sourcing space through Buy IPv4 or Lease IPv4, we can run that audit on any candidate block before you commit, and arrange delisting where it is needed.