IP Space Acquisition Due Diligence

Almost no ESP receives virgin (never-before-announced, never-before-used) IP space. IPv4 exhaustion means new sending IPs are almost always recycled — previously allocated, returned or revoked, and reissued — or transferred/leased on the secondary market. Recycled and transferred addresses carry the reputation and blocklist history left by their previous holder. Diligence before you send on an IP block is cheaper than a warm-up that starts from a deficit you did not cause.

This article covers how to vet IP space before it enters a sending pool. It is upstream of IP Warm-Up (what to do once the IP is yours) and Basic IP Allocation (how many IPs to run). For the mechanics of the blocklists you check against, see Blocklists & Spamhaus and the Spamhaus Listings Deep Dive.

Why recycled IPs carry inherited reputation

Reputation attaches to the IP address, not to the holder. When an address block changes hands, the new holder inherits:

• Blocklist entries placed on the block for the previous registrant's activity. ARIN warns explicitly that "some of the address space returned to ARIN remains on external, individually managed IP blocklists based on activity by the previous registrants," causing "problems with routing, geolocation, and email delivery for the new registrant" even though the address has been properly cleared for reissuance.
• Mailbox-provider reputation — a Gmail/Microsoft/Yahoo memory of the IP's past sending behavior that no registry can reset.
• Geolocation and routing artifacts — stale geo-IP mappings, and stale entries in others' route filters / bogon lists.
• Spam-trap associations — recycled addresses may have sent to traps under prior ownership; the mail-stream equivalent risk is covered in Spam-Trap Incident Response.

Registries do not remediate reputation. ARIN's role is limited: it clears returned/revoked space for reissue and publishes a quarterly "IPv4 Addresses Cleared for Waiting List" file, but it "delegate[s] reputation remediation to the new registrants and blocklist maintainers." ARIN's two-sided guidance:

• New registrants should contact service providers and blocklist operators directly to request removal of stale data.
• Blocklist operators should regularly review ARIN's quarterly cleared-for-waiting-list publication to decide which space to remove.

Practical consequence: a freshly allocated block from ARIN's waiting list is not a clean slate. Treat it as suspect until you have checked it.

The IPv4 transfer- and lease-market abuse problem

The secondary market — buying, selling, and leasing IPv4 blocks — is where much of the risk concentrates. ARIN's IPxo post (Nov 2022) documents the abuse vectors:

Abuse vector	Description
Post-transfer blacklisting	Research shows IP addresses are 4 to 25 times more likely to be blacklisted after a transfer than before — the market itself correlates with reputation damage.
Black-market hijacking	Malicious actors have hijacked hundreds of thousands of RIR-assigned IPs for resale to criminals.
Legacy-space exploitation	Outdated/dormant registration records make legacy blocks vulnerable to hijacking for spam, phishing, and malware.
Legal acquisition, illegal use	Criminals obtain IPs legitimately via transfer markets and waiting lists, then misuse them — the acquisition is clean, the use is not.

ARIN abuse statistics (Q3 2022) that frame the base rate: 1,340 abuse cases, of which 60.65% were spam-related; 7.42% each copyright infringement and login attacks; ~90% handled automatically but spam cases required manual intervention 46% of the time.

Implications for an ESP acquiring space:

• Leased space is riskier than owned space for reputation control. You do not control the block's future or its full history, and lease platforms pool many lessees; a bad neighbor or a prior lessee's activity follows the block.
• Verify the chain of custody. ARIN's mitigation emphasis is entirely on accurate, current Whois/RDAP records — a block whose registration data is stale or inconsistent with the seller's identity is a hijacking red flag, not just a paperwork nuisance.
• A block that looks cheap may be cheap because it is dirty. Reputation problems are the market's discount mechanism.

Reputation-history data sources

ARIN WhoWas — historical registration record

WhoWas gives "authorized users access to historical registration information for a given IP address or ASN" — the complete public history of how a block was allocated across organizations and contacts over time. This is the authoritative way to see who held the block before you and how often it changed hands.

Attribute	Detail
What it returns	Full historical registration records for the resource plus associated org and POC handles
Delivery format	A .zip containing a ReadMe, a summary of associated handles, and individual .tsv files for Net Handles, AS Handles, Organization Handles, and POC Handles
Access	Requires an ARIN Online account (no POC/Org-ID link needed) and a one-time authorization request
Review	ARIN staff reviews within two business days; you must agree to the WhoWas Terms of Use and state intended use, projected query frequency, and whether the data supports advertising/marketing/marketing-research goals
Restrictions	Not for high-volume querying; excessive querying can terminate access
vs. Whois/RDAP	Whois/RDAP show current registration; WhoWas shows the complete history, and its reports are much larger and more complex

