Check IP reputation before buying IPv4

Your next address block should help customers connect from day one. Before you buy IPv4 addresses, check how the block behaves on the networks, security systems and services your customers use. A low purchase price loses its appeal if your team spends the launch fixing blocked traffic or old routing records.

Check reputation before you commit

Start with the exact prefix and your intended workload. Compare current blocklist results with abuse history, BGP announcements, RPKI, IRR, reverse DNS and geolocation. Then test representative addresses against the destinations that matter to your business. Keep the results and the date so you can compare them at handover.

Protect the customer experience you are buying capacity for

A previous operator's spam, compromised servers or proxy activity can leave traces after an address changes hands. Those traces may affect email delivery, API access or customer sign-ins. Finding them early lets you choose a better block, price the repair work or choose a supplier that handles the address operations with you.

Connect each check to a launch decision

Registration tells you which resource you are discussing. Routing checks show how it reaches the Internet. Reputation checks reveal how services treat it. Your deployment test brings those answers together: can this capacity support the service you want to sell?

Test reputation against your workload

Look across spam blocklists, malware and phishing feeds, proxy or VPN classifications, and the security tools used by your customers. Spamhaus and Cisco Talos are useful starting points. Your own connection tests add the context a general reputation score cannot supply. The IP reputation guide explains how these signals fit together.

Turn a blocklist result into an actionable answer

Record which addresses are listed, the reason, when activity was last seen and whether an individual address or the whole prefix is affected. Check the list operator's review process. An old incident with a clear correction path is a different buying decision from active abuse across the block.

Find the history that could delay your launch

Review reports of open proxies, exposed resolvers, compromised hosts, malware and DDoS amplification. Shadowserver provides security reporting that can help operators investigate exposure. Match reports to their observation dates and previous use, then confirm whether the underlying service is still present.

Focus on the services your customers need

Reputation checks by customer workload

Your service	Check first	Customer result
Email	Sending history, blocklists, PTR and authentication	A sound starting point for reliable delivery
Hosting and cloud	Malware history, security feeds and abuse reports	Fewer inherited access problems for new workloads
APIs and SaaS	Destination access, allowlists and location data	Connections that work for the customers you serve
ISP and network services	BGP visibility, RPKI, IRR and operational contacts	Capacity your network can route and support
VPN and security services	Proxy classification, location and destination tests	A clear view of compatibility before rollout

What a clean IPv4 block means for your business

Ask for recent results for the exact prefix and the services you will run. “Clean” becomes useful when it describes current blocklist checks, known history and successful deployment tests. That gives your team a practical basis for selection and a record to compare after launch.

Decide whether historical issues are worth fixing

Compare the affected services, the age of the issue and the available repair path with your launch date. A manageable correction may be worthwhile. If the work will absorb the saving or delay customer revenue, choose different capacity.

Make sure the block will route on your network

Use RIPEstat to examine current and historical BGP announcements. Look at origin ASNs, periods without announcements, more-specific routes and recent changes. Compare them with the supplier's account of how the prefix has been used.

Understand changes in routing history

A new origin ASN can reflect a provider move, a customer's network, multihoming, anycast or DDoS mitigation. Ask what changed and when. Match that explanation to route records so your engineers can prepare the handover with confidence.

Prepare RPKI for your origin ASN

A Route Origin Authorisation (ROA) identifies the ASN allowed to originate a prefix and the permitted prefix length. Check the current ROAs and arrange updates for your intended announcements. The RPKI architecture explains how this authorisation supports route validation.

Read the RPKI result correctly

• Valid: at least one covering ROA permits both the origin ASN and the announced prefix length.
• Invalid: covering ROAs exist, but none permits that announcement. Resolve the ASN or prefix-length mismatch before rollout.
• NotFound / Unknown: there is no covering ROA. Arrange the intended authorisation with the resource operator.

The BGP origin validation reference describes these states. Recheck your planned announcements after any ROA change.

Keep route authorisation and resource control connected

RPKI answers a routing question. For a smooth handover, also identify the team that can update the resource records and authorise your future changes. Your network needs both working announcements and a dependable path to maintain them.

Update IRR records alongside BGP

Review the Internet Routing Registry route objects for the IPv4 prefix, including origin ASN, database and maintainer. Some upstreams use these objects to build filters. Coordinate replacement of stale entries with the party that controls them, then confirm your upstream accepts the intended routes.

Prepare email, DNS and location for real use

For outbound email, review the prefix's sending history and test your new sending setup. Check forward DNS, PTR records, SPF, DKIM and DMARC, together with complaint rates and sending patterns. Google's sender guidance explains the configuration expected for mail sent to Gmail.

Build sending reputation from a strong start

Begin with wanted messages, consistent sending volumes and working authentication. Monitor delivery and recipient feedback as traffic grows. Good address history gives you a useful starting point; the way you operate the new service builds its ongoing reputation.

Get control of reverse DNS before launch

