Diagnose the listing before you request removal.

Which listing should I inspect before seeking removal?

Distinguish an exact-address record from surrounding-prefix context, check its source and date, then follow that operator’s current procedure. IPJury neither scans every blocklist nor decides whether a removal request will succeed.

Source availability depends on the current deployment and each returned record. These review dates do not establish when a particular IP was observed. Method axis-scope-2026-09-15 · Score ipjury-score-v3.

You found your address on a blocklist and the instinct is to file removal requests everywhere at once. First identify the named source, the scope and the date, rather than treating every listing as the same problem.

Three kinds of listing, three different situations

Exact-address direct record

An operator observed something from this specific address and recorded it. The scope is this address, not an identified person. Inspect the operator’s current record and procedure before deciding what action is appropriate.

Network or prefix-level listing

The listing covers a range, an allocation, or an announcing network. A containing range is not an exact-address record. Ask the provider about the scope and consult the listing operator’s procedure; this tool cannot predict whether an individual request will succeed.

Historical or community report

A report filed by another operator or a volunteer, often about an event weeks or months old, sometimes about an address since reassigned. It describes the address's past, and many such records age out on their own schedule.

IPJury separates returned exact-address evidence from surrounding-prefix context. It does not query every blocklist or every community reporting system. That label is the fork in the road: the same word "listed" points at three different responses.

Diagnose in this order

1. Establish scope. Is the finding against your exact address or inherited from prefix context? Everything downstream depends on this answer.
2. Establish control. Do you hold this address, or does your provider assign it to you? On a dynamic or shared assignment you may be inheriting a previous or concurrent user's record, and the address may not be yours by tomorrow.
3. Read the other axes. Network role and anonymity are separate context. They do not prove the mechanism that caused an abuse record.
4. Find and fix the cause. Compromised host, misconfigured service, an open resolver or relay, a tenant of yours, or automation you did not know was running.
5. Then request removal, describing what changed and when.

Why filing first backfires

The named operator decides under its own current procedure. Read any remediation and waiting requirements it publishes, and distinguish a range listing from an exact-address record. IPJury does not submit, adjudicate or predict removal requests. Quoting a score instead of the actual listing scope cannot resolve what that operator recorded.

Are you the cause, or a neighbor?

On shared egress this distinction is everything. Under carrier-grade NAT an address-level record does not identify the subscriber responsible. Ask the provider what it can investigate rather than assuming the current user caused it. On a hosting range, an adjacent tenant's incident can produce a prefix-level listing that reaches your unrelated address. The evidence record separates the two: an exact-address finding concerns that address, not necessarily its current user; a prefix-only finding identifies a different scope to discuss with the operator.

Abuse contact basics

The registry record for an address names the party responsible for reports about it. Query it through RDAP, the structured successor to whois, which the regional registries expose over HTTP; IPJury's routing and allocation context tells you which registry to ask. Use the actual abuse contact in that authoritative record or the provider’s published contact. Do not construct a mailbox from the operator name. This tool does not fetch or verify the contact for you.

Two practical notes. The abuse contact for a prefix is often your upstream, which is who to talk to about a network-level listing. And the listing operator's own removal form is authoritative for their list; the abuse contact reaches whoever runs the network.