How to check reputation before you buy IP addresses

Buying IPv4 address space involves more than finding an available block at an acceptable price.

A prefix can carry years of operational history. It may have been used for email, hosting, proxies, VPN services, customer infrastructure or workloads that generated abuse complaints.

It may also have historical BGP announcements, existing RPKI objects, old IRR records, reverse DNS configurations and third-party reputation data that continue to affect how the addresses behave after a transaction.

That is why IPv4 due diligence should examine more than one signal.

A good IPv4 purchase review should separate registry state, seller authority, routing history, routing authorisation, reputation and operational readiness.

None of these layers alone tells the complete story.

A clean registry record does not guarantee clean reputation. A valid BGP route does not prove legal ownership. A blocklist entry does not necessarily mean a prefix can never be used again. And a valid RPKI Route Origin Authorisation does not replace transaction due diligence.

How to Check IP Reputation Before Buying: Quick Answer

Before buying IPv4 addresses, review at least the following:

1. current RDAP or Whois registration data;
2. the seller's authority to complete the transaction;
3. applicable RIR transfer requirements;
4. historical and current BGP announcements;
5. RPKI Route Origin Authorisations;
6. IRR route objects;
7. spam, malware and abuse reputation;
8. reverse DNS and email-related history;
9. geolocation data where relevant;
10. abuse contacts and historical operational exposure; and
11. the work required after transfer to make the block production-ready.

These checks should be considered together.

IP reputation is not a single score. It is a collection of signals created by different networks, security systems, mail providers and historical uses.

Why IP Reputation Matters When You Buy IPv4 Addresses

IPv4 scarcity has created an active secondary market in which address blocks can move between organisations.

But operational history does not automatically disappear when registry state changes.

A newly acquired block may still be associated with:

• spam complaints;
• malware activity;
• open proxies;
• botnet traffic;
• DDoS infrastructure;
• hosting abuse;
• historical email campaigns;
• outdated geolocation data;
• old PTR records;
• stale IRR objects; or
• historical BGP origin ASNs.

Some of these issues are easy to correct.

Others may require time, evidence of changed use, third-party database updates or reputation rebuilding.

The objective is therefore not simply to classify a prefix as either “clean” or “bad.”

The objective is to understand:

what happened before, what remains visible today, what can be changed, and whether the block is suitable for the buyer's intended use.

Separate IPv4 Transaction Due Diligence Into Four Layers

Before analysing reputation, it helps to distinguish four different layers surrounding an IPv4 resource:

legal and commercial rights → registry state → routing authorisation → operational use

A reliable purchase review should examine all four.

1. Check RDAP and Registry Records

RDAP is one of the first places to begin an IPv4 due-diligence review.

The Registration Data Access Protocol provides structured access to Internet resource registration information.

Depending on the registry and resource, the data can help identify:

• the address range;
• the relevant registry;
• the organisation associated with the resource record;
• resource status;
• relevant contacts; and
• other registration information.

APNIC describes RDAP as an alternative to Whois for accessing Internet resource registration data, with standardised queries and responses and referral capabilities.

See: APNIC – Registration Data Access Protocol .

RDAP Is a Registration Check, Not a Universal Ownership Test

RDAP should not be described simply as a tool for “checking who owns an IP address.”

It shows registry information.

Registry state is extremely important for a transaction, but it is not necessarily identical to the complete legal or commercial relationship surrounding the resource.

For example, a transaction may involve:

• an authorised representative;
• a broker;
• a corporate parent or subsidiary;
• a merger or acquisition;
• a legal-name change;
• corporate succession; or
• another documented arrangement.

Therefore, if the seller's commercial identity does not exactly match the organisation displayed in an RDAP record, that difference should trigger further verification rather than an automatic conclusion that the transaction is fraudulent.

RDAP tells you what the registry record says. Transaction due diligence determines whether the seller has appropriate authority to complete the transaction.

For more on this distinction, read Who Owns IP Addresses? Understanding Rights, Registry Records and Network Control .

2. Verify the Seller's Authority

The buyer should establish who has authority to enter into the transaction.

Depending on the circumstances, useful evidence may include:

