By Yair Knijn · October 28, 2025
The IPv4 block you leased came pre-poisoned: blocklisted, hijacked history, and dead on arrival
An infrastructure director needs more public space, gets quoted a lease on a /22 at well under market rate, and signs because the number is good. Capacity is capacity, the thinking goes, and a clean RIR registration plus a Letter of Authorization is all that matters. The block announces fine. Then mail to half the customer base bounces, a chunk of outbound web traffic gets silently dropped by networks that never see the routes, and the help desk fills up with people who can't reach the new servers.
The wrong assumption is that an IP address is a blank container. It isn't. It arrives with everything the last several tenants did to it still attached, and that history is exactly why it was cheap.
Why an IP address has a credit history
Addresses are reused, not minted. The /24 you just leased may have hosted a snowshoe spam operation two holders ago, sat in a botnet C2 range before that, and been parked dark for a year while reputation systems kept the bad score warm. Operators have a name for this: abuse residue, the reputation damage that sticks to a block across users and time. A range with a dirty past leases at a 30 to 40 percent discount to comparable clean space, and the discount is the market pricing in the cleanup cost you're about to inherit. Price alone is the trap, because the cheapest blocks are cheap for a documented, checkable reason.
Blocklists, spam reputation, and inherited deliverability damage
The fastest damage shows up in email. The big reputation operators key off the address, not the tenant, so a Spamhaus SBL or DBL listing, an AbuseIPDB confidence score, or a CSS entry carried by the prior holder lands on you the moment you announce. Receiving mail servers honor those lists in real time, so your transactional mail bounces or sinks into spam folders on day one, and de-listing is a per-list appeals process measured in days and weeks, not a config change. Before you sign, the block's score against Spamhaus, AbuseIPDB, and comparable databases is a five-minute lookup. Skipping it is how a capacity decision turns into a deliverability incident.
RPKI ROA status and prior hijacking as diligence items
Routing reputation is the quieter failure, and it has a specific leasing trap. With Route Origin Validation now widely enforced, a prefix with no valid ROA gets treated as unknown or, worse, invalid and dropped by networks doing origin validation. The catch with leased space is that only the resource holder can create the ROA in the RIR portal, not you. If the lease doesn't explicitly commit the holder to publish an ROA matching your origin ASN, you announce into a routing void and can't fix it yourself. Pull the block's BGP history too: a prefix with a record of hijacks or flapping origins gets filtered by downstream networks long after the incident, and you'll be untangling someone else's mess from the outside.
Address provenance checks before you sign the lease
Reputation and routing diligence is a short, repeatable checklist, and it runs before money changes hands, not after the incident:
- Blocklist status across Spamhaus, AbuseIPDB, and comparable lists, for the whole range, not a sampled
/32. - An ROA commitment in writing: the holder publishes a valid ROA for your origin ASN before you announce.
- BGP announcement history for prior hijacks, route leaks, or flapping origins.
- IRR object accuracy and a current LOA that actually covers your deployment, including cloud BYOIP if that's the plan.
Run that pass on every range, then record what you found so the next person doesn't relearn it the hard way. In Spot IPAM, each block carries its provenance inside the Environment that owns it, so reputation findings, ROA status, and the LOA chain live next to the allocation instead of in someone's inbox. See how the block provenance and reputation tracking work before your next lease, and check it before you sign rather than after the mail starts bouncing.