Post-mortem: Customer Range Briefly on Spamhaus DROP List

A customer’s /24 IP range appeared on the Spamhaus DROP list on a Friday afternoon. The DROP list is among the most consequential blocklists: many networks drop traffic to and from listed IP ranges entirely. The customer’s mail delivery to any destinations using DROP-aware filtering was effectively impossible during the listing.

The listing was not caused by the customer. A different operator sharing the same upstream provider had been compromised. The compromise produced abuse patterns that Spamhaus attributed to the broader range. The remediation involved provider coordination, evidence gathering for Spamhaus, and verification across multiple systems before delisting.

The total customer impact was approximately 8 hours from listing to verified delisting. The customer’s Friday evening sending was significantly affected. The Saturday morning sending was clean.

This post documents the incident, the investigation across multiple systems, the remediation process with Spamhaus, and what we changed about IP range selection going forward.

What the DROP list is

Spamhaus operates multiple blocklists for different purposes. The DROP list specifically is the most consequential.

DROP (Don’t Route Or Peer) lists IP ranges that Spamhaus has determined are wholly involved in or controlled by criminal infrastructure. The recommendation is that network operators should not route or peer with these ranges at all.

Many ISPs and network operators apply DROP at the network layer rather than just at the mail layer. Traffic to and from DROP-listed ranges is dropped entirely; mail is just one symptom of broader connectivity problems.

The criteria for DROP listing are more stringent than typical Spamhaus blocklists. DROP listings reflect Spamhaus’s determination that the range is fundamentally compromised rather than just occasionally involved in abuse.

DROP listings are rare. Most IP ranges never appear on DROP. The ranges that appear are those where Spamhaus has strong evidence of fundamental compromise.

How the customer ended up on DROP

The /24 range our customer used was assigned by an upstream provider that allocated to multiple customers. Our customer was a small portion of the /24; the rest was allocated to other operators we did not have relationship with.

One of those other operators was compromised. The compromise produced significant abuse activity: spam campaigns, botnet command-and-control, malware distribution. Spamhaus observed the patterns and added the entire /24 to DROP rather than just the specific compromised IP.

This is Spamhaus’s policy for range-level listings. When multiple IPs in a range show patterns of compromise or when the range’s history suggests systemic issues, Spamhaus lists the range rather than tracking individual IPs.

Our customer’s clean IP was caught up in the range listing despite not having contributed to the abuse.

The detection sequence

The incident detection followed our standard monitoring.

3:47 PM UTC Friday: customer’s bounce rate spike triggers alert. The bounces from multiple major receivers indicate connectivity issues rather than authentication or reputation issues.

3:55 PM: investigation begins. The bounce error messages suggest network-level issues. “Connection refused” and “Connection timeout” responses from multiple destinations.

4:08 PM: blocklist check reveals the DROP listing. The customer’s IPs are in a /24 range that appeared on DROP earlier in the day.

4:12 PM: customer notification sent. We explain the situation and our planned response.

4:30 PM: investigation expands to understand the cause. The patterns are not attributable to the customer’s activity. We start investigating the upstream provider context.

Investigation of cause

The investigation across multiple data sources:

Customer behavior verification

We verified the customer’s recent sending patterns. No abuse indicators. No content patterns that would have triggered Spamhaus. No volume changes. The customer was operating normally.

The customer-side was clean. The cause was external.

Upstream provider context

We contacted the upstream provider. They were aware of the DROP listing. Another customer of theirs had been compromised; the compromise produced the abuse that triggered the listing.

The provider was working on:

• Terminating the compromised customer’s services
• Documenting the remediation for Spamhaus
• Coordinating with affected legitimate customers (like ours)

Spamhaus communication

We initiated contact with Spamhaus to:

• Acknowledge the listing situation
• Provide evidence of our customer’s clean operation
• Request expedited review once the underlying cause was remediated

Spamhaus communication is typically formal. The evidence requested includes:

• Specific IPs being requested for delisting
• Authentication evidence (ownership documentation)
• Operational history demonstrating clean operation
• Evidence of the upstream remediation

We prepared the documentation for Spamhaus review.

The remediation process

The remediation involved multiple parallel workstreams.

Workstream 1: Upstream provider action

The upstream provider terminated the compromised customer’s services and documented the action for Spamhaus.

This took approximately 2 hours from incident detection to documented termination. The provider was operationally responsive once the situation was clarified.

Workstream 2: Evidence preparation for Spamhaus

We prepared evidence demonstrating our customer’s clean operation:

• Recent sending history showing no abuse patterns
• Authentication setup demonstrating proper practices
• Complaint rate data showing very low rates
• Customer business documentation

The evidence was organized for Spamhaus review.

Workstream 3: Customer communication

We provided the customer with regular updates throughout the incident. The communication included:

• The cause of the listing (not their fault)
• The remediation timeline (estimated 4-12 hours)
• Operational alternatives during the incident
• The full post-incident analysis

Some customers in similar situations get frustrated even when not their fault. The clear communication and demonstrated effort on their behalf maintained the relationship.

Workstream 4: Operational mitigation during the listing

For the customer’s most critical mail (transactional, time-sensitive), we worked on operational alternatives:

• Routing critical mail through different sending infrastructure
• Coordinating with the customer on which mail could wait
• Communication to the customer’s affected end-users where appropriate

The operational mitigation reduced the customer-facing impact during the listing.

The delisting