Confirm who can change PTR records, how delegation will be handed over and when you can publish your own names. Replace obsolete records and test forward and reverse lookups. This helps mail systems, logs and support teams recognise your infrastructure correctly.

Check the location your customers will see

Compare the databases and destination services relevant to your users. An address may still be associated with its previous country, operator or VPN use. Submit corrections where needed and test again. The registry region and the place your network routes the address are separate facts.

Give operational reports a responsive destination

Update abuse and technical contacts so reports reach the team now running the service. Agree how the previous operator will forward reports during the transition. A reachable operations team can resolve inherited issues before they become recurring customer problems.

Confirm the resource and the delivery path

Use RDAP or WHOIS to confirm the exact address range, registry, recorded organisation, status and contacts. APNIC's RDAP reference describes the registration data available through standard queries. Match the records to the block in your offer.

Look beyond the name on the record

A registry entry identifies a registered relationship. Your business also needs control of routing, updates and continued use. The guide to IP address rights and control explains why these layers matter when comparing direct holding with a first-party service.

Work with the party that can deliver

Identify who controls the resource and who will carry out the handover. If a representative or a different company name appears, establish the connection early. That avoids spending time negotiating a block with someone who cannot complete the required changes.

Plan the transfer around your launch date

For a purchase, establish the applicable transfer route, fees, eligibility and processing steps with the parties involved. Ask which updates must happen before you can announce the prefix. Bring the registry work and network activation into one delivery schedule.

Price the work needed to reach production

Compare purchase price, transaction fees, registry work, routing preparation, reputation repair and deployment effort. Include the revenue impact of waiting to launch. Our IPv4 negotiation guide turns those findings into a practical commercial comparison.

Make the handover easy for your team

Agree who will update ROAs, IRR records, PTR delegation, contacts and old announcements, and in what order. Give each step an owner and a target date. This turns the purchase into a usable delivery plan for the engineers bringing your services online.

Refresh the checks before completion

Repeat the important reputation, registry and routing checks just before the handover. Compare them with your first results and resolve changes while the supplier is still preparing delivery. A current picture helps you avoid inheriting a problem that appeared after the initial review.

Verify the result on your own network

After handover, confirm the expected origin ASN, ROAs, IRR records, DNS and contacts. Test representative services from outside your network and monitor reachability as you introduce traffic. Track any location corrections and reputation reviews through to their observed result.

Keep reputation healthy as you grow

Continue monitoring abuse reports, security exposure and destination access after launch. Secure customer workloads and respond quickly to incidents. Reputation reflects ongoing use, so good operations protect the value of your address capacity.

Your buying checklist

From purchase review to customer-ready capacity

Decision	Evidence to collect	Next step
Will services work?	Current reputation results and workload tests	Choose suitable capacity or price the remediation
Can we route it?	BGP history, ROAs, IRR and upstream requirements	Coordinate the intended ASN and route changes
Can we launch on time?	Transfer path, DNS control and delivery owners	Align the handover with your service launch
Is this the best use of capital?	Full acquisition and operating cost	Compare direct LARUS capacity and Continuity

Get capacity with continuity built around it

You need addresses that keep your customers connected as your business grows. LARUS brings first-party IPv4 supply, routing operations, renewal and Continuity together, so your team has a direct operator to work with throughout the service.

Buying a block leaves the registry relationship with the holder. With LARUS, that interface sits upstream with a specialist operator. Lu Heng's Note 35 explains the structure behind this approach. Unlimited IPv4 gives you a growth path without tying your next expansion to another block purchase.

Put your next investment into customer growth

Use your reputation review to choose capacity your network can put to work. Compare the full purchase and operating burden with LARUS Continuity, then choose the plan that supports your next launch. If acquisition is part of your strategy, the IPv4 buying guide explains that route too.

Questions before buying IPv4 addresses

How do I check IP reputation before buying?

Check the exact prefix across relevant blocklists and security feeds, review its routing and abuse history, then test your intended services. Record current results so you can repeat the checks at handover and after deployment.

Should I reject a block with an old listing?

Look at the cause, date, affected addresses and repair path. Judge it against your workload and launch schedule. Choose another block when fixing the issue would cost more time or money than the saving is worth.

Does RPKI Valid mean the address has good reputation?

It means the announcement matches a route authorisation. Reputation services assess other signals, including abuse and sending behaviour. Check both to understand how your routes and customer traffic will be treated.

Does a change of origin ASN mean the block was hijacked?

Provider changes, customer routing and DDoS mitigation can all change the origin. Compare the dates with the operator's explanation and routing records to establish what happened.

Can reputation improve after a transfer?

Yes. Changed use, corrected records and resolved abuse can improve the signals services observe. Follow up with the affected database operators and test the actual destinations your customers use.

Does reputation matter outside email?

Yes. Firewalls, fraud systems and API platforms may assess address history or location. Make those destination checks part of the review for hosting, cloud, ISP and application workloads.