Entire IP range blocklisted: how a listing widens from one address to a /24 or a whole allocation, and who owns the fix

First, find out how wide it actually is

If you already know which box is spamming, stop it before you read anything: suspend it or null route it; blocking port 25 alone stops the mail but not the probes and the forwarding that also list an address at UCEPROTECT Level 1. Every automated clock runs from the last detection, three days for CSS, seven for UCEPROTECT Level 1, and Level 2 counts every detection once a source has run for two days, so an hour spent reading while the box runs is an hour added to the exit at every rung. Then start with the bounces your customers are forwarding: a Spamhaus rejection names the zone and carries the return code that separates SBL from CSS, XBL and PBL, and a UCEPROTECT rejection names its level, so the rung is usually in the bounce before any range read. The range read answers the second question, how wide it is.

The free checkers answer for one object at a time: Spamhaus's takes an address, a domain or a hash, Proofpoint's takes one address. A whole range means querying the DNSBL zone once per address, which is free for low volume non commercial use and is 256 lookups for a /24, run from your own resolver rather than a public one, because Spamhaus answers 127.255.255.254 to queries through public resolvers and 127.255.255.255 to excessive volume, and a script that treats any answer as a listing will flag every address in the block; or a paid or licensed API; or a tool that samples across the range and reads each sampled address. A subnethistory range lookup does the last of these: it reports how many addresses were checked and how many were flagged, draws one cell per sampled address on a block map with the unsampled remainder shown, marks the announced blocks of the origin AS it has room to show flagged, mild, clean or unsampled, saying how many cells stand for how many blocks, and prints the union of every list that flagged anything as Blocklisted on, with each address carrying its own count. Read the distribution. Flags on one address are one customer's box, and your clock: if the customer has not stopped it, you stop it, because UCEPROTECT counts impacts against your allocation and Spamhaus judges the provider's response, not the customer's. Flags on every address of one /24 with the rest quiet are usually a listing whose object is that /24, a UCEPROTECT Level 2 allocation or a range list such as ivmSIP/24, so read which list flagged them before concluding anything. Only where no list names the block, and the bounces come from a mailbox provider rather than a list, is a receiver side neighbourhood effect the likeliest reading. Flags spread evenly across the sample point at the allocation, or at a policy listing or an inherited one, which the list names and the origin history will separate; those are different rungs with different owners. Two honesty notes belong in the same breath: sampled means sampled, so an unsampled address is not a clean address, and if the read hit its row cap the counts are floors rather than totals, which the report says when it happens. The short key, before the theory: one address, the customer fixes and self removes, and you stop it if they have not; the allocation, you stop every Level 1 source and wait for the count to fall, or the ISP in charge writes to Spamhaus with evidence; a declaration, the PBL account, not a cleanup.

The widening ladder, rung by rung

The bottom rungs do not widen at all. Spamhaus's XBL lists individual addresses, IPv4 one at a time and IPv6 per /64; the checker at check.spamhaus.org is the only place XBL removals are handled, so the fix is to clean the box and remove it there, and it expires on its own, on a schedule Spamhaus does not publish, only if nobody does. CSS, the automated part of the SBL zone, lists IPv4 as single addresses and normally expires about three days after the last detection, longer for chronic abuse; its only widening rule is on IPv6, where many spamming /64s inside one network can push a listing to a larger block. UCEPROTECT Level 1 is per address and, by its removal page, an address temporarily listed there expires seven days after the last spam from it hits UCEPROTECT's traps, and the listing policy counts more than spam: probes and attacks against its sensors and SPF breaking forwarding list an address too, so check outbound connections before assuming the clock is running.

The mechanical rung is UCEPROTECT Level 2, the clearest published example of widening by rule. It lists what UCEPROTECT calls the allocation once Level 1 impacts inside it pass a size scaled threshold within a rolling seven days: any impact for blocks smaller than a /27, two for a /26, three for a /25, four for a /24, and progressively more for larger blocks under a published formula, six for a /23 and 954 for a /10 in its own examples. Impacts are counted per listed address over time, at most one per four hours at first, one per hour after a day, and every detection after two days, so UCEPROTECT itself warns that a single address left running can escalate an allocation alone. UCEPROTECT does not say how it derives the allocation boundary, and it can also list a network at Level 2 manually and permanently if it suspects the network was built for spamming.