What to look for in a WhoWas report: frequent ownership changes, a prior holder in a spam-heavy business, gaps where the block was revoked/returned (often a sign of past abuse), and whether the block passed through known lease/transfer brokers.

ARIN RDAP — current registration and ownership

RDAP (Registration Data Access Protocol, the structured-JSON successor to legacy Whois) is the quick, unauthenticated first check for current ownership, allocation status, and abuse contacts. ARIN's service (search.arin.net/rdap, REST base https://rdap.arin.net/registry/) auto-detects query type and supports:

Query type	Example
IP address / CIDR	https://rdap.arin.net/registry/ip/192.0.2.0
Autonomous System Number	https://rdap.arin.net/registry/autnum/64496
Entity (org / POC handle)	https://rdap.arin.net/registry/entity/HANDLE
Reverse-DNS domain	https://rdap.arin.net/registry/domain/2.0.192.in-addr.arpa

Output is structured JSON (an evolution over free-text legacy Whois). RDAP follows IANA bootstrap referrals, so a query to one RIR redirects to the RIR that actually holds the resource. Use RDAP to confirm: the block is registered to the party selling/leasing it, the abuse/POC contacts are current, the allocation status matches the deal, and the registration is not obviously stale (a hijacking indicator).

RIPEstat — routing history and blocklist/abuse data calls

The RIPEstat Data API provides programmatic, global data for vetting a block regardless of which RIR issued it. Base pattern:

https://stat.ripe.net/data/<endpoint>/data.json?resource=<prefix|IP|ASN>&param=value

Responses are JSON with common fields status (ok/error/maintenance), data_call_status (supported/deprecated/development), version, and data. Unlimited requests are permitted, but register (and pass a unique sourceapp parameter) for regular use above ~1,000 requests/day.

Routing History (/data/routing-history/) is the key acquisition-diligence call: it returns "the history of announcements for prefixes, including the origin ASN and the first hop," sourced from RIS route collectors — i.e. which ASNs announced this block, and when.

Parameter	Purpose
resource	Prefix / IP / ASN to investigate (required)
starttime / endtime	Query window (ISO-8601 or Unix time)
min_peers	Filter low-visibility announcements (default 10)
normalise_visibility	Add peer-visibility percentages
include_first_hop	Include the first-hop ASN
max_rows	Cap results (soft cap 3,000)

Response is organized by announcing ASN, each with prefix, timelines (announcement periods with start/end), and full_peers_seeing (RIS collectors observing the route). Example: https://stat.ripe.net/data/routing-history/data.json?resource=192.0.2.0/24.

How it helps vetting: spot when the prefix changed announcing ASNs, whether it sat in a spam-friendly or hijack-prone ASN, whether announcements were fragmented/erratic (a snowshoe or hijack pattern — see Basic IP Allocation on snowshoeing), and whether the seller's claimed ASN matches actual routing history.

Other RIPEstat data calls useful pre-acquisition:

Data call	Use
DNS Blocklists	Whether/when the resource appeared on tracked DNSBLs
Abuse Contact Finder	Current abuse-reporting contact for the resource
Allocation History / Historical Whois	Registry-side ownership changes over time (cross-check WhoWas)
Transfer History	Recorded ownership transfers
Routing Status / BGP Updates	Current announcement state and recent routing changes
Address Space Usage / Address Space Hierarchy	Allocation patterns and parent/child relationships

IPv4.Global reputation reporting — aggregated marketplace check

For blocks moving through the secondary market, IPv4.Global (a Hilco Streambank IPv4 marketplace) offers a free reputation report to buyers, sellers, lessors, and lessees — a convenient one-shot aggregation that queries 10 independent blocklist services plus registry, routing, and geolocation data:

• Blocklist / reputation sources: Spamhaus (SBL, CBL, DROP, EDROP, and ISP lists), UCEPROTECT, Feodo Tracker, Blocklist.de, RBL.interserver.net, and SpamCop.
• Registry data: the RIRs and ARIN's WhoWas.
• Routing/geolocation: MaxMind, IP2Location LITE, and RIPEstat.

Access model: buyers request real-time reports on listings; sellers/lessors get auto-generated reports on listing/approval; active lessees get twice-weekly automated reports plus on-demand generation. Each report is "a snapshot of the block's history at the time the report was generated" — so regenerate immediately before you commit, not off a stale copy. Treat it as a fast screen, not a substitute for your own DNSBL and provider-reputation checks: the vendor's blocklist set is finite and does not include mailbox-provider (Gmail/Microsoft/Yahoo) internal reputation, which no external tool exposes.

