Vetting a subnet before you lease it: proxy, VPN and email providers
A proxy network, a VPN service and a bulk email sender look like three different businesses, and they share one weakness exactly. All three live or die by the reputation of the addresses they route from, and that reputation is inherited: it attaches to the range, not to whoever holds it this month. Lease a subnet without reading its past and you have bought the last tenant's history sight unseen. Here is how each of the three should read a range before it becomes theirs.
The shared weakness
Reputation systems key on the address. Blocklists, fraud scores, VPN and proxy classifiers, streaming denylists, mailbox reputation: every one of them stores its opinion against the numbers, and none of them resets when a range changes hands. The intermediary you lease from can automate the paperwork perfectly and still hand you a range that three of those systems remember badly. Worse, a degraded range is a delayed failure: it passes a quick test and then breaks once it carries real production volume, which is precisely when you have committed to it.
Clean space knows this about itself, which is why it costs more. Well-documented blocks with no blocklist history lease quickly and at a premium, while ranges with reputation problems lease slowly, at a discount, or not at all, and experienced lessees now ask for a reputation report before they sign. The single lookup this piece keeps pointing at is how you produce that report for yourself instead of taking the seller's word.
Proxy providers: is it already burned as proxy space
For a proxy operator the nightmare is leasing a range that is already classified as proxy space, because the whole product is addresses that do not look like proxies. If a feed already flags the block, or a scanner has already caught proxies serving there, the range is worth a fraction of clean space for your purpose and no amount of fresh paperwork repairs it.
So read the block for prior anonymity use before you take it. Look at what independent feeds have said about addresses inside it, and on which dates, and look for the specific tell that a range has been proxy space before: a cluster of addresses that read as proxy or VPN, a history of the block being announced by networks whose business is anonymity, or our own confirmation that proxies answered there. That last signal is worth a note, because a range can look clean today precisely because the previous proxy operator switched off last week.
subnethistory keeps a proxy we confirmed and later found switched off as a lapsed finding, grouped under "proxy, now quiet" with the date we last saw it serving, rather than letting it revert to clean. For a proxy buyer that is the exact distinction that matters: a block that ran proxies until recently is not the same asset as one that never did, even though a point-in-time check reads both as empty today.
VPN providers: will streaming and signups accept it
A VPN service needs the opposite of a proxy operator in one respect and the same in another. You are openly a VPN, so you are not hiding, but your users still expect to reach streaming platforms, sign up for services and pay, and those gates reject addresses classified as VPN, proxy or datacenter. Inheriting a range that streaming services already block, or that a previous tenant got flagged through abuse, means your users hit walls from day one and blame you.
The complication is that VPN and proxy classification is driven by observed traffic patterns, not by who owns the space, so a range can carry a stale classification from behaviour that is no longer happening, or be tarred because a free-VPN or P2P app once turned its addresses into relays. Reading the history separates a range with an old, decaying classification, which you can rehabilitate, from one whose reputation was earned by sustained abuse, which you often cannot. Check what the addresses have been flagged as over time, whether the block has bounced between unrelated operators, and whether the flags are recent or aging out. A range that was flagged two years ago and has been quiet since is a very different proposition from one lit up last month.
Email providers: is it clean enough to send
For a sender, reputation is bound to the sending address, so a range carrying prior spam history is throttled or rejected on arrival no matter how correct your SPF, DKIM and DMARC are. Authentication proves who you are; it does not clear who the addresses were.
Before leasing a range to send from, check its blocklist and abuse history across the whole prefix, not one address, because listings and classifications are often applied at block granularity and a /24 can mix clean and burned addresses. Read the dates: a listing that predates the range's availability is inherited, and knowing that, with the transfer date, is the strongest line in any delisting request. Confirm the range can carry proper reverse DNS and that nothing structural, like a hijack history or a stretch of abuse-driven silence, sits in its past. Then, and only then, plan the warm-up, because a range with history needs its past cleared before the ramp, not during it.
What to read, and in what order
All three businesses read the same record; they just weight it differently. Cheapest and most disqualifying first:
- Reputation over time. What independent feeds have flagged inside the block, on which dates, and whether anything is active now or merely lapsed. This is where proxy and VPN operators should start.
- Blocklist and abuse history. Across the whole prefix, with listing dates. Where email senders should start.
- Origin and routing history. Which networks announced the block and when, and whether it churned between unrelated operators or went dark before you were offered it. A hijack or an abuse-driven silence hides here.
- Registration. Who the record says holds it, whether the paperwork is coherent, and whether the party leasing it to you appears in the chain at all.
This is the same due diligence a buyer runs before purchase, applied by the three operators for whom address reputation is not one input among many but the entire product. And it is the same history whether you approach it from the proxy, VPN or mail side; only the line you read most carefully changes.
After you deploy, keep watching
Vetting is not a one-time gate. Once your traffic is on the range, its reputation is being written by you and by anyone sharing adjacent space, and the failure you most want to catch is the slow one: a blocklist entry that appears in week six, a classification that drifts, a neighbour that gets the covering aggregate flagged. Re-check your own prefix on a schedule and read it as an outsider would, because the first bounce or the first blocked signup is a worse way to learn than a dated report you pulled yourself. For a leased range this doubles as evidence: if the block arrived clean and degraded on your watch, the dated history says so, and if it was already degrading when you took it, that is a conversation to have with whoever leased it to you, backed by dates rather than by a screenshot.
Proxy, VPN and email operators are, in the end, in the same business as this site: reading what an address has been, before it costs them. The difference is that for them it is not due diligence on the side. It is the product.
Look up any prefix on the front page before you route traffic through it. The report shows what the addresses have been flagged as and when, whether a proxy we confirmed is still serving or has gone quiet, who has announced the space over time, and says plainly when nobody has checked something.