How IPs End Up on Blacklists and How to Stay Off

A blacklist is not one giant database in some regulator's cloud, as many imagine. It's dozens of independent lists maintained by different people and organizations under different rules, and services pull them in by the batch. Let's unpack how this system works, why an address ends up there, and what's within your control and what isn't.

This material is about engineering your own infrastructure and is educational in nature. You are responsible for complying with the laws of your own jurisdiction.

What a blacklist really is

When a service shows "VPN detected" or a bank refuses a "login from abroad," there's no single central registry behind it. Behind it sits a set of independent lists, each with its own logic:

• DNSBL / RBL (Spamhaus, SORBS, and dozens of others) — historically built against spam, served over DNS. Mail servers and others check against them in real time.
• Fraud/VPN detectors (scamalytics, ipqualityscore, and the like) — commercial databases that catalog VPN exit nodes, proxies, Tor, and "risky" addresses, and sell access to services.
• Services' own internal lists — banks, marketplaces, and AI services maintain their own registries of datacenter ASNs and suspicious addresses, supplementing purchased databases with their own statistics.

The key point: these lists are independent and uncoordinated. An address can be clean on one and dirty on three others. So "I checked one checker, all green" guarantees nothing — the service the client connects to is looking at a different list.

Why an address ends up there

The reasons split into "it's your own fault" and "bad luck with the neighbors."

Your own fault:

• Abuse from the node. If one of your clients spams, brute-forces, DDoSes, or mines through your address, complaints fly to the ASN owner and the address lands on the lists. One noisy client can burn a node for everyone.
• Mass uniform traffic. A sudden spike of identical connections from a freshly stood-up address is a classic pattern by which detectors flag an IP as a VPN exit.
• A datacenter ASN as such. The mere fact that the address belongs to a hosting provider rather than a residential ISP is already grounds for some lists. Here you're only "at fault" for your choice of host.

Not your fault:

• Subnet neighbors. In many databases, reputation lives at the level of an address block, not a single IP. Someone in the neighboring addresses misbehaved — the whole range gets tagged, including you.
• A "flagged" hosting subnet. If a provider is known as a VPN host, detectors enter its ranges wholesale, preemptively.
• List inertia. An address could have been released and passed to you already carrying someone else's abuse history that you never committed. And it clears from the lists slowly.

The conclusion worth internalizing once: you're responsible not only for your own behavior, but also for your choice of subnet. A white address at the start (one that isn't blacklisted and keeps working through RF throttling) sitting in a dirty block is a bad bet.

Why this is a separate problem from DPI

It's easy to confuse a blacklist with a border block, but these are different layers. DPI/TSPU looks at how you connect — fingerprint, transport, handshake behavior — and lives between the client and your node. A blacklist looks at who connected — the address's reputation — and lives on the end service's side, behind your node. You can pass DPI flawlessly and still run straight into a blacklist, because these are two different checks at two different points. A blacklist isn't cured by masking — only by the whiteness of the address itself.

How to stay off — what's within your control

You can't fully insure yourself, but you control most of the ways you land there.

• Choose the subnet, not just the address. Before buying, look at the ASN and the reputation of the block, not a single IP. Don't take the only node in a range packed with VPN abuse.
• Don't let clients burn the node. Anti-abuse and anti-fraud at the entry point isn't only about money — it's about keeping one spammer from sending your address to Spamhaus. Limit obvious abuse patterns, catch sharing and multi-accounts.
• Separate dirt from whiteness. A disposable entry point you don't mind burning, kept apart from a white exit on a good ASN. A cascade is the architectural answer to blacklists: what burns, burns on the cheap entry, while the exit holds its reputation.
• Monitor and rotate. Regularly sample the reputation of your live addresses and swap the ones starting to go red before a client notices. Keep your own blocklist and never hand out burned addresses again.

A note on shared blacklists — from the other side

There's a flip side, useful in business: blacklists can be allies, not only enemies. Within the operator community, shared lists of problem users are maintained — scammers, referral-fraud abusers, DDoS organizers, resellers, and subscription "sharers." The same set of people migrates between services and burns everyone's nodes one after another. By connecting such a shared list to your bot, you turn away known abusers right at the entry — and at the same time protect your addresses' reputation from their antics.

The logic is the same as with IP blacklists, only applied by you: the community's collective memory saves everyone nerves and money. And the etiquette is the same — lists sometimes carry false positives, so keep your own whitelist and admins in the exclusions, review disputed cases by hand, and once you catch an abuser, return them to the shared list so they don't burn the next operator's node. We cover the practical setup of such a list in the bot in the section on anti-fraud and sales.

Bottom line

A blacklist is a multitude of uncoordinated lists, some of which you land on because of your own behavior, and some because of your choice of subnet. It's cured not by masking but by address whiteness, by separating dirt and whiteness across a cascade, and by discipline: monitoring, rotation, your own blocklist, anti-abuse at the entry. Exactly how to check reputation and keep a reserve of white addresses is covered in the practice pieces "Checking IP Reputation and Warm-Up" and "Where to Get White Subnets and How to Check."