Technical guide
Is Your Leased IP Clean?
Bring new addresses online with confidence. Check reputation, routing and your real customer services before you launch.
Choose my IPv4 planStart with the services your customers use
A new IPv4 range should help you connect more customers, launch services and grow. Before putting it into production, check the address you will actually use, its reputation, the route to your network and your application's response. That gives you a practical answer to “is this IP safe?” and a clear next step if something needs attention.
Your checks at a glance
- Confirm the exact public addresses and who will support their delivery.
- Check relevant blocklists and read the reason behind any result.
- Verify routing, reverse DNS and the services your customers depend on.
- Resolve any issue before moving more traffic, then keep watching the signals that matter.
What does a clean IP address mean for your business?
For a hosting provider, it may mean customers can reach websites and APIs without unexpected blocks. For a mail operator, it means addressing reputation and sending configuration together. A clean result on one tool is a useful starting point; a successful test of your real service gives you the confidence to launch.
Reputation reflects an address's history and current use. A previous tenant's activity may still appear in a tool, while a timeout may simply mean the lookup failed. Treat each result as information about what to check next.
What is a leased IP address?
With commercial IPv4 leasing, your business obtains address capacity from a provider to use for its services. This is different from a DHCP lease that assigns an address to an individual device. Confirm the prefix, the intended network and the routing arrangement so your team knows exactly what it is bringing online.
Start with the source address shown in your service's logs or a receiving system's connection record. A browser IP lookup shows that browser's public exit address, which may be a VPN, proxy or NAT gateway rather than the server you are investigating.
Check early so customers get a smoother launch
Finding a stale DNS record or an old listing before deployment saves your team from troubleshooting it during a customer launch. Give priority to the destinations your customers actually use: their mail providers, business applications, API endpoints and access networks.
Separate the symptoms. A mail rejection naming a blocklist points to a different investigation from an unreachable route, an incorrect location label or a failed application login. This keeps the work focused on restoring the customer's connection.
How to check whether your leased IPv4 is clean
1. Look up the right address
Record the exact IPv4 address, the affected service and the time of the test. If you are preparing a whole prefix, identify the addresses you will deploy and check those workloads. One successful lookup does not describe every address in a range.
2. Check reputation at the source
Use the Spamhaus reputation checker for its datasets. A multi-list tool such as MXToolbox helps you discover other records to investigate. Open the relevant list operator's result to see its explanation and recovery route.
DNSBL means Domain Name System Blocklist. Different lists describe different things: spam activity, compromised systems or addresses not intended to send mail directly. A policy listing is not the same as evidence that your server was hacked. Our IPv4 blacklist guide explains how to interpret the response.
3. Check routing and DNS
Compare the announced prefix and origin ASN with your planned deployment. Review the relevant RPKI ROA and IRR route records with the team handling the announcement. Test reachability from the networks that matter to your customers.
For mail, check the sending hostname and its forward and reverse DNS. Review authentication and delivery feedback too. Google's email sender guidelines explain the Gmail-side requirements; the receiving service's own feedback is the best place to investigate a rejection.
4. Run a small service test
Test API requests, website connections or mail delivery using systems and test accounts you operate. Check the response, logs and source address. This joins the reputation report to the experience you want to deliver.
| What you find | What it tells you | Your next step |
|---|---|---|
| No listing found | The checked dataset has no matching listing. | Continue with routing, DNS and your real service test. |
| A named listing | That operator has a record to investigate. | Read the reason and compare it with your service logs. |
| Timeout or lookup error | The check did not give you a usable answer. | Retry through the operator's supported lookup method. |
| Only one destination fails | The problem may be specific to that service or path. | Use its error message and support route to narrow the cause. |
What to do if your leased IP is blacklisted
Start with the customer's failed connection or rejected message. Keep the address, timestamp, exact error and listing URL together. Share that evidence with your provider so the right team can act without repeating the investigation.
If the listing describes current activity from your systems, fix that cause first: for example, a compromised account, an open mail relay or an exposed application. Then use the list operator's removal process and retest the affected service. A listing left by a previous user needs the same clear evidence about who is operating the address now.
Discuss the recovery path with your provider, including whether an address change would help. Changing the IP also affects DNS, customer allowlists and integrations, so plan the transition around the service you need to keep running.
Keep the address useful as your network grows
- Watch delivery errors, unusual outbound traffic and the lists relevant to your services.
- Keep exposed software patched and protect administration and sending accounts with strong authentication.
- Send messages people expect, handle bounces and make it easy to stop unwanted mail.
- Keep route, DNS and operational contact details aligned with the network you actually run.
Your provider relationship matters after the first lookup. With LARUS, you work directly with the IPv4 provider for supply and Continuity, while your team keeps control of its network. Build with Unlimited IPv4 and put expansion on a dependable supply foundation.
Leased IP checks: common questions
How do I check if my leased IP address is clean?
Identify the actual public address, check the reputation sources relevant to your use, verify routing and DNS, then test your service. A multi-list report helps you find issues; the relevant operator's result helps you understand them.
Does a flagged IP mean my server is compromised?
Read the reason before deciding. The record may describe current abuse, previous use or a sending policy. Compare its timing and scope with your own logs to find the right fix.
Can a clean IP still have email delivery problems?
Yes. Check the receiver's response, sending domain, authentication, DNS and sending pattern alongside IP reputation. This gives you a much more useful recovery path than repeating a blocklist lookup alone.
Should I request a replacement IP?
Bring the affected service and the lookup result to your provider. Decide whether remediation or a planned change will restore customer service sooner, and update the dependent routes, DNS and allowlists together.
Where do I start with a new IPv4 range?
Choose your LARUS IPv4 plan around the network you are building. The same checks help your team prepare the deployment, while direct supply and Continuity support the services you want to keep growing.
IPv4 for your next move
Launch your next service with confidence.
Build on Unlimited IPv4 and direct LARUS support. Choose the plan that keeps your customer connections and next expansion moving.