Spamhaus reviewed the evidence and remediated the listing approximately 8 hours after the original listing time.

The delisting verification involved:

• Confirmation from Spamhaus that the range was removed from DROP
• Verification through multiple network paths that traffic flowed normally
• Test sends to multiple major destinations to confirm acceptance

By Saturday morning, the customer’s infrastructure was fully operational.

What was different from other blocklist incidents

Most blocklist incidents we handle are different from this one.

Standard Spamhaus listings (SBL, XBL, CBL)

These typically affect specific IPs rather than ranges. The investigation focuses on what behavior triggered the listing. The remediation involves changing behavior and requesting delisting.

The standard process takes 3-14 days typically. The customer is responsible for the cause and the remediation.

DROP listings

The range-level listing is more consequential. The remediation requires coordination with upstream providers. The customer may not be responsible for the cause.

The process is more complex but Spamhaus can act more quickly when the cause is documented and remediated.

Other blocklists

Various other blocklists (SORBS, UCEPROTECT, others) have different criteria and processes. The pattern of incident response differs by blocklist.

For this specific incident, DROP-specific procedures applied. The lessons are bounded but apply specifically to DROP listings.

What we changed afterward

The incident produced specific procedural changes.

IP range selection criteria

We added explicit criteria for IP range selection:

• Verify the range’s recent listing history
• Check for other operators in the range that might create risk
• Prefer ranges with documented operational quality

We do not exclusively use small allocations now (which would reduce flexibility) but we screen ranges before deployment.

Upstream provider relationships

We documented the upstream providers’ practices and reputations more carefully. The provider relationships affect customer outcomes; the assessment is part of operational decisions.

Monitoring expansion

We added explicit monitoring for DROP list (alongside other major blocklists). The detection during this incident was through customer bounce patterns; faster detection comes from blocklist monitoring.

Customer communication templates

We developed templates specifically for blocklist incidents. The clear communication during incidents reduces customer anxiety.

Insurance and capacity planning

We documented our capacity for emergency mitigation during incidents. The ability to route critical mail through alternative infrastructure during the customer’s primary infrastructure being affected is operationally valuable.

What this revealed about IP shared environments

The incident demonstrated risks of shared IP environments.

Range-level reputation impact

Even in dedicated IP scenarios, the broader range affects reputation. Spamhaus and other blocklists sometimes act at range rather than IP level.

Upstream provider responsibility

The upstream provider’s overall customer quality affects all their customers. Operators selecting upstream providers should consider this.

Compensating practices

Customer practices alone cannot prevent these scenarios. Even clean operation can be affected by other operators sharing infrastructure.

The mitigation: choose upstream providers carefully, maintain monitoring capability, have incident response capability.

What other operators should consider

For operators selecting infrastructure providers:

Range history

Check the IP range’s recent history. Ranges with recent blocklist appearances may have higher risk of future appearances.

Operator mix

Understand what other operators share the range. Smaller, more curated ranges typically have lower risk than larger shared ranges.

Provider quality

The upstream provider’s overall customer screening affects all customers. Provider reputation matters beyond just the specific IPs assigned.

Incident response capability

Prepare for incidents even when not their cause. The capability to respond quickly during incidents reduces customer impact.

Customer communication

Clear communication during incidents preserves customer relationships. Templates and procedures help ensure consistent communication.

What we tell customers in similar situations

For customers facing similar blocklist incidents:

The cause matters. Customer-caused incidents require different response than upstream-caused incidents.

The communication matters. Customers who know what is happening handle the situation better than customers in the dark.

The remediation timeline varies. DROP listings can resolve in hours with proper response; other listings can take days.

The relationship matters. Operators who handle incidents well preserve customer relationships even through difficult situations.

The lessons compound. Each incident produces procedural improvements that prevent or reduce future incident impact.

What we expect

Looking forward, IP-related incidents will continue happening. The infrastructure layer of email operations involves shared environments where one party’s issues can affect others.

The mitigation: operational discipline, careful provider selection, monitoring infrastructure, incident response capability, customer communication discipline.

For our customer base, the incident reinforced existing practices and produced specific procedural improvements. The next similar incident will be handled faster and with less customer impact.

For our team, the experience built capability. The procedures developed during this incident apply to future incidents. The institutional learning compounds.

The customer relationship outcome

The customer in this incident remained on our infrastructure. The relationship was not damaged by the incident; if anything, our response demonstrated operational capability that built trust.

Several factors contributed:

• Proactive communication throughout the incident
• Clear explanation of cause (not their fault)
• Substantive remediation effort
• Honest timeline communication
• Continued service quality after the incident

The customer explicitly noted that the way we handled the incident strengthened their confidence in us. The honest engagement during difficulty produces better outcomes than perfect operation never tested.

The honest summary

DROP listings are rare but consequential. Eight hours of disruption is bounded but real customer impact. The remediation requires coordination across multiple parties.

For customers reading this with concerns about similar scenarios: the operational discipline to prevent and respond to these incidents is bounded. Working with providers who have this discipline produces better outcomes than working with providers who do not.

For other operators reading this: the patterns are generalizable. IP range selection matters. Upstream provider quality matters. Incident response capability matters. Customer communication discipline matters.

The next similar incident will come. The preparation work is bounded. The customer relationships built through good incident response continue paying back. The operational maturity grows through experience.

We continue working with the customer affected by this incident. The relationship continues. The lessons continue producing operational improvements. The work of running email infrastructure well continues being worthwhile.