IP Space Acquisition Due Diligence

If you are adding IP addresses to a sending pool, the addresses you get have almost certainly been used before, and their history comes with them. Checking that history before you send is cheaper than a warm-up that starts from a deficit you did not cause.

Almost no ESP receives virgin IP space, meaning space that has never been announced or used. Because IPv4 addresses have run out, new sending IP addresses are almost always recycled (previously allocated, returned or revoked, and then reissued) or transferred or leased on the secondary market. Recycled and transferred addresses carry the reputation and blocklist history left by their previous holder.

The checks below apply before an IP block enters a sending pool. Once the addresses are yours, IP Warm-Up covers what to do next, and Basic IP Allocation covers how many IP addresses to run. For how the blocklists you check against work, see Blocklists & Spamhaus and the Spamhaus Listings Deep Dive.

Why recycled IP addresses carry inherited reputation

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

• Blocklist entries placed on the block because of 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.
• Reputation at mailbox providers. Gmail, Microsoft and Yahoo remember the IP address's past sending behavior, and no registry can reset that memory.
• Leftover geolocation and routing data: outdated geo-IP mappings, and outdated entries in other networks' route filters and bogon lists.
• Associations with spam traps. Recycled addresses may have sent to traps under their previous owner. Spam-Trap Incident Response covers the equivalent risk for a mail stream.

Registries do not repair reputation. ARIN's role is limited: it clears returned or revoked space for reissue, and it publishes a quarterly file, "IPv4 Addresses Cleared for Waiting List". Beyond that, it "delegate[s] reputation remediation to the new registrants and blocklist maintainers." ARIN's guidance addresses both sides:

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

In practice, a newly allocated block from ARIN's waiting list is still not a clean slate. Treat it as suspect until you have checked it.

Abuse in the IPv4 transfer and lease market

Much of the risk concentrates in the secondary market, where IPv4 blocks are bought, sold and leased. ARIN's post about IPxo (Nov 2022) documents the ways the market is abused:

ARIN's abuse statistics for Q3 2022 give the base rate: 1,340 abuse cases, of which 60.65% were related to spam. Copyright infringement and login attacks accounted for 7.42% each. Some ~90% of cases were handled automatically, but spam cases needed manual intervention 46% of the time.

What this means for an ESP acquiring space:

• Leased space gives you less control over reputation than space you own. You do not control the block's future or know its full history, and lease platforms pool many lessees. A bad neighbor, or a previous lessee's activity, stays with the block.
• Verify the chain of custody. ARIN's advice for reducing abuse rests entirely on accurate, current Whois and RDAP records. A block whose registration data is outdated or does not match the seller's identity is a warning sign of hijacking, not just a paperwork problem.
• A block that looks cheap may be cheap because it is dirty. The market discounts blocks with reputation problems.

Sources of reputation history

ARIN WhoWas: historical registration records

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

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

ARIN RDAP: current registration and ownership

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

The output is structured JSON, an improvement on the free text of legacy Whois. RDAP follows IANA bootstrap referrals, so a query sent to one RIR is redirected to the RIR that actually holds the resource. Use RDAP to confirm that the block is registered to the party selling or leasing it, that the abuse and POC contacts are current, that the allocation status matches the deal, and that the registration is not obviously outdated (a sign of hijacking).

RIPEstat: routing history, blocklist and abuse data

The RIPEstat Data API provides global data that you can query from code to vet a block, whichever RIR issued it. The base pattern is:

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

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

Routing History (/data/routing-history/) is the most important call for acquisition checks. It returns "the history of announcements for prefixes, including the origin ASN and the first hop," using data from RIS route collectors. In other words, it shows which autonomous systems (ASNs) announced this block, and when.

The response is organized by announcing ASN. Each entry has a prefix, timelines (announcement periods with start and end) and full_peers_seeing (the RIS collectors that observe the route). Example: https://stat.ripe.net/data/routing-history/data.json?resource=192.0.2.0/24.

How it helps you vet a block: it shows when the prefix changed announcing ASNs, and whether it sat in an ASN that tolerates spam or is prone to hijacking. It shows whether announcements were fragmented or erratic, which is a snowshoe or hijack pattern (see Basic IP Allocation on snowshoeing). It also shows whether the ASN the seller claims matches the actual routing history.

Other RIPEstat data calls that help before an acquisition:

IPv4.Global reputation reporting: a combined check for marketplace blocks

For blocks moving through the secondary market, IPv4.Global (an IPv4 marketplace run by Hilco Streambank) offers a free reputation report to buyers, sellers, lessors and lessees. It is a convenient single check that queries 10 independent blocklist services together with registry, routing and geolocation data:

