Every address has a past. Read it in one search.

A whois record tells you who holds the space today, and a reputation score tells you how it reads this minute. We merge the registry record, RIR transfer records and BGP visibility windows into one dated timeline, so you can read what a block has been and not only what it is now.

Six upstream sources feed a report, and it names which of them answered, when each was fetched, and whether the answer came from cache. How far back the history goes depends on what those sources publish, and our own archive of a resource begins the first time somebody looks it up here.

Start with the origin history: every network that has announced the space, one row per network and prefix it announced, so a network that deaggregates appears more than once. Each row carries the window that announcement ran for and how many separate spells of visibility it had. One origin holding steady for six years reads very differently from four origins since last year.

The report raises its own findings alongside: the announcing network changing in the last twelve months, space that is registered but not announced, a registration less than two years old.

Transfers recorded by the RIRs land on the same timeline as the registration events and the routing windows, so a change of holder sits in order next to the announcements around it. If the announcing network changed inside the last twelve months, the report raises that as a finding rather than leaving you to spot it.

A block going quiet and lighting up again under a different network is something you read in sequence, instead of reconstructing it across several tools.

We can't tell you that, and we don't pretend to. We run no delivery test and make no deliverability prediction.

What you get is the input to the question: which reputation feeds report listings against addresses sampled inside the block, which lists named them, and what the space was doing before you took it on. Those feeds are metered, so a lookup checks a small number of addresses inside a block rather than all of them, and where no feed has an answer the field reads n/a rather than 0. Unchecked is not the same as clean.

Labels come from a fixed vocabulary published in the docs, and analysts apply them from a review queue, each label carrying a confidence shown on the report. Automated signals can propose a label, but a proposal stays visibly a proposal: it sits in its own group, marked as not yet confirmed, and it never drives the severity banner at the top of a report.

A label on a network and a label on a block inside it are separate records, and the report keeps them apart, because a reputable operator can announce a /24 leased to somebody running proxies.

No. The review queue fills from real searches, so a subject nobody has asked about has no entry in it, and nothing puts it in front of an analyst. Entries stay pending until someone reaches them, and reports are assembled and served either way.

Read a report with no labels as an absence of findings, not a clean bill of health.

Write to [email protected] with the prefix or AS number and what you think is wrong, and we'll review it. Be clear on what that is: an inbox, not a ticket system, and no promised turnaround.

A label that is withdrawn stays withdrawn. No automated process can quietly revive it, and every addition, amendment and withdrawal is written to an append-only audit trail.

Not who you are. There is no account, and your address is only ever kept as a salted hash whose salt is regenerated every time the process restarts.

The query itself is another matter: a public endpoint lists a short run of recent searches with the normalised query, its kind and a timestamp, and nothing about who searched. A lookup of your own address is kept off that list. The privacy page is the long version.