# IP Space Acquisition Due Diligence

> How an ESP vets IP address space before sending on it — prior-use and reputation history via ARIN WhoWas/RDAP and RIPEstat, why recycled IPs inherit blocklist history, the IPv4 transfer/lease-market abuse problem, and pre/post-acquisition checklists.

Source: emailmarketing.net — https://emailmarketing.net/learn/esp-operations/ip-acquisition-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](https://emailmarketing.net/learn/ip-management/ip-warm-up) covers what to do next, and [Basic IP Allocation](https://emailmarketing.net/learn/ip-management/basic-ip-allocation) covers how many IP addresses to run. For how the blocklists you check against work, see [Blocklists & Spamhaus](https://emailmarketing.net/learn/reference/blocklists-and-spamhaus) and the [Spamhaus Listings Deep Dive](https://emailmarketing.net/learn/reference/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](https://emailmarketing.net/learn/reference/spam-traps).** Recycled addresses may have sent to traps under their previous owner. [Spam-Trap Incident Response](https://emailmarketing.net/learn/esp-operations/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:

| Abuse vector | Description |
|---|---|
| **Blacklisting after transfer** | Research shows that IP addresses are **4 to 25 times more likely to be blacklisted after a transfer** than before. The market itself is associated with reputation damage. |
| **Black-market hijacking** | Malicious actors have hijacked hundreds of thousands of IP addresses assigned by Regional Internet Registries (RIRs) and resold them to criminals. |
| **Exploitation of legacy space** | Outdated or dormant registration records leave legacy blocks open to hijacking for spam, phishing and malware. |
| **Legal acquisition, illegal use** | Criminals obtain IP addresses legitimately through transfer markets and waiting lists, then misuse them. The acquisition is clean, but the use is not. |

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.

| Attribute | Detail |
|---|---|
| **What it returns** | Full historical registration records for the resource, with the associated organization and point-of-contact (POC) handles |
| **Delivery format** | A `.zip` file 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 link to a POC or Org ID is needed) and a one-time authorization request |
| **Review** | ARIN staff review the request within **two business days**. You must agree to the WhoWas Terms of Use and state your intended use, how often you expect to query, and whether the data supports advertising, marketing or marketing research |
| **Restrictions** | Not for high-volume querying. Excessive querying can end your access |
| **Compared with Whois and RDAP** | Whois and RDAP show the 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 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:

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

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**.

| Parameter | Purpose |
|---|---|
| `resource` | The prefix, IP address or ASN to investigate (required) |
| `starttime` / `endtime` | The query window (ISO-8601 or Unix time) |
| `min_peers` | Filters out announcements with low visibility (default 10) |
| `normalise_visibility` | Adds peer-visibility percentages |
| `include_first_hop` | Includes the first-hop ASN |
| `max_rows` | Caps the results (soft cap 3,000) |

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](https://emailmarketing.net/learn/ip-management/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:

| Data call | Use |
|---|---|
| **DNS Blocklists** | Whether and when the resource appeared on tracked DNSBLs |
| **Abuse Contact Finder** | The current contact for reporting abuse of the resource |
| **Allocation History** and **Historical Whois** | Changes of ownership over time on the registry side (compare with WhoWas) |
| **Transfer History** | Recorded ownership transfers |
| **Routing Status** and **BGP Updates** | The current announcement state and recent routing changes |
| **Address Space Usage** and **Address Space Hierarchy** | Allocation patterns and parent and child relationships |

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

For blocks moving through the secondary market, [IPv4.Global](https://www.ipv4.global/reputation-reporting/) (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](https://emailmarketing.net/learn/reference/blocklists-and-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](https://emailmarketing.net/learn/reference/spamhaus-listings-deep-dive) 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](https://emailmarketing.net/learn/ip-management/basic-ip-allocation) 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](https://emailmarketing.net/learn/ip-management/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](https://emailmarketing.net/learn/esp-operations/multi-tenant-architecture) and [Advanced IP Segmentation](https://emailmarketing.net/learn/ip-management/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](https://emailmarketing.net/learn/ip-management/ip-warm-up), including why recycled space starts below neutral
- [Basic IP Allocation](https://emailmarketing.net/learn/ip-management/basic-ip-allocation)
- [Advanced IP Segmentation](https://emailmarketing.net/learn/ip-management/advanced-ip-segmentation)
- [Blocklists & Spamhaus](https://emailmarketing.net/learn/reference/blocklists-and-spamhaus)
- [Spamhaus Listings Deep Dive](https://emailmarketing.net/learn/reference/spamhaus-listings-deep-dive), with the return codes and delisting workflows
- [Spam Traps](https://emailmarketing.net/learn/reference/spam-traps)
- [Spam-Trap Incident Response](https://emailmarketing.net/learn/esp-operations/spam-trap-incident-response)
- [Multi-Tenant Architecture](https://emailmarketing.net/learn/esp-operations/multi-tenant-architecture), on isolating new IP addresses from established reputation
- [Reputation Monitoring](https://emailmarketing.net/learn/operations/reputation-monitoring)