Does your ASN affect IP reputation? Choosing where your clean space gets announced

Three granularities of the same verdict

Reputation attaches at whichever level the system chose, and the levels behave differently. Spamhaus's SBL is a database of spam sources whose own description says it carries both individual addresses and address ranges. Its automated component, CSS, works at address granularity, listing IPv4 as single addresses and IPv6 as /64s or larger, with entries that normally expire about three days after the last detection. One level up, the DROP list names whole prefixes that Spamhaus describes as leased or stolen by professional spam or cybercrime operations, added only after its investigators have gathered evidence. At the top sits ASN-DROP, which lists AS numbers themselves. The separate eDROP list stopped existing on 10 April 2024, when its data was folded into DROP.

The jump from the middle level to the top is the one worth understanding, because it changes who is judged. A prefix listing indicts the space. An ASN listing indicts the announcer, and everything the announcer announces travels with it. How blocklists work covers the machinery underneath; this post is about the top rung.

The two lists that judge an origin

Spamhaus ASN-DROP lists autonomous systems it describes as hijacked or leased by professional spam or cybercrime operations. It is free to use with attribution, re-evaluated daily, and published as JSON; when we read the feed on 28 August 2026 it held roughly 440 AS numbers, a figure that moves, so treat any count as dated. Spamhaus relaunched it in September 2023, saying it had reinvigorated the list with a new algorithm and moved it to JSON, aimed at what it called the worst of the worst behaviour. Spamhaus is equally clear about what the list is not: the DROP family is an advisory drop all traffic set for firewalls and routing equipment, it calls them coarse filters rather than a silver bullet, and it says the list is small by comparison and should not be considered a replacement for the datasets that filter at SMTP time, its SBL, XBL and PBL.

The consequence is spelled out on Spamhaus's own page: feed ASN-DROP into your edge routers and you can blackhole listed networks, which in its words makes all networks announced by them unreachable. The corollary is ours rather than theirs, but it follows directly, since the list keys on the announcer: a clean prefix originated by a listed AS goes dark too, for every network applying the list. Keep the size of the thing in view, though. The list held roughly 440 AS numbers on the day we read it, and it names networks that are hijacked or run by criminal operations, so a mainstream upstream or hosting company is essentially never on it. The inheritance is real; the population it applies to is tiny, and what that leaves as the actual risk is the subject of a later section.

UCEPROTECT does the same thing for mail, in tiers. Level 1 lists single addresses from spamtrap and attack evidence, expiring seven days after the last hit. Level 2 escalates to the whole allocation containing them, on a threshold that scales with prefix size. Level 3 is the ASN tier: once an AS crosses a published score, defined as Level 1 impacts from that AS divided by its total addresses and multiplied by a hundred thousand, reaching fifty with at least fifty impacts inside seven days, every address assigned to that AS number is listed. Impacts are rate limited detection events rather than distinct addresses, so fifty impacts can come from fewer than fifty machines. UCEPROTECT also reserves a manual and permanent Level 3 listing for networks it suspects were created for spamming, warns on its own page that the tier can and probably will cause collateral damage to innocent users when used to block email, and tells end customers plainly that removal requests at Level 3 are futile, since only the network operator can change the score. It sells optional express delisting alongside the free automatic expiry, and its pages exclude the worst scoring networks from buying it.

Beyond those two we found no other anti abuse operator publishing a downloadable ASN level blocklist with public listing criteria. That is a narrow claim on purpose. Community curated ASN lists do exist and get used in production filters, but they enumerate categories of network, typically cloud and hosting, rather than measured abuse, which makes them a different instrument with a different failure mode. Other shapes of ASN level reputation circulate too, such as vendor rankings of high risk networks with per network scores, and Cloudflare Radar exposes per AS telemetry including bot traffic share, but those are scores and analytics rather than block lists. And on the mailbox side the honest finding is an absence: as of 28 August 2026, none of Gmail, Yahoo or Microsoft mentions the origin AS anywhere in its published sender guidance, where the documented units of reputation are the address and the domain. Yahoo's guidance touches routing exactly once, advising senders to publish routes for the space they own as protection against BGP hijacking, and even there the announcing AS is not treated as a reputation input. Undocumented is not the same as unused, so the only defensible statement is that none of them publishes anything about weighing your AS.

