The ritual is familiar to anyone who works with proxies: you get an address, run it through MXToolbox, IPQualityScore, Scamalytics, Spamhaus. Green checkmarks mean "clean, can work with it," while red ones indicate "dirty, needs replacement from the provider." The problem is that these tools hardly measure what they are intended to measure. In May 2026, this was finally assessed on a large sample, and the picture turned out to be much more interesting than usual.
What the check of a thousand residential addresses showed
On May 7, 2026, the Databay team published the results of the measurement: 1000 route observations across 25 declared residential ASNs, including 624 IPv4 records (at the /24 prefix level) and 376 IPv6 records (/48), totaling 981 unique routes. The full exit addresses were intentionally not disclosed. Each record was run through six free reputation sources. The results:
- 501 out of 624 IPv4 lines (80.3%) received a label from at least one DNSBL: 494 from the Spamhaus ZEN aggregate, 7 from DroneBL;
- Spamhaus DROP — zero matches across all lines and all declared ASNs;
- Tor exit node lists — zero matches;
- cf.threat_score from Cloudflare — zero on all 1000 measurements;
- cf_client_bot — false on all lines without exception;
- The declared ASN matched the observed in 968 cases (96.8%), and the declared country in 998 (99.8%);
- Four enrichment columns remained completely empty: proxy type from ip2location, confidence from AbuseIPDB, hosting flag from ipinfo, and GreyNoise class.
If you read this table as a "purity assessment," it becomes nonsensical. Eight out of ten addresses are supposedly on blacklists — yet none made it onto any list of truly dangerous infrastructure, and the largest anti-bot platform on the internet rates their threat level as exactly zero. There is no contradiction here. The first number and the second simply measure different things, and neither answers the question "will the target site let me through."
Why 80% on blacklists is not about you at all
ZEN is not a separate list, but an aggregate: it includes SBL, SBLCSS, XBL, and PBL. The last abbreviation explains the entire array of labels. PBL stands for Policy Block List, and Spamhaus describes it as a set of ranges of end users from which mail should not be sent directly to the final mail server. The wording in the documentation is extremely clear: addresses in this set are not necessarily bad — they simply should not send direct mail. A significant portion of the ranges is added by the internet providers themselves through their ISP accounts, and there are specific response codes for this: 127.0.0.10 for records added by Spamhaus and 127.0.0.11 for records added by the provider.
Home internet falls under this description by definition. Your own home address is almost certainly listed in PBL right now — and this is correct, as intended. A residential proxy is essentially someone else's home internet. Therefore, the mass inclusion of such a pool in ZEN is not a sign of defect, but rather indirect confirmation that the addresses are indeed residential, not data center ones with a nice label.
The study honestly notes an important detail: the dump does not publish either raw DNS responses or codes of individual Spamhaus sub-zones. This means that based on this data, it is impossible to determine whether the policy was triggered or if there was indeed a threat. The same blindness applies to any public checker that shows you a single red line "Listed in Spamhaus" without breaking down the sub-zone. The authors state the conclusion directly: the DNSBL label is not a general web reputation score, ZEN reflects mail lists and the logic of SMTP policy, and ranking ASNs by such fields means building a rating without a defensible target variable.
The practical criterion is simple. If you send mail directly via SMTP — PBL is absolutely real for you and must be taken into account. If you parse directories, manage accounts, collect prices, and work through a browser — mail lists have nothing to do with your task at all.
Zero from Cloudflare means "no data," not "safe"
A separate trap is the cf.threat_score field, which still appears in dozens of "anonymity checks." In the measurement, it returned zero for all records without exception, and the authors explicitly note: the field is now always zero, and routes cannot be ranked by it. This is not an assessment of "no threat," but rather a decommissioned metric. A widget that shows you a green zero is showing you emptiness.
The second similar case is cf_client_bot=false on all lines. This value only means that the traffic was not identified through the known bots field, which includes verified crawlers like search engines. This is not confirmation of human origin of the request. Substituting "no signal" for "positive signal" is the most common misreading of such reports, and it is on this that false confidence is built before the first block.
The real decision about you is made by modern anti-bot systems not based on a line in the database, but on a combination of layers: TLS and HTTP client fingerprint, consistency of headers, behavior within the session, history of the specific identifier. How these layers are structured and how they differ among various vendors has been discussed in detail in the comparison of Cloudflare, DataDome, Akamai, and Kasada. The IP there is just one entry point among many, and far from the most significant.
A residential address cannot have a stable reputation
There is also a structural reason why the very idea of a "clean residential IP" does not work. In the research note from the Cloud Security Alliance dated August 13, 2026, it is described as a blind spot of attribution: the same home address in one connection carries the usual family traffic, while in the next it carries a foreign account takeover attempt routed through the same device. Perimeter tools relying on the address cannot distinguish between these two cases in principle.
The scale of the phenomenon in the same note is supported by figures: at least two million devices worldwide were involved in the NetNut pool; the Google Threat Intelligence Group observed 316 different threat clusters operating through the alleged NetNut exit nodes in one week of June 2026; in the Fengwo advertising fraud, about 38,000 unique devices were involved, yielding approximately $1.25 per device per day; the JDY botnet grew from about 650 infected devices in January 2024 to over 1500 by June 2026.
What this meant for the market is known: on July 2, 2026, the FBI, along with the Criminal Investigation Division of the IRS, seized hundreds of NetNut domains, and the Google Threat Intelligence Group published a technical justification linking part of the exit node pool to the Popa botnet. The service owner, the public company Alarum Technologies, contested the allegations. This was not about a marginal service, but one of the notable players in the residential market.
The CSA's conclusion for the defending side is to shift from IP reputation and geofencing to behavioral anomaly detection. Note the symmetry: those who block you already openly recognize the address as an unreliable unit of judgment. It is strange at the same time to build your own procurement strategy on it.
What checkers still measure meaningfully
They should not be discarded — it is important to understand their applicability:
- Type of ASN and hosting flag. The most meaningful signal: data center origin is indeed visible and does influence site decisions. The caveat is the same — in the disassembled set, the ipinfo_hosting and ip2location_proxy_type columns were empty, meaning that even this part is not always provided by free sources.
- Compliance of declared and actual geo and ASN. A fully verifiable quantity: in the measurement, ASN matched in 96.8% of cases, and country in 99.8%. If your pool shows a significantly larger discrepancy, this is a substantive conversation with the provider, not an abstract "dirt."
- Mail DNSBL. Only for mail tasks and only with sub-zone breakdown.
- DROP and ASN-DROP. A narrow list of truly dangerous infrastructure. Zero matches on residential ASNs here is the expected norm, not a merit of the provider.
The mechanics of checking and analyzing cases where an address ended up where it shouldn't have are described in a separate article on checking IPs against blacklists. Here, the more important question is what to replace this procedure with as the main criterion.
What to measure instead of reputation
- The share of successful responses on your specific target. Not "purity" in a vacuum, but the result: 100–200 requests to the domain for which you are buying proxies, with your real client and your headers. The same pool can easily yield 98% on one site and 40% on another.
- The cost of a successful record, not the price per gigabyte. A pool with "bad reputation" and high success rate is cheaper than an ideal checker pool that runs into challenges. How to calculate this metric was discussed in the article on why the price per gigabyte is misleading.
- Layer separation when analyzing blocks. Change the IP with the same client — if the behavior hasn't changed, the issue is not with the address. Change the client or browser profile with the same IP — if the block disappears, the fingerprint was to blame. This five-minute check saves weeks of disputes with the provider.
- Session longevity. For accounts, it is more important not to have "purity," but how many minutes or hours a sticky session lasts and how often the address changes unexpectedly. A drop in the middle of authorization costs more than any label in the database.
- Consistency of geo and ASN in the sample. Take not one address, but a hundred, and compare the declared with the observed — as done in the analyzed study.
- Your own failure log for the target. Response codes, types of challenges, time to the first block. After two weeks, such a log will tell you more about the pool than all six public databases combined.
What this means when choosing proxies
The question "give me clean IPs" is posed incorrectly: a residential address is a shared resource, its history is written by everyone who has passed through it, and yesterday's cleanliness says nothing about tomorrow's. Meaningful questions to the provider sound different: what percentage of successful responses do I get on my type of target, how consistent are the geo and ASN in the sample, how long does a sticky session last, what happens to the address during a drop. There are verifiable answers to these questions, and they can be checked in one test day.
That is why we recommend evaluating residential proxies not by a screenshot from a checker, but by the results on your task — with payment for traffic, no subscription fees, and the ability to test the pool on a small volume before a serious purchase.
In brief
Eight out of ten residential addresses are marked by DNSBL — and this is normal because they are marked by mail policy, not by threat. Zero from Cloudflare means no data, not safety. A home IP physically cannot have a stable reputation while traffic from both the family and a foreign botnet is flowing through it, and the defending side has already recognized this by shifting to behavioral analysis. The only metric that truly predicts your performance is the share of successful responses on your target, measured by you. Everything else is hygiene, not strategy.