Reading a Multi-Database IP Report: What Wins When They Disagree

What the report contains

A widely used open-source script — xykt/IPQuality, run as a single command — queries AbuseIPDB, Cloudflare, DB-IP, IP2Location, ipapi, IPinfo, IPQS, ipregistry and Scamalytics, then prints the results as one table. It also checks several hundred blocklists, mail-provider connectivity and outbound port 25.

Its real value is not saving you nine lookups. It is that putting nine verdicts next to each other makes their disagreements visible, which no single lookup can do.

Read it in this order

1. Allocation facts first — ASN and organisation. These come from the routing table and registries, they are the least interpreted thing in the report, and they answer the question that actually matters: which network handed this address out.
2. Classification second — the consumer / business / hosting row across databases. This is inference, so read it as a vote count rather than a fact, and note who dissents.
3. Risk scores last. They are the most processed, the most vendor-specific, and the most likely to disagree.
4. Blocklists as a separate question. A listing is a concrete, attributable event, unlike a composite score.

Most people read this report bottom-up, starting at the scary red number. Reading it top-down usually resolves the confusion in one step.

What disagreement actually looks like

A pattern that shows up constantly in reports people publish: four databases classify an address as consumer broadband while one calls it hosting; separately, five risk scores come back at zero while one returns a double-digit number.

Neither is a malfunction. Vendors build their classifications from different inputs and update on different cycles, and a fraud score is tuned for a decision that may have nothing to do with your use case.

The practical rule: a lone dissenter among consistent peers is usually the outlier, not the revelation. What deserves attention is the opposite — consistent agreement that an address is hosting when the seller told you it was not.

Three sections that get misread

• Usage type vs company type. These are different rows answering different questions — how the address is used, and what kind of entity holds it. An address can legitimately show consumer usage under a business account holder. Comparing the two rows across databases resolves more confusion than any single cell.
• Geolocation. It is inferred, and each vendor infers differently, so the same address drifting between cities or states across databases is ordinary. It is a well-known frustration and it is rarely a defect in the address itself.
• Service reachability. The report checks whether particular services respond normally. That measures each service's own regional policy at that moment, not the quality of your address — and it is not something we treat as a quality metric or make promises about.

How we use it at delivery

We run this report when we vet our own blocks, and you can ask for the output with your delivery. We prefer it to a set of screenshots from individual vendors for one reason: you can run exactly the same command yourself, at any time, and see whether the picture still holds.

What we state as fact stays the same regardless of what any score says on a given day: which access network the address came from, its ASN, its registration shape, that a statically configured address survives a reinstall, and that one customer uses it.