The investigative rung is Spamhaus's SBL, and its escalation policy is published in full. When a network appears to be a threat requiring proactive measures, Spamhaus may apply escalated listings to that network's own infrastructure addresses, to extended ranges of that network, or to the entire network or networks related by ASN or RIR assignment. The named triggers are ignoring SBL listings and notifications for a significant period of time, claiming to remove a spammer that repeatedly reappears, providing bulletproof hosting or connectivity for blackhat operations such as other networks on Spamhaus DROP, or exhibiting other patterns that demonstrate persistent spam or security issues. No thresholds are published, and the timing phrase is the only one Spamhaus offers. Above it sits DROP, the routing list of netblocks Spamhaus judges controlled by criminal operations, which since 10 April 2024 also carries the sub allocated ranges that used to live in a separate eDROP list, so the allocation mechanism no longer decides eligibility; Spamhaus says space under the control of a legitimate network will never be listed there. The ASN tier, where whole autonomous systems are judged, is its own post. Two more rungs sit off the ladder: the PBL is a policy declaration that end user ranges should not send mail directly, made through ISP accounts and supplemented by Spamhaus, not a spam finding; and dead lists cannot escalate or delist anyone, SORBS having been shut down by Proofpoint on 5 June 2024 according to trade reporting, with its zones emptied and its domain no longer resolving.

Who owns the fix at each rung

Spamhaus is explicit about whose problem an SBL listing is: it is the network owner's responsibility to notify Spamhaus of changes and to request removal once the conditions behind the listing no longer apply, and removal requests for SBL listings proper are accepted only from the ISP in charge of the addresses, with end users sent back to their provider. That is different from CSS, which shares the same zone under a different return code, covers single addresses, and can usually be self removed at the reputation checker, within the limits Spamhaus puts on self removals. Spamhaus also says where the notices go: SBL records are named after the top level RIR assignment, and notifications and statistics are based on that network name, so the party Spamhaus writes to and counts against is the allocation holder, even when the listed range is one customer's server. Removal is always free, and Spamhaus publishes no separate rule for lifting an escalation; the route back is the same as for any listing. UCEPROTECT says the same thing in its own way: Level 2 clears itself, free of charge, once the allocation's seven day impact count falls under the threshold, which means removing the Level 1 impacts inside it, and only the provider can change a customer's situation. It also sells providers a per allocation express removal but withholds it from networks that overshot the threshold tenfold, rank in its worst five spam hosters, or are believed to collaborate with spammers, and a paid removal does not reset the counter, since UCEPROTECT says the netblock may be re-listed if new abuse becomes known, so paying before every Level 1 source inside the allocation is stopped can be undone by the next impact; and it offers a clean address inside a listed range an exclusion from the neighbourhood tiers through a paid whitelisted.org registration, priced in Swiss francs on its policy page as of September 2026 and non refundable if the address is later listed. On a report, the Enclosing blocks table names the parent allocation above your assignment, with its registry type, so you know which block to look up next; whether the flags extend across that parent is a second range lookup, not something the table shows. The abuse contact the report resolves is the published contact on the most specific record covering the address, your own where your assignment carries one and a parent's where it does not. It is where a notice would most likely land, not a record of where any notice actually went. If it shows your upstream, that is where Spamhaus's notices most likely landed, so ask them what they received and give them the evidence. It does not settle who files: Spamhaus accepts removal requests from the ISP in charge of the listed addresses, and if you operate them you are that party whether or not your abuse contact is on the record. Fix the record so the next notice reaches you, and file rather than wait. If your assignment has its own registry record with your abuse contact on it, you are plainly the ISP in charge and you file.

What each remedy actually is

The remedies are as different as the owners. For the automated single address tiers the remedy is fixing the cause and waiting: CSS re-lists quickly on re-detection, so a self removal followed by a relisting is Spamhaus telling you the source is still active. For UCEPROTECT Level 2 the lever sits at Level 1, stop every listed address and let the impacts age, and the honest re-check point is seven days after the last counted impact, not the morning you fixed it. For an SBL escalation the remedy is a written account from the ISP with evidence that the cause is gone. For a PBL hit the remedy is a declaration, through the ISP account for ranges or the one year self exclusion for a single static mail server. For receiver side neighbourhood effects the remedy is nothing but clean traffic and time, and here the published record is thin and worth stating precisely. On the pages read on 3 September 2026, Google's Gmail SMTP error reference, Yahoo's Sender Hub error codes and Microsoft's Exchange Online NDR reference, none of them publishes a /24 rule or a scoring method. Yahoo's deferral guidance names a poor reputation on the IP or its subnet, its example being the .255 block, as a cause of temporary deferrals. Gmail's error reference documents a temporary rate limit on your IP netblock when an unusual rate of unsolicited mail comes from it. Exchange Online's 5.7.501 bounce reads spam abuse detected from IP range, but Microsoft's own NDR reference explains it as a ban on the sending account inside Exchange Online, so it is not a receiver documenting a rule about your range. Talos puts recovery after a fix at a few hours to just over a week and says it cannot be hurried, and states that the network owner it displays for an address does not affect that address's reputation. The /24 is where operators expect collateral damage; none of these vendors publishes it as a rule or a score, and Yahoo's .255 example is as close as the published record gets. One subscription list, invaluement's ivmSIP/24, lists ranges by design when a spam pattern is seen across the block, while saying it avoids listing bystanders' neighbouring ranges. The per list forms and portals are their own subject, getting one address off a blocklist, and how addresses come off covers the general shape. And if the origin history shows a change of announcing network on the date you acquired the range, the listing may predate your use entirely; that is the inherited case in why new ranges arrive blocklisted. If you did not change transit and an AS you do not recognise is announcing the range, the flags may be someone else's traffic, and telling a hijacked prefix from a transfer is the post for that.