• registry account information;
• corporate records;
• authorised-signatory information;
• board or management approval where appropriate;
• merger or acquisition documents;
• corporate succession records;
• power of attorney or agency documentation;
• historical transfer documentation; and
• other evidence relevant to the resource and transaction.

The exact documentation required depends on the transaction and the applicable registry process.

The important point is not to treat any single database field as a substitute for transaction authority.

3. Check Applicable RIR Transfer Requirements

IPv4 transfer requirements differ between Regional Internet Registries and can change over time.

Before signing or closing a transaction, determine:

• which registry or registries are involved;
• whether the block is eligible for the proposed transfer;
• what documentation is required;
• whether source or recipient eligibility requirements apply;
• whether an inter-RIR transfer path is available where relevant;
• whether a transfer restriction or holding period applies;
• whether organisational changes must first be reflected in registry records; and
• what steps must be completed before the registry update is final.

Transfer rules should be checked directly with the relevant registry rather than assumed from a previous transaction.

Commercial agreement and registry transfer are related, but they are not the same event.

commercial transaction → registry transfer → routing and security updates → operational deployment

4. Review Historical BGP Announcements

After reviewing the registry and transaction layer, examine how the prefix has appeared in BGP.

Historical routing data can help identify:

• previous origin ASNs;
• long periods of inactivity;
• recent origin changes;
• more-specific announcements;
• multi-origin behaviour;
• short-lived announcements; and
• changes that require further explanation.

Tools such as RIPEstat can help examine routing history and other network data.

An Unusual BGP History Does Not Automatically Mean Hijacking

Routing history requires context.

A different origin ASN may be caused by:

• a legitimate provider change;
• multihoming;
• network migration;
• DDoS mitigation;
• traffic engineering;
• anycast;
• a customer's ASN;
• corporate restructuring; or
• a temporary operational arrangement.

Therefore, an unexpected announcement is a reason to investigate. It is not by itself proof of hijacking.

Buyers should compare routing history with:

• registry history;
• RPKI;
• IRR information;
• known corporate history;
• transaction documentation; and
• explanations from the relevant parties.

5. Check RPKI Route Origin Authorisations

RPKI is an important part of IPv4 routing due diligence, but its purpose should be described accurately.

A Route Origin Authorisation, or ROA, specifies which Autonomous System is authorised to originate routes for a prefix.

The RPKI architecture defined in RFC 6480 describes ROAs as explicit route-origin authorisations.

Buyers should check:

• whether a covering ROA exists;
• which ASN is authorised;
• the authorised prefix length;
• whether current BGP announcements are Valid, Invalid or NotFound/Unknown;
• who can update the ROA after the transaction; and
• when any old ROA should be changed or removed.

RPKI Does Not Prove Legal Ownership

RPKI should not be treated as a property-title system.

Its primary operational purpose is routing security.

RPKI helps answer: “Is this origin ASN authorised by the relevant RPKI state to originate this prefix?”

It does not by itself answer:

“Who legally owns every right associated with this IPv4 resource?”

Those are different questions.

Understand Valid, Invalid and NotFound RPKI States

RPKI status also needs to be interpreted correctly.

RIPE NCC documentation distinguishes these validation states and explains that networks can use them as inputs to their own routing decisions.

See: RIPE NCC – BGP Origin Validation .

6. Review IRR Route Objects

Internet Routing Registry data can also be relevant when evaluating an IPv4 block.

Route and route6 objects can describe relationships between prefixes and origin ASNs, and some networks use IRR data to build routing filters.

Before buying, review:

• existing route objects;
• the origin ASN shown in those objects;
• the relevant IRR database;
• maintainer information where applicable;
• whether stale objects exist;
• whether the buyer or relevant provider can create the required new objects; and
• how old objects will be corrected or removed.

IRR records are useful operational information.

But, like BGP and RPKI, they should not be treated as standalone proof of legal ownership.

7. Check IP Reputation Across Multiple Sources

Reputation is not maintained by one central Internet authority.

Different organisations maintain different datasets for different purposes.

A buyer may therefore want to review several categories of reputation data:

• spam blocklists;
• malware reputation feeds;
• phishing or fraud datasets;
• proxy or VPN classifications;
• hosting classifications;
• email-provider reputation;
• threat-intelligence systems;
• geolocation databases; and
• historical abuse reports.