What the measurements actually show

Two research findings anchor the rest of this, and both need their scope kept intact. Researchers profiling serial hijackers at IMC in 2019 flagged 934 of the 19,103 autonomous systems they examined as showing hijacker like origination behaviour, of which 793 were publicly routable after filtering. Of those 793, 84, or 10.6 percent, appeared on at least one of six ASN-DROP snapshots taken between January 2017 and early 2019, against 1.1 percent of the roughly eighteen thousand non flagged systems in the same set, close to a tenfold difference. What the model keyed on was churn: systems that come and go from the routing table, originate a prefix briefly and move on, draw space from several registries, and rack up short lived origin conflicts. A 2024 replication reached similar accuracy on far less data and flagged 766 systems over a later window, overlapping the earlier flags on 279, which its authors read as reasonable agreement across five years of turnover. They also cautioned that daily snapshots miss short lived events and that legitimately multi origin networks, such as DDoS protection providers, show up as false positives. Any single flag is a signal, not a verdict.

The second finding is about leasing. A 2024 measurement study inferred that 4.1 percent of advertised IPv4 prefixes were leased in April 2024, and that 1.1 percent of those leased prefixes were announced by ASN-DROP listed systems against 0.2 percent of non leased ones, roughly five times as likely. Read the direction the authors read it: they describe abusers turning to the leasing market because a lease arrives with routing authorisation attached, so announcements that RPKI would once have filtered as unauthorised now validate. That the space is also unburned is our inference rather than theirs. Either way it is a portrait of who leases, not a penalty measured on clean tenants. And the complement deserves care too, because about 99 percent of leased prefixes were not announced by an ASN-DROP listed system, which is not the same as ninety nine percent clean. ASN-DROP is a deliberately tiny worst of the worst list; absence from it says nothing about address level or prefix level listings on the same space.

Vetting an origin before you commit

This is the practical part, and it is a lookup rather than a leap of faith. Before you agree that a given network will announce your space, look that AS number up directly on the front page, which is when the report pulls the AS view rather than treating it as context for an address. Read two things there. The confirmed tags, where any exist, sit on the announcing network far more often than on a prefix, and the vocabulary distinguishes the kinds of operation that matter here, from hosting and eyeball ISP through to proxy provider and worse. Then read the announced prefix list, which shows what else the network is currently originating, in other words the company your space would keep. That list reflects a recent window of roughly two weeks rather than a full inventory, so treat it as a current snapshot.

For the longer view, read the origin history on the prefixes themselves, one row per announcing network and prefix with first and last seen dates. Reading a prefix's routing history covers the patterns; the one that matters for this decision is churn, since that is exactly the behaviour the hijacker research keyed on. A prospective origin whose announcements hold steady for years reads differently from one whose prefixes rotate every few weeks.

The caveat belongs in the same breath. Confirmed tags are sparse. A network with no tag is not a certified clean network, and absence of a tag is never a finding of innocence. Layer the checks that are yours to make: does the network publish route objects and RPKI data, does its abuse address reach a human, does it participate in MANRS, whose network operator programme asks for filtering, coordination and globally validated routing data as mandatory actions with anti spoofing recommended. How to research an ASN is the long form of that investigation, aimed at third parties; here you are researching your own future landlord.

Your own AS, an upstream, or a cloud