Containment, so the next one stays narrow

The advice to put every hosting customer on their own /24 is folklore: no list operator we could find says it, the figure circulates in vendor and IP lease blogs, and the nearest thing from an industry body is M3AAWG's rule for what a customer may bring to a sending platform, a minimum for bringing your own space rather than a rule for handing space out. The principle behind it is published, though. Spamhaus's PBL best practices say to segment so that email infrastructure is separate from the rest of the network's address space, its ISP FAQ says to block port 25 on dynamic ranges and list them in the PBL, and its PBL FAQ shows the expected shape, a /24 listed with small mail server ranges carved out. M3AAWG's hosting best practices tell hosts to register sub allocations larger than a /27 with working abuse role accounts, to acknowledge reports and act on them, and to suspend customers who do not respond; on IPv6 they say to give each customer a separate /64 so a receiver can block one customer without blocking everyone else on the same host. The current Sender BCP, version 4.0 from August 2026, sets /24 as the smallest IPv4 range a customer may bring to a sending platform, requires it to have a clean history, and sets /64 as the smallest IPv6 allocation per customer.

The registry record is what makes a customer separately addressable to a list operator. In the ARIN region a reassignment must carry the customer name, but customer contacts go on the record only when the customer asks or the block is routed outside the provider's network, so a customer who wants their own abuse contact visible has to ask for a detailed reassignment; SWIP and reassignment records covers the mechanics. In the RIPE Database an abuse-c on a customer's inetnum overrides the organisation's and any parent's, and the NCC's validation, by its own RIPE 87 account, replaces a dead abuse-c on a resource object with the LIR's working one, which is exactly the moment a customer's problem becomes yours by record. Reverse DNS is the other label: the Sender BCP wants one PTR per sending address matching a forward name that looks like a server rather than a pool, a match it now calls a requirement for direct mail to major mailbox providers, and an entity specific name on dedicated addresses so the responsible customer can be read from the PTR; Spamhaus's ISP FAQ wants the rDNS of a range to say what the range is for, and its only /24 advice is operational, sort the abuse mailbox into /24 chunks and triage by volume. Reverse DNS for a subnet covers the zone side. Finally the desk itself, because Spamhaus's escalation triggers are about the provider's behaviour, not the customer's: notifications ignored for a significant period is the published wording, and nothing more precise exists. MANRS expects an operational contact answered within 72 hours, a figure about operational queries rather than a promise about abuse reports, and a 2018 abuse.ch measurement found only 16 percent of six hundred plus notified hosting providers got reported content offline within six hours on average. Neither figure is a threshold Spamhaus applies, and no operator publishes one. What they show is what the measured field does, and a desk that answers at all, quickly, sits well ahead of it; that is the only containment; running an abuse desk is how.

Verifying the reading changed

Repeat the same range lookup after the relevant window, not before: for CSS, once the source is fixed and you have self removed at the checker, after the zone rebuilds and again a day later, because a relisting means the source is still active, or three days after the last detection if you left it to expire; for XBL, after the removal propagates and again a day later; seven days after the last counted impact for UCEPROTECT Level 2; up to just over a week for Talos; and whatever the ISP's written request produces for an SBL escalation. Spamhaus states its own clocks, the SBL zone rebuilt every five minutes, DROP re-evaluated daily, a PBL exclusion propagating in about fifteen minutes, and downstream mirrors refresh on their own schedules. The JSON API mirrors the report at 120 requests per minute per client address with no key, so the before and after reads can be scripted and kept. Kept by you, that is: the site holds no listing dates from the lists themselves, and its dated points exist only for the days somebody looked, so a gap is a gap; a feed's blacklisted verdict flipping between two of your reads shows under Verdict changes we have recorded, dated to the read that saw the new value, but that dates your reads, not the listing; it does not monitor anything for you and it alerts nobody; and a clean sample after the cleanup is a snapshot of sampled addresses, not a clean bill for the block.