Pre-acquisition checklist

Run before signing/buying/leasing. Any red flag is grounds to renegotiate price, demand a different block, or walk.

• RDAP lookup — confirm current registrant matches the seller/lessor; abuse/POC contacts current; allocation status matches the deal.
• WhoWas report (or IPv4.Global's registry section) — count ownership changes; identify prior holders; note revocation/return gaps.
• RIPEstat Routing History — review announcing ASNs over time; flag spam-friendly/hijack-prone ASNs and fragmented announcement patterns.
• Blocklist sweep across zones — query each address (and the covering CIDR) against the major zones. At minimum: Spamhaus ZEN (zen.spamhaus.org, covering SBL/CSS/XBL/PBL in one query — see Blocklists & Spamhaus), plus Spamhaus DROP/EDROP (hijacked/leased-to-spammers netblocks you must never route), UCEPROTECT, SpamCop, Barracuda, SORBS/legacy zones as relevant.
• PBL status — check pbl.spamhaus.org. A PBL listing (return code 127.0.0.10 ISP-designated or 127.0.0.11 Spamhaus-designated) means the range is policy-marked as not-for-direct-to-MX mail (dynamic/residential/IoT space). Acquiring PBL-listed space for bulk sending means you must get the listing changed and convince the registrant to re-designate the range — a leading indicator the block was never intended for a mail server.
• DROP/hijack check — a block on Spamhaus DROP (127.0.0.9 under SBL) is a hard no: it is treated as hijacked or wholly controlled by spammers and is dropped at the routing layer, not just filtered.
• Reverse-DNS state — confirm you can set matching PTR records for every address; existing stale/spammy rDNS must be replaceable.
• Reputation-service snapshot — Senderscore, Cisco Talos (Good/Neutral/Poor), and Google Postmaster Tools history if available for the block.
• Volume-vs-block-size sanity — will your intended volume support the minimum 40,000 messages/week per IP without snowshoeing across too many addresses?

Post-acquisition checklist

Once the block is yours but before production sending:

• Set rDNS/PTR for every sending IP, matching HELO/EHLO and pointing to a hostname on a domain you control (a Google/Yahoo bulk-sender requirement).
• Request delisting of inherited entries. For stale blocklist entries from the prior holder, contact each operator directly, citing that the block was reissued to you (ARIN's recommended path). Reference ARIN's quarterly "cleared for waiting list" file where relevant.
• PBL delisting. If the block was PBL-listed, use Spamhaus self-service removal for space you legitimately run a mail server on, or have the network owner re-designate the range.
• Re-check reputation after delisting propagates — DNSBL removals and geo-IP corrections take time; re-run the pre-acquisition blocklist sweep before your first campaign.
• Warm up as if from a deficit, not neutral. Recycled/transferred space frequently starts below neutral (see IP Warm-Up — new/unknown IPs start slightly negative). Follow the standard warm-up ramp, and lead with your most-engaged recipients so providers rebuild a positive memory over the inherited one.
• Isolate warm-up risk in the pool architecture so a block that turns out worse than diligence suggested does not contaminate established IPs — see Multi-Tenant Architecture and Advanced IP Segmentation.
• Baseline monitoring from day one — seed/inbox-placement testing and postmaster-tools/SNDS enrollment before volume ramps, so you detect an inherited-reputation problem in the first campaigns, not the fifth.

Key principle

Registries transfer title, not reputation. A block cleared by ARIN, sold on the transfer market, or leased through an automated platform can still be blocklisted, PBL-marked, hijack-tainted, or remembered poorly by mailbox providers. The transfer market's own data — 4-to-25× higher post-transfer blacklisting — means the burden of proof is on the acquirer. Verify prior use before you send; assume a below-neutral starting point; and warm up accordingly.

Related

• IP Warm-Up — the ramp once the IP is yours; recycled space starts below neutral
• Basic IP Allocation · Advanced IP Segmentation — sizing and isolating the fleet
• Blocklists & Spamhaus · Spamhaus Listings Deep Dive — the zones and return codes to check against, and delisting workflows
• Spam Traps · Spam-Trap Incident Response — recycled addresses and inherited trap risk
• Multi-Tenant Architecture — isolating unvetted/new IPs from established reputation
• Reputation Monitoring — the ongoing checks after acquisition