Services such as Spamhaus and Cisco Talos can provide useful signals, but no single reputation provider should be treated as the complete definition of whether a prefix is usable.

A Blocklist Entry Is a Signal, Not a Permanent Verdict

If addresses appear on a blocklist, investigate why.

Important questions include:

• Which addresses are listed?
• Is the entire prefix affected or only individual IPs?
• What type of activity triggered the listing?
• When was the activity observed?
• Is the activity still occurring?
• What is the delisting process?
• Can the buyer demonstrate a change of operational control?
• Does the listing matter for the buyer's intended workload?

A historical listing may be significant, but it does not mean that an address block can never recover.

Likewise, an address that is absent from a public blocklist is not guaranteed to have perfect reputation across every private security system.

Reputation should be evaluated by use case, evidence and remediation cost rather than by a single binary label.

For more background, read Understanding IP Address Reputation .

8. Review Abuse and Security Exposure History

Historical security exposure can provide additional context.

Useful indicators may include evidence of:

• open resolvers;
• open proxies;
• known malware infrastructure;
• DDoS amplification services;
• compromised servers;
• phishing infrastructure; or
• other exposed services.

The Shadowserver Foundation and other security-data providers can be useful sources for understanding historical exposure.

But scan history also needs context.

A service visible months ago may no longer exist. A historical finding may belong to a previous operator. And some legitimate network services can look unusual without being abusive.

The purpose of the check is to identify what needs investigation, not to assume every historical observation represents current misuse.

9. Evaluate Email Reputation Separately

If the IPv4 block will be used for outbound email, email-specific due diligence becomes particularly important.

Email reputation can depend on:

• historical complaint rates;
• spam history;
• previous sending behaviour;
• PTR records;
• forward DNS;
• SPF;
• DKIM;
• DMARC;
• sending volume;
• recipient engagement; and
• the policies of individual receiving networks.

Google currently requires valid forward and reverse DNS for mail-sending infrastructure and sets additional authentication requirements for senders to personal Gmail accounts.

See: Google – Email Sender Guidelines .

Buyers intending to send email should therefore review both the historical reputation of the addresses and the configuration required for the new sending environment.

Buying a “Clean” IP Block Does Not Guarantee Email Deliverability

Email deliverability is not transferred automatically with the IPv4 block.

Even a prefix with no obvious negative history may need to establish a new sending reputation.

A buyer should not assume that:

• no blocklist entry means guaranteed inbox placement;
• old positive reputation automatically transfers to a new sender;
• correct PTR records alone guarantee deliverability; or
• an IPv4 purchase removes the need for SPF, DKIM, DMARC and responsible sending behaviour.

IP reputation is only one component of modern mail-delivery decisions.

10. Check Reverse DNS Before Deployment

Reverse DNS can matter for email, network services, logging and security systems.

Before completing the transaction, determine:

• who currently controls reverse DNS;
• whether old PTR records exist;
• how the delegation will change after transfer;
• when the buyer can create new PTR records; and
• whether the intended registry or provider structure supports the required configuration.

Reverse DNS should be treated as part of the operational handover, not as an afterthought once the block has already entered production.

11. Check Geolocation Data

IP geolocation databases do not all contain identical information.

A newly acquired prefix may still be associated with:

• a previous country;
• a previous network operator;
• a previous hosting location;
• a proxy or VPN classification; or
• other historical information.

This can affect services that use IP-based geolocation for content, security, licensing or fraud decisions.

Buyers with geolocation-sensitive workloads should identify relevant database providers before deployment and understand their correction procedures.

Geolocation data should not be confused with registry region.

The RIR associated with a resource describes an administrative coordination relationship; it does not by itself determine where the prefix is operationally routed.

12. Verify Abuse Contacts and Operational Contactability

Accurate abuse and operational contacts help ensure that incidents can be reported and handled efficiently.

Before deployment, verify:

• which abuse contact is currently published;
• whether it belongs to the previous operator;
• when it will change;
• who will respond after the transfer;
• which registry or database records require updating; and
• how reports received during the transition will be handled.

Contactability is especially important during the period immediately after a transfer, when historical complaints may still arrive.

13. Assess Reputation Based on the Intended Use