Running your own origin buys control of the neighbourhood, and it has become easier in one region and not the other. It also concentrates the score rather than diluting it: UCEPROTECT's Level 3 formula divides impacts by the addresses in the AS, so a small self originated network reaches the threshold on the fifty impact floor alone, and impacts accrue repeatedly from a single persistent source. Owning the origin removes the neighbours; it also leaves you as the only tenant whose behaviour counts. Current ARIN policy says any organisation may be issued a single AS number on request, with justification needed only for additional ones, a default set by a policy implemented in September 2023; numbers are billed through the annual registration plan rather than per AS, and an organisation holding one to three of them sat in the smallest tier at 275 US dollars a year on the schedule in effect for 2026. RIPE remains stricter on paper, since its current AS assignment policy still asks that a network be connected to more than one autonomous system and that the routing policy be stated in RPSL; a 2025 proposal to drop that requirement was withdrawn in July 2026. The RIPE charging scheme for 2026 puts the annual fee at 1,800 euro per LIR account plus 50 euro per AS number assignment. Owning the origin also means owning the paperwork, which is route objects and, increasingly expected though not mandatory, ROAs naming your AS.

Announcing through somebody else means joining their standing. The traditional mechanics are a letter of authorisation plus route objects published under the provider's origin, as a letter of authorization describes, though the cloud pipelines increasingly validate control through RPKI and registry records instead. On the clouds the arrangement is explicit: AWS documents that bringing your own addresses means a ROA authorising Amazon's AS16509 and AS14618 to advertise them in its commercial regions, and Google documents that imported prefixes are announced by Google with the ROA naming AS396982 for its premium tier. Your registration, their origin. The traffic runs both ways, incidentally: AWS's own requirements say the addresses must have a clean history and that it may reject a range with poor reputation. A lessor rarely announces for you: the usual arrangement leaves origination with your own AS or with a cloud, which is why the leasing decision is really this same decision in different paperwork, and leasing out IPv4 safely covers the lessor's side of it. The specific question of whose network your space joins, read from the lessor's chair rather than the tenant's, is in vetting an IPv4 lessee.

One honest calibration before you act on any of this. ASN-DROP lists outright attacker controlled networks, so a mainstream transit provider or hosting company is essentially never on it, and the realistic risk of parking space behind an upstream is not that list. It is being scored alongside that network's other customers by the handful of systems that aggregate abuse per origin, of which UCEPROTECT's Level 3 is the only published blocklist we found; every blocking mechanism the mailbox providers and Spamhaus actually document keys on the address, the range or the domain. And there is a second effect that has nothing to do with abuse. Anti fraud and anti bot systems categorise by origin AS, so space announced by a hosting or cloud network reads as datacenter traffic whatever your own record looks like, which is a different problem with different remedies: why clean hosting addresses still get CAPTCHAs. On the other side of the same question, sizing a block to the evidence is what a defender is weighing when they decide whether to go wider than a prefix. Notably, the deliverability industry's own core reference, the M3AAWG sender best practices document, has not been revised since 2015 and never mentions AS numbers at all; its reputation advice stops at shared versus dedicated addresses. Warming a newly acquired range is where that advice picks up.

What changing origin does not fix

A cleaner announcer helps clean space stay clean. It does not clean dirty space. Spamhaus documents two ways off its lists: fix the cause and request removal for SBL entries, or wait out expiry after the abuse stops for the automated ones. The reason those listings follow the space is simpler than documentation: they are keyed to addresses and ranges, so who announces them is not what the record is about. DROP is re evaluated daily and its factors do include detected network reassignments, but the exit from DROP still runs through the underlying SBL record being cleared. If you are inheriting space with a past, the relevant post is why new ranges arrive already blocklisted.

The reverse direction is worth stating carefully, because it is where speculation usually creeps in. Neither Spamhaus nor UCEPROTECT documents that a prefix's old listings, once the abuse has stopped, count against a new origin AS. The documented risk is current behaviour: the ASN level systems score what a network announces now, so importing space that keeps misbehaving is what drags the new origin down. And one more piece of symmetry from the hijacker research: moving space around a lot is itself the pattern those models flag. Nobody publishes a blocklist built from them, so an operator who rotates origins to escape a reputation problem is not tripping a filter; they are making their network read, to anyone reviewing its routing history by hand, like the networks those models were trained on.