Why your newly bought IP range is already blocked

Reputation is keyed to the address. It does not move with the holder, a transfer does not reset it, and no part of the system is obliged to tell you it is there. That is the whole mechanism, and once you accept it the problem becomes tractable. You are not fixing your network. You are working out what the previous tenant did, and which of several unrelated systems still remembers it.

Reputation belongs to the number

A subnet is a range of integers. A /24 is 256 of them, a /22 is 1,024. Every system that forms an opinion about your traffic stores that opinion against those integers: a blocklist entry, a fraud score, a classification feed's label saying "this is hosting", a CDN's memory of an address that scraped it for a month.

Registration lives somewhere else entirely. When a block transfers, the RIR updates its record and publishes the transfer in a statistics file. That is the full extent of the event. No RIR publishes a transfer feed that reputation systems are known to consume, and none of the major blocklists, mailbox filters, geolocation feeds or payment scoring engines documents clearing its data against registry changes. Each keeps its own view, keyed on the address. Whatever their internals, the observable behaviour is consistent and is the part that matters to you: a change of registrant does not, on its own, clear anything.

There is a defensible reason for that. If reputation reset on transfer, clearing it would cost no more than a paper sale to a shell company, and the whole apparatus would be worthless inside a year. So it does not reset, and the cost of that design falls on the buyer who did nothing wrong.

Why nobody tells you

There is no clearing house. Nothing in the transfer process contacts the systems holding the listings, because there is no register of them and no protocol to contact them with.

• Nothing is notified. The RIR knows. The seller knows. You know. Nobody else is told, at any point.
• There is no single list to check. The public DNS-based blocklists are queryable, and a checker tool will test perhaps 50 to 100 of them in a second. The systems that cost real money are not queryable at all: internal reputation at the large mailbox providers, the scores inside fraud vendors and payment processors, and the classification data that retailers buy. You discover those by being declined.
• Every system ages on its own schedule. An automated listing may drop out within days once the traffic stops. A manually entered one sits until somebody asks. A hosting classification does not age at all, because from the feed's point of view nothing about it is wrong.
• The market selects for it. Space with a clean, boring history is worth more and tends to move through channels you were probably not in. Cheap space is cheap for a reason, and often the reason is exactly this.

Five causes that look identical

From inside your network these all present the same way: things that should work do not. They have almost nothing else in common, and treating the wrong one wastes weeks. Start here.

An inherited listing

The clean case, and the one everybody assumes they have. Listings are frequently at range granularity rather than per address: an SBL entry commonly covers a CIDR block, which is why testing one address and finding it clear tells you almost nothing. Query several addresses spread across the range, and read the listing date and reason text rather than just the yes or no. A listing dated before your acquisition is inherited, and saying so, with the transfer date, is the single most useful sentence in a removal request.

A neighbour is the problem

If you bought a /24 out of a /22 and the other three stayed with the seller, you can be entirely clean and still be caught. Many systems aggregate at /24, and some aggregate far higher: UCEPROTECT level 2 lists whole allocations and level 3 lists whole autonomous systems on the strength of one offender. Fraud scores commonly carry a neighbourhood component. Check the blocks on either side of yours, and check who announces the covering aggregate. If a neighbour is the cause you cannot fix it. You can only demonstrate separation: your own announcement, your own rDNS, your own records, and time.

Classified as hosting, which is not a blocklisting at all

This one is misdiagnosed more than any other. Geolocation and IP intelligence feeds label ranges by type: residential, mobile, business, hosting, datacenter, VPN. Retailers, streaming services, ticketing platforms and signup flows use those labels as a risk input. A range marked as hosting gets declined at rates that feel exactly like a blocklisting from the inside, and there is nothing to delist from, because nothing is asserting misconduct. Usually the label is simply correct.

Where it goes wrong for a new holder is when the label is stale or too broad: the range is marked VPN or proxy because the previous tenant ran one, or it geolocates to the wrong country because an old record said so. Those are correctable, and the levers are all record-side. Fix the RIR object. Publish a geofeed (RFC 8805) and reference it from the RDAP or whois record in the way RFC 9092 describes. Keep the PeeringDB entry accurate. Submit corrections to the feeds that accept them: MaxMind and IPinfo both do, several others accept nothing. Then wait for their next refresh, which may be a week or may be a quarter.

The records still name the previous holder

Cheapest to fix and most often skipped. If rDNS still resolves to the previous tenant's naming scheme, or the inetnum netname still reads something like PROXY-NET-01, then every receiving admin who looks you up sees them rather than you. Worse, abuse reports go to the contact in the old record, so you never hear about the compromised host inside your own range until somebody blocks it.

Set rDNS for everything you announce. Update the netname, the organisation and the abuse contact. In the ARIN region, reassign properly rather than leaving the parent record to speak for you. Remove route objects the seller left behind. This is a few hours of work and it is a prerequisite for everything else: a removal request sent from a range whose records still name a proxy operator tends to get the answer it looks like it deserves.

Missing or stale RPKI, and leftover IRR objects

Not blocking, filtering, which is why it presents as partial reachability rather than a bounce. There are two failure modes and the second is specific to transfers. The first is having no ROA, which is legal, increasingly unusual, and attracts some extra scrutiny. The second is that a ROA created by the previous holder is still in place and still names their AS. Your announcement from your AS is then not merely unsigned, it is RPKI-invalid, and the networks that drop invalids, which now include several of the largest transit providers, will not carry it. The same happens when an inherited ROA has a maxLength that does not cover the prefix length you are announcing.

You cannot revoke somebody else's ROA. Either the seller does it or the RIR does it as part of the transfer, and if neither has happened, your range stays partly unreachable until one of them acts. The same applies to route objects in the IRR: a conflicting entry can both cause filtering and stop you creating your own. Check validation state before you announce, not after the tickets start arriving.

What each lever actually moves

The levers are not interchangeable and most of them do nothing for most of the causes above. This is the honest mapping.

Two things are worth saying plainly. Some lists offer a paid express delisting alongside a slower free one. Before paying, find out whether anything you actually care about consults that list: check whether the bounce messages your mail is generating name it, and whether the receivers blocking you cite it. A listing nobody downstream reads costs you nothing to leave in place, and the fee buys a cleaner dashboard rather than delivered mail. And if what you inherited was sustained, deliberate abuse rather than one compromised host, there is no fast lever at all. Internal reputation at a large mailbox provider is rebuilt through weeks of low-volume, low-complaint sending, and there is no way to shortcut it. A range known for years as proxy space carries a classification no correction request will overturn, because it was accurate when it was applied. At that point the honest options are a long rehabilitation, a use that does not depend on reputation, or resale, and that is a decision better priced before purchase than discovered after.

Knowing what you inherited

Every remedy above depends on knowing which problem you have, and that depends on what the previous tenant was doing. A range that sent spam has a mail problem: delisting plus patient warming, measured in weeks. A range that ran exit proxies has a classification problem, measured in months and sometimes not resolvable at all. A range that sat behind carding infrastructure has a fraud-score problem, and those scores were built from observed transactions and decay slowly.

Nothing in your own records tells you which. The registry shows the current holder, and the current holder is you. What you need is the earlier state: which AS announced the range and between which dates, whether it went quiet for a stretch before the transfer, which is a common shape after an enforcement action, and what security feeds said about the addresses inside it on the days they were sampled. Those observations exist only if somebody recorded them at the time, because current-state tools overwrite rather than accumulate.

That is what this archive holds: origin history, transfer records and dated sampling verdicts for a prefix, covering the period before you owned it. It will not delist anything, and it cannot. What it does is tell you what you inherited and when, which decides which of the levers above is worth your week.