Why the question is harder than it looks
Ask what an address’s reputation is and the honest answer is that there are several answers produced by several organisations using several methods, and they are not required to agree. Understanding why requires separating the types of evidence that get called reputation, because they differ in what they can support and in how they go wrong.
Three kinds of data get bundled under the label. Ownership data says which organisation an address range is registered to, which is a matter of public record and cannot be wrong in the way an inference can. Behavioural observations describe what a provider has seen associated with an address, which is empirical and depends on that provider’s visibility. Model output converts those observations into a number or a label, which introduces every assumption the model makes along with the data.
Only the first is a fact. The second is evidence. The third is an opinion with a provenance, and it is the one most likely to be treated as a verdict.
Ownership: the part that is simply recorded
Every address range is allocated to an organisation and announced in internet routing by an autonomous system. This layer is stable, public and checkable, and the ASN lookup reports it directly. A range registered to a hosting provider is a hosting provider’s range; that is not an accusation about anyone using it.
The confusion arises because ownership is frequently used as a proxy for behaviour. A connection arriving from a range belonging to a cloud provider behaves differently in aggregate from one arriving from a consumer network, and treating them differently is a reasonable heuristic. The failure mode is treating the heuristic as a fact, which produces the false positives described in VPN and proxy detection explained.
Behavioural observations: empirical and partial
A provider with visibility across many networks can observe that an address sends unusual volumes of mail, authenticates to services in patterns no household produces, or has been reported for abuse. Those observations are real, and they are exactly the kind of signal that identifies a compromised host.
Two limits apply. Coverage is uneven: a provider sees only what crosses its own vantage points, so an address that behaves badly elsewhere can look unremarkable. And attribution is coarse: an address is shared, so an observation about it may describe a previous occupant of the range, another customer of a hosting provider, or a device on a corporate network rather than the person currently connecting.
Model output: where the disagreements come from
Converting observations into a number requires decisions about which observations matter and how much. Those decisions differ between providers, which is the mechanism behind the disagreement people find so confusing.
One provider may weight mail-related observations heavily because its customers are mail receivers. Another may weight automated access patterns because its customers are content delivery networks. A third may focus on whether an address is a known exit point for a commercial anonymity service. Each produces a defensible answer to a slightly different question, and the answers cannot be reconciled into a single truth because the questions were never the same.
This is the reason there is no composite score on this site. Averaging inputs that were produced to answer different questions produces a number with no defined meaning, and a number with no defined meaning gets treated as a verdict. The IP reputation check presents each provider’s observations separately with the source named, and the IP purity check explains what the individual indicators mean rather than combining them.
Reading a report without over-reading it
The first habit worth building is to check the source of every value and the time it was produced. A risk indicator without a provider name and a timestamp is not evidence, and a report that omits both should be treated as a summary rather than as a finding.
The second is to distinguish an observation from its absence. A provider that has raised no flags has told you what it has observed and nothing more. Treating an unobserved signal as a negative signal is the most common error in this category, and it is the substitution this site’s interface refuses to make: an unavailable field is reported as unavailable rather than defaulted to clean.
The third is to read disagreement as information. Two providers raising different flags on the same address is not a failure of the tools; it is a description of the evidence, and it is usually more useful than a single confident label. What to do about it depends on the decision being made, which is a policy question rather than a measurement one.
Where reputation actually matters
Mail is where it matters most, and where the consequences are most immediate. Once authentication is in place, reputation is the dominant input in placement decisions, alongside how recipients treat the mail. The practical levers are a clean sending history, a dedicated address rather than a shared one, and a list that does not generate complaints — the subject of why legitimate email goes to spam and the blacklist removal guide.
Fraud controls are the second place it appears, and the one where misuse is most tempting. Using reputation to challenge a transaction is defensible; using it to refuse one outright means refusing a legitimate customer because somebody previously used the same shared address. The signal is weak enough that it should inform a decision rather than make it.
What reputation data cannot support
It cannot identify a person, and it cannot support a conclusion about intent. An address is shared, reassigned and described by inference, so a flag attached to one is a statement about a network attachment point at a moment in time.
It cannot be reduced to a single clean answer, and any tool that offers one has either hidden the inputs or averaged things that should not be averaged. It also cannot tell you whether a specific message will be delivered or a specific connection accepted; both depend on the receiving end’s own model, which is not published.
The layer below reputation is resolution and addressing. Whether a name resolves at all is answered by DNS lookup, and which network owns the address involved is answered by the ASN lookup. Keeping those questions separate from reputation is the habit that prevents a routing problem from being diagnosed as a trust problem, and the network guide sets out the order.