A blocklist can identify an abusive source without knowing every person using the same pipe.
That is where the trouble begins.
Modern email is full of shared infrastructure. Thousands of organizations can send through the same email service provider. Many websites can share a hosting network. A marketing platform may place unrelated customers behind the same pool of outbound IP addresses.
That makes reputation efficient.
It also makes reputation contagious.
Spamhaus explains that its Spamhaus Blocklist can contain individual IP addresses or entire IP ranges associated with spam and other abusive activity. Receiving mail administrators decide whether to reject, flag, or further filter mail based on those listings. See the Spamhaus Blocklist documentation and its explanation of how blocklists are used.
The enforcement unit can therefore be larger than one individual sender.
Shared infrastructure creates shared risk
Suppose one customer on a shared outbound mail platform sends a terrible purchased list.
Complaints rise. Spam traps are hit. The shared sending IP acquires a bad reputation.
Other customers using that same IP may be sending ordinary newsletters to people who asked for them.
Mailchimp openly describes this problem in its documentation on spam traps: if a sending IP is denied or blocklisted, that can affect delivery for other Mailchimp users sharing the infrastructure. See Mailchimp’s explanation of spam traps.
This is not evidence that blocklists are careless.
It is evidence that attribution becomes difficult when many independent actors share technical resources.
Broad blocking and precise attribution pull in opposite directions
Receiving systems operate under pressure.
They may need to reject enormous volumes of abusive mail in real time. Investigating every message back to the exact contractual customer behind an IP is often impossible during the SMTP transaction.
A broad reputation signal is fast.
A precise human attribution is slow.
That tradeoff creates false-positive risk.
Spamhaus itself warns that different blocklists are designed for different purposes and that using one in the wrong place can create problems. Its Policy Blocklist, for example, identifies IP ranges that should not send mail directly to destination servers; Spamhaus has specifically warned providers not to misuse that list against authenticated outbound users. See its discussion of PBL misuse.
The lesson is not that blocklists are bad.
Without reputation systems, recipients and mail operators would absorb even more abuse.
The lesson is that technical reputation belongs to infrastructure, while responsibility belongs to actors.
Those two layers do not always line up neatly.
Spam Empires exploit shared systems because scale loves aggregation.
The defensive side aggregates too.
Sometimes innocent mail gets caught between them.