Avoiding Blocklistings — the ESP Playbook

Spamhaus's three-part Avoiding Blocklistings series is written for the ESP operator, not the individual sender: how to run the platform so that a customer's bad practices never converts into a Spamhaus listing against shared infrastructure. It divides the work into three phases — set senders up for success (before they send), monitor and educate customers (while they send), and take matters into your own hands (proactive protection and enforcement). This article digests all three into one playbook and folds in the hosting-provider anti-fraud-signup controls from Spamhaus's service-provider guidance.

It is deliberately the operational-strategy layer above the mechanics articles. It does not restate:

• listing criteria, return codes, and delisting workflows — see Blocklists & Spamhaus and Spamhaus Listings Deep Dive;
• what to check before letting a customer send — see Customer Vetting;
• signup-form / list-bombing defenses — see Subscription Bombing;
• IP-pool isolation mechanics and promotion/demotion — see Multi-Tenant Architecture;
• the monitoring stack itself — see Outbound Monitoring and Reputation Monitoring.

Core framing: deliverability is a shared responsibility between the ESP and the sender. A blocklisting is almost never a pure infrastructure event — it traces to list quality, consent, and behavior — so the ESP's job is to make good behavior the path of least resistance and bad behavior expensive and short-lived.

Phase 1 — Set senders up for success (before the first send)

The cheapest listing to avoid is the one you prevent at onboarding: "make authentication a requirement right at the beginning so there isn't any damage to clean up."

Onboarding safeguards

Safeguard	What it means operationally
Vetting at signup	Vetting questions/measures to evaluate each prospect's quality; decline signups that raise sufficient alarms. (Full questionnaire → Customer Vetting.)
Tiered / provisional access	Two-stage grant: support-team review before platform access, or provisional restricted access that requires domain validation and authentication before high-volume sending is unlocked.
Mandatory authentication	Require SPF/DKIM (and, given the Gmail/Yahoo/Microsoft bulk-sender mandates, effectively DMARC) before unrestricted sending — not as a later clean-up task. See Customer Domain Authentication.
Volume caps on new accounts	Restrict volume until the sender authenticates domains and demonstrates safe sending patterns; raise caps on demonstrated need and clean reputation (progressive trust).
Permission-only list policy	Prohibit non-permissioned lists in policy and enforcement — they are the direct source of "hard bounces, spam trap hits, and spam complaints," the three inputs that feed a listing.

Make provisioning policy a cross-functional artifact

Spamhaus's distinctive point in Part 1: onboarding/provisioning policy cannot be written by the deliverability team alone. Involve sales, marketing, customer support, and leadership when creating it, so the policy balances enforcement against business reality and actually gets applied at the point of sale. A policy the sales team routes around is not a policy. Align provisioning rules with inbox-success outcomes, not with signup-conversion targets alone — the commercial pull toward frictionless signup is exactly what erodes list quality (the same dynamic that keeps subscription bombing alive).

Phase 2 — Monitor and educate customers (while they send)

The three data tiers

Spamhaus frames the monitoring problem by where the data lives, which dictates how fast you can act on it:

Tier	Data	Latency / access
1. Instant-access	Your own platform's delivery and engagement statistics	Real-time; build your first-line alerting here
2. Cross-team request	Custom reports, exports, data your team must pull	Slower; needs internal workflow
3. Third-party	Google Postmaster Tools, seed-list testing, deliverability-monitoring vendors, Spamhaus reputation data	External latency; GPT is buggy with ~2-day data delays — treat it as confirmation, not early warning

The operating stance is proactive, not reactive: monitor from a "10,000-foot view" using delivery/engagement data to catch problems before the customer reports them. Because the third-party tier lags (GPT's 2-day delay creates a reactive window where an emerging issue is invisible until it has already hurt the customer), your instant-tier behavioral signals are what actually give you lead time.

Signals to watch

• Delivery-statistic trends — deferrals, tempfails, block messages by destination.
• Engagement metrics — open and click rates; a dropping open rate is a leading red flag (falling engagement precedes reputation loss and the deep-into-unengaged-segments behavior that triggers trap hits).
• Domain reputation alongside IP reputation — IP alone is no longer sufficient (domain and content reputation now dominate; see Blocklists & Spamhaus).
• Volume anomalies — drops or spikes to dangerous levels; a sudden spike is the classic compromised-account / injected-spam signature (see Compromised Accounts).

Before building this, answer the two scoping questions Spamhaus poses: "What is it you'll monitor, and how?" — decide which dashboards, data feeds, and tools already exist versus what you must build or buy. (The concrete watcher/alert design is in Outbound Monitoring.)

Educate customers — the business-impact framing

The most transferable idea in the series is how to get a customer to act on a recommendation. Deliverability teams lose this argument when they speak in reputation abstractions; win it by speaking in the customer's terms:

• Communicate in dollar signs, not sender reputation. Frame every recommendation around revenue and the customer's day-to-day workload, not around a metric they don't feel.
• Quantify the miss. Track and show how many valid recipients you expected to reach, how many you actually reached, and how many were missed — then attach a value (Spamhaus's illustration: if each valid recipient is worth $1, the missed count is a dollar figure the customer feels immediately). Data visualization of revenue impact is the persuasion tool.
• Check that the ask is realistic. Before pushing a change, assess whether it is reasonably possible given the customer's platform capabilities and bandwidth (e.g., is manual segmentation even feasible for them?), and whether it deserves priority within their org. A technically correct recommendation the customer cannot execute is wasted leverage.
• "Show, don't tell." Use the customer's own data — or anonymized examples from comparable senders — to demonstrate the poor→good performance delta after a change, rather than asserting best practice.
• Phase the education. Deliver digestible, achievable guidance about what they need to know at each stage to succeed; avoid dumping everything at once (information overload defeats adoption).
• Debunk myths actively. Customers arrive believing shortcuts work; authoritative guidance that names and refutes the common myths (holiday "rule tightening," spam-word filters, buying lists for a revenue push) is part of the job. See Two Worlds of Email Deliverability and Content & Design for Deliverability.

Where education lives

Spread guidance across every touchpoint, not just support tickets: website and company blog/newsletter; Terms of Service and product documentation; support and sales conversations; onboarding email sequences; and pre-signup resources (so bad-fit prospects self-select out before they cost you a listing). Make authentication-record setup a mandated onboarding step, given the major-provider requirements.

Phase 3 — Take matters into your own hands (proactive protection)

Education and monitoring are not enough against a customer who won't or can't comply. Part 3 is about platform mechanisms that protect the rest of your senders regardless of one customer's behavior.

Risk-tiered IP segmentation

• A shared pool (or dedicated pool) for new senders, so you observe new-account behavior before it can touch established customers' reputation.
• Stratify pools by reputation tier: "riskier senders mingle with similarly questionable customers while stellar customers can be isolated." Contamination is contained within a tier.
• Dedicated IPs with sender-specific DKIM domain signing for senders who warrant isolation — reputation attaches to that sender alone.

(The IP-pool architecture, promotion/demotion automation, and reputation isolation mechanics are in Multi-Tenant Architecture; warm-up in IP Warm-Up.)

Automation that removes manual bottlenecks

Mechanism	Purpose
List scanning on upload	Scan lists at upload time to catch poor-quality lists (purchased, scraped, mismanaged) before the first send — the highest-leverage single control, since bad lists are the primary listing cause. Screen for role accounts, known traps, disposable/typo domains, purchase indicators (see Customer Vetting and Spam Traps).
Auto-warmup	Automated IP warm-up so segmentation isn't a manual onboarding chore that gets skipped under time pressure.
Behavioral routing	Automatically detect suspicious volume increases or senders with bad stats and route that traffic to restricted IPs with stricter sending ability — isolating the risk without human latency.
Automated performance alerting	Systems that notify customers of "low performance and associated risks" automatically, without a human having to spot and compose each warning.
Customer-facing hygiene tools	Give customers list-segmentation and suppress-unengaged features so the right action is one click, not a project. See List Hygiene & Sunset Policies and Suppression-List Architecture.

Rate-limiting as leverage, not just protection

When a sender's statistics reach a critical level, apply automated volume rate limits during the investigation window. This does two things at once: it protects the pool's reputation and it is "the leverage you need to get those stubborn senders" to engage — a throttled customer who is losing throughput has a concrete reason to fix their list where a reputation lecture failed. (Adaptive shaping mechanics: MTA Delivery Tuning.)

Enforcement of last resort — termination

When remediation fails, remove the customer. Spamhaus specifies the process so termination survives dispute and doesn't itself become a business problem:

1. Documented communication of the required changes;
2. Multiple intervention attempts on record;
3. Stakeholder alignment (the same cross-functional group from Phase 1) before pulling the plug.

Reference Spamhaus's delisting instructions for the remediation workflow and lean on community support channels for troubleshooting help. (Escalation to and delisting from Spamhaus specifically: Spamhaus Listings Deep Dive. The SBL escalation policy — where tolerating one bad customer can widen a listing to your whole allocation — is why this last-resort step exists.)

Fighting fraudulent sign-ups at registration

Spamhaus's separate hosting-provider guidance targets a distinct threat from the sender-quality problem above: criminals opening accounts fraudulently to abuse the platform from day one. Spamhaus's blunt framing: in some services "50% of all new subscriptions are fraudulent — every second subscription," and "a good balance between abuse prevention and abuse handling" is far cheaper than post-abuse cleanup — "an understaffed and overwhelmed abuse desk will make your service attractive to cybercriminals."

This complements Subscription Bombing (which is about abuse of customer signup forms, not fraud at ESP account signup) and the fraud-prevention chapter in Customer Vetting (preauthorization, fraud-account recordkeeping, fraud-scoring, tiered rights). The controls below are the concrete registration-time mechanics.

Verification — invert the direction

The signature insight: criminals use disposable email and SMS providers to receive verification codes but cannot send. So invert the flow —

• Email verification: display a code at signup and require the customer to send it to you (from the address being registered), rather than you sending a code to them.
• Phone verification: apply the same send-based check; block numbers previously seen in fraudulent signups — a phone number assigned to a real person is harder to compromise or churn than an address.
• Suspension on unverifiable info: hold the account until the customer makes contact through an alternative channel.

Payment controls

Control	Rationale
Reject cryptocurrency (BTC, ETH) and WebMoney	Non-reversible, pseudonymous — favored by fraud.
Require 3-D Secure / SafeKey / SecureCode / ProtectBuy	Card-issuer authentication defeats stolen-card signups.
High-fraud regions: 6+ months prepayment, non-reversible methods (wire, cleared check)	Removes chargeback vector; raises the cost of a throwaway account.
Consider scanned passport from high-risk jurisdictions	Manual KYC gate for the riskiest signups.

Customer blocklist (match every new signup against it)

Maintain an internal blocklist keyed on: first/last names; postal addresses; phone and mobile numbers; email addresses; payment-service identifiers (PayPal, WebMoney, etc.); signup IP addresses; and browser User-Agent strings. It works because criminals "frequently do not change the email address and often attempt to sign up from the same IP address." (This is the concrete implementation of Customer Vetting's "keep records of previously terminated fraud accounts and match new signups against them.")

IP and network reputation at signup

• Query the signup IP against Spamhaus SBL and XBL — reject signups from listed space. (SBL = spam sources/operations; XBL = compromised/exploited hosts. See Blocklists & Spamhaus.)
• Reject Tor exit nodes via a Tor-DNSBL service.
• Deploy Spamhaus DROP / EDROP (Don't Route Or Peer lists of hijacked/criminal netblocks) on network routers — via BGPf (the paid BGP feed) where available — to deny traffic from proxy/forwarding nodes outright, before signup.
• Netflow / traffic monitoring: watch for patterns uncharacteristic of legitimate use, detect VPN connections to known blackhat forwarding nodes, and correlate consistent VPN endpoints across multiple terminated fraudulent accounts (the same egress reappearing is a strong linkage signal).

Policy, geography, and abuse response

• Strong AUP/ToS prohibiting spam, malware, and botnet activity; authorizing suspension and null-routing on credible abuse reports; and stating intent to cooperate with law enforcement and security organizations. Spamhaus offers an AUP Document Builder tool to draft/revise one.
• Geographic restraint: limit acceptance of foreign customers until you have the abuse-handling capacity to match — accepting global signups you cannot police is what drives the "every second signup is fraud" number.
• Fast abuse desk: null-route customer IPs immediately on credible abuse reports and suspend pending contact; rapid response is itself a deterrent. See Abuse Desk.
• Outsource fraud checking to specialized third-party services when internal resources are insufficient (the vendor landscape is catalogued in Vetting Automation).

Related articles

• Customer Vetting — the pre-send/post-send vetting questionnaire and the Hosting-Abuse-BCP fraud-prevention chapter this extends.
• Subscription Bombing — abuse of customer signup forms (distinct from ESP-account fraud).
• Multi-Tenant Architecture — the risk-tiered IP-pool mechanics referenced in Phase 3.
• Outbound Monitoring · Reputation Monitoring — the monitoring stack behind Phase 2.
• Blocklists & Spamhaus · Spamhaus Listings Deep Dive — listing criteria, SBL escalation, and delisting.
• Vetting Automation — third-party fraud/signal vendors for registration screening.
• Abuse Desk — the null-route-and-suspend response referenced above.

---

Provenance: the three "Avoiding Blocklistings" parts and the hosting-provider fraudulent-signups article are Spamhaus resource-hub deliverability posts (marketing-adjacent operational guidance, not spec documents); content extracted via WebFetch of the live pages, July 2026. The "$1 per valid recipient" figure is Spamhaus's illustrative example, not a benchmark; the "50% of subscriptions fraudulent" figure is Spamhaus's stated observation "in some cases," not a universal rate. Concrete numeric thresholds are intentionally sparse in these sources — the quantitative material lives in the mechanics articles cross-linked throughout.