• Blocklist and 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 and geolocation: MaxMind, IP2Location LITE and RIPEstat.

How access works: buyers request real-time reports on listings, sellers and lessors get reports generated automatically when a listing is created or approved, and active lessees get automated reports twice a week and can generate more on demand. Each report is "a snapshot of the block's history at the time the report was generated", so generate a new report immediately before you commit rather than relying on an old copy.

Treat the report as a fast screen, not a substitute for your own DNSBL and provider reputation checks. The vendor checks a limited set of blocklists, and the set does not include the internal reputation that mailbox providers (Gmail, Microsoft, Yahoo) hold, which no external tool exposes.

Checklist before acquisition

Run these checks before you sign, buy or lease. Any warning sign is grounds to renegotiate the price, ask for a different block, or walk away.

• RDAP lookup: confirm that the current registrant matches the seller or lessor, that the abuse and POC contacts are current, and that the allocation status matches the deal.
• WhoWas report (or the registry section of the IPv4.Global report): count the ownership changes, identify previous holders, and note gaps where the block was revoked or returned.
• RIPEstat Routing History: review the announcing ASNs over time, and flag ASNs that tolerate spam or are prone to hijacking, as well as fragmented announcement patterns.
• Blocklist sweep across zones: query each address, and the CIDR block that covers it, against the major zones. At a minimum, check Spamhaus ZEN (zen.spamhaus.org, which covers SBL, CSS, XBL and PBL in one query; see Blocklists & Spamhaus), Spamhaus DROP/EDROP (netblocks that are hijacked or leased to spammers, which you must never route), UCEPROTECT, SpamCop, Barracuda, and SORBS or other legacy zones as relevant.
• PBL status: check pbl.spamhaus.org. A PBL listing (return code 127.0.0.10 when the ISP designated the range, or 127.0.0.11 when Spamhaus did) means that policy marks the range as not meant to send mail directly to mail exchangers (MX), because it is dynamic, residential or IoT space. If you acquire PBL-listed space for bulk sending, you must get the listing changed and also persuade the registrant to redesignate the range. The listing is an early sign that the block was never meant for a mail server.
• DROP and hijack check: a block on Spamhaus DROP (127.0.0.9 under SBL) is a hard no. It is treated as hijacked or entirely controlled by spammers, and it is dropped at the routing layer, not just filtered.
• Reverse DNS: confirm that you can set matching PTR records for every address. Any outdated or spammy existing rDNS must be replaceable.
• Reputation service snapshot: check Senderscore, Cisco Talos (Good, Neutral or Poor), and the block's history in Google Postmaster Tools if it is available.
• Volume compared with block size: will your intended volume support the minimum 40,000 messages/week per IP without snowshoeing across too many addresses?

Checklist after acquisition

Once the block is yours, and before production sending:

• Set rDNS (PTR records) for every sending IP address, matching HELO or EHLO and pointing to a hostname on a domain you control. Google and Yahoo require this of bulk senders.
• Request delisting of inherited entries. For outdated blocklist entries left by the previous holder, contact each operator directly and state that the block was reissued to you, which is the path ARIN recommends. Refer to ARIN's quarterly "cleared for waiting list" file where it applies.
• PBL delisting. If the block was listed on the PBL, use Spamhaus self-service removal for space where you legitimately run a mail server, or have the network owner redesignate the range.
• Check reputation again once delisting has propagated. DNSBL removals and geo-IP corrections take time. Run the blocklist sweep from the checklist before acquisition again before your first campaign.
• Warm up as if from a deficit, not from neutral. Recycled or transferred space often starts below neutral (see IP Warm-Up: new or unknown IP addresses start slightly negative). Follow the standard warm-up ramp, and send first to your most engaged recipients so that providers build a positive memory over the inherited one.
• Isolate warm-up risk in the pool architecture, so that a block that turns out worse than your checks suggested does not contaminate established IP addresses. See Multi-Tenant Architecture and Advanced IP Segmentation.
• Monitor from day one. Set up seed and inbox-placement testing, and enroll in postmaster tools and SNDS before volume ramps up, so that you detect an inherited reputation problem in the first campaigns rather than the fifth.

Key principle

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

Related articles

• IP Warm-Up, including why recycled space starts below neutral
• Basic IP Allocation
• Advanced IP Segmentation
• Blocklists & Spamhaus
• Spamhaus Listings Deep Dive, with the return codes and delisting workflows
• Spam Traps
• Spam-Trap Incident Response
• Multi-Tenant Architecture, on isolating new IP addresses from established reputation
• Reputation Monitoring