Not every reputation problem matters equally to every buyer.

A prefix can therefore be suitable for one workload while requiring additional remediation for another.

14. Do Not Treat IP Reputation as Permanent

IP reputation changes.

It is created by:

• historical behaviour;
• current traffic;
• security observations;
• complaint rates;
• database updates;
• routing changes;
• network classification; and
• the buyer's own future operation.

This means both positive and negative assessments can change after acquisition.

A buyer with good operational practices can improve many reputation signals.

A buyer with poor security or abuse management can damage a previously clean block.

Reputation is an operational state that needs to be maintained, not a permanent characteristic of the IP address itself.

15. Estimate Remediation Cost Before You Buy

A block with historical issues is not necessarily a bad purchase if the buyer understands the remediation work and prices it appropriately.

Before closing, estimate the effort required to:

• request blocklist review or delisting;
• correct geolocation databases;
• update RDAP or Whois records;
• create or update ROAs;
• replace stale IRR objects;
• configure reverse DNS;
• update abuse contacts;
• build new email reputation where applicable;
• monitor BGP after deployment; and
• respond to historical abuse reports.

The effective acquisition cost is therefore:

purchase price + transaction cost + registry work + routing preparation + reputation remediation + deployment cost

16. Put Critical Handover Requirements in the Transaction Agreement

Technical due diligence should connect directly to transaction execution.

Depending on the deal, the agreement may need to address:

• the exact prefix being transferred;
• seller authority;
• required registry cooperation;
• conditions related to registry approval;
• disclosure of known disputes;
• known material abuse or reputation issues;
• RPKI changes;
• IRR updates;
• reverse DNS transition;
• removal of old operational configurations;
• timing of routing changes; and
• post-transfer cooperation where needed.

The appropriate contractual terms depend on the transaction, jurisdiction and parties involved.

Buyers should obtain appropriate professional advice where legal classification or contractual risk is material.

17. Recheck the Prefix Immediately Before Closing

Reputation and routing state can change between initial due diligence and transaction completion.

A buyer should therefore consider a final pre-closing review of:

• RDAP or Whois information;
• transfer status;
• BGP origin;
• RPKI state;
• IRR objects;
• major blocklists;
• recent abuse observations; and
• any new disputes or unexpected administrative changes.

This reduces the risk of relying on due-diligence results that were accurate weeks earlier but are no longer current.

18. Repeat the Checks After the IPv4 Transfer

Due diligence does not end when the registry transfer completes.

After acquisition, verify that the operational state matches the intended new relationship.

Confirm:

• registry information is correct;
• relevant organisation and contact data is current;
• ROAs match the intended origin ASN;
• IRR objects are correct;
• reverse DNS works as intended;
• BGP announcements have the expected origin;
• geolocation correction requests are progressing where needed;
• abuse contacts are operational; and
• reputation is monitored during initial production use.

A successful registry transfer is an important milestone. It is not the end of operational deployment.

IPv4 Buyer Due-Diligence Checklist

What Does a “Clean IPv4 Block” Really Mean?

There is no universal certification called a “clean IPv4 block.”

The phrase normally means that due diligence has not identified material reputation or operational problems for the intended use.

A stronger description is:

an IPv4 block whose registry, routing, reputation and operational conditions have been reviewed and are suitable for the intended deployment.

This avoids implying that any provider can guarantee how every third-party reputation system will treat an address forever.

Should You Reject Every IPv4 Block With Historical Problems?

Not necessarily.

The decision should depend on:

• the severity of the history;
• how recent it is;
• whether the problematic activity has stopped;
• which reputation systems are affected;
• the buyer's intended workload;
• the cost and time of remediation;
• the availability of alternative blocks; and
• the purchase price.

A block with manageable historical issues may still be commercially attractive.

A block with extensive unresolved operational problems may not be.

The correct decision comes from due diligence, not from treating all reputation signals as permanent.

How LARUS Approaches IPv4 Transaction Readiness

LARUS approaches IPv4 infrastructure by separating transaction, registry, routing and operational questions.

For a buyer, this means understanding more than whether address space is available.

The resource should also be evaluated for:

• registry readiness;
• transaction documentation;
• routing history;
• RPKI and IRR state;
• reverse DNS requirements;
• reputation;
• geolocation;
• abuse history; and
• post-transfer operational requirements.

Buying an IPv4 block is therefore not simply an asset-selection exercise.

The objective is to acquire address capacity that can be transferred, routed and operated with clearly understood dependencies.

Organisations evaluating an IPv4 acquisition can review Buy IPv4 Address Space Through LARUS and i.LEASE .

Frequently Asked Questions

How do I check the reputation of an IP address before buying it?

Review several sources rather than one score. Check public blocklists, threat-intelligence data, abuse history, routing history, reverse DNS, geolocation and any reputation systems relevant to the intended workload.

Does RDAP show who owns an IP address?

RDAP provides Internet resource registration information. It can show the organisation and other information associated with a resource record, but registry data should not automatically be treated as a universal legal property record.

What if the seller name does not exactly match the RDAP record?

Investigate the difference. It may indicate a problem, but it may also have a legitimate explanation involving an authorised representative, corporate structure, merger, name change or other documented relationship. The seller should be able to demonstrate appropriate authority.

Can BGP history prove an IP block was hijacked?

BGP history can reveal unusual announcements that deserve investigation, but origin changes alone do not prove hijacking. Legitimate migrations, multihoming, DDoS mitigation, customer announcements and other network changes can produce similar patterns.

Does RPKI prove ownership of an IPv4 block?

No. RPKI provides cryptographically verifiable information relevant to route-origin authorisation. It should not be treated as universal proof of legal property ownership.

Is an RPKI Invalid route a warning sign?

Yes, an Invalid state should be investigated because the announcement conflicts with applicable ROA information. It may result from a routing configuration error, an outdated ROA or an unauthorised announcement. The cause should be understood before deployment.

Is a prefix unsafe if it has no ROA?

Not necessarily. A route without a covering ROA is generally classified as NotFound or Unknown, which is different from Invalid. Buyers should determine whether an appropriate ROA can and should be created for the intended routing arrangement.

Does a blocklist entry mean I should not buy the IPv4 block?

Not automatically. Determine what caused the listing, whether the activity is current, how important that list is to your intended use, and what remediation is available.

Can IP reputation improve after a transfer?

Yes, many reputation signals can change as operational use changes. However, improvement may take time, and different reputation providers update their data independently.

Can a previously clean IPv4 block develop bad reputation?

Yes. Poor security, abuse, spam or other harmful activity can damage the reputation of previously clean address space. Reputation therefore requires ongoing operational management.

Is IP reputation important if I am not sending email?

Yes. Security systems, firewalls, fraud platforms, hosting providers, geolocation systems and other services can use IP reputation independently of email.

Should I check reputation before or after the IPv4 transfer?

Both. Conduct due diligence before committing to the transaction, recheck important signals before closing, and verify registry, routing and reputation state again after the transfer and before full production deployment.

What is the most important thing to check before buying IPv4?

There is no single universal check. A strong review combines seller authority, registry and transfer status, routing information, RPKI and IRR, reputation, reverse DNS, abuse history and the buyer's intended operational use.

Conclusion

Checking IPv4 reputation before purchase requires more than entering an address into a blocklist search.

A production-ready review should examine several different layers:

legal and commercial rights + registry state + routing authorisation + operational reputation

RDAP helps identify registration state, but it is not a universal property-title system.

BGP history helps identify routing patterns, but unusual announcements require context before they are labelled hijacks.

RPKI helps validate route-origin authorisation, but it does not settle every legal ownership question.

Blocklists and reputation feeds provide important operational signals, but those signals are dynamic and should be evaluated against the buyer's intended use.

The strongest IPv4 purchase process therefore asks not only:

“Is this block available?”

but also:

“Can we verify the transaction, complete the registry process, establish the intended routing state and deploy the addresses without unexpected reputation or continuity problems?”

That is the difference between acquiring IPv4 inventory and acquiring IPv4 capacity that is ready for real infrastructure.

If your organisation is evaluating an IPv4 purchase, visit Buy IPv4 Address Space Through LARUS and i.LEASE .

For more detail on reputation signals, read Understanding IP Address Reputation .

For a deeper explanation of ownership, registry state and network control, read Who Owns IP Addresses? .