emailmarketing.net

Avoiding Blocklistings — the ESP Playbook

Spamhaus's three-part operational playbook for ESPs digested — set senders up for success (onboarding safeguards, mandatory authentication, cross-functional policy), monitor and educate customers (data tiers, business-impact framing), and take proactive protective measures (risk-tiered IP pools, list scanning, behavioral routing, rate-limiting as leverage); plus the hosting-provider anti-fraud-signup controls.

Operational11 min read

Who it is for ESP operators

If you run an email service provider (ESP), one customer's bad practices can turn into a Spamhaus listing against infrastructure that all your customers share. Spamhaus's three-part Avoiding Blocklistings series is written for you, the platform operator, rather than for the individual sender, and explains how to run the platform so that this does not happen.

The series 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). The playbook below combines all three, and adds the controls against fraudulent sign-ups from Spamhaus's guidance for hosting providers.

The playbook is about operational strategy. For the mechanics, see:

The core idea: deliverability is a shared responsibility between the ESP and the sender. A blocklisting is almost never purely an infrastructure event. It traces back to list quality, consent and behavior. The ESP's job is therefore to make good behavior the easiest path, and to make 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. In Spamhaus's words: "make authentication a requirement right at the beginning so there isn't any damage to clean up."

Onboarding safeguards

Safeguard What it means in practice
Vetting at signup Questions and measures that evaluate the quality of each prospect. Decline signups that raise enough alarms. (The full questionnaire is in Customer Vetting.)
Tiered or provisional access Access granted in two stages: a review by the support team before platform access, or provisional, restricted access that requires domain validation and authentication before high-volume sending is unlocked.
Mandatory authentication Require SPF and DKIM before unrestricted sending, and in effect DMARC too, given the bulk-sender requirements of Gmail, Yahoo and Microsoft. Do not leave authentication as a later clean-up task. See Customer Domain Authentication.
Volume caps on new accounts Restrict volume until the sender authenticates its domains and shows safe sending patterns. Raise caps when the sender shows a need and keeps a clean reputation (progressive trust).
Permission-only list policy Prohibit lists without permission, in policy and in enforcement. Those lists are the direct source of "hard bounces, spam trap hits, and spam complaints", the three inputs that lead to a listing.

Write provisioning policy across teams

A point specific to Part 1 of the series: the deliverability team cannot write the onboarding and provisioning policy alone. Involve sales, marketing, customer support and leadership when creating it. The policy then balances enforcement against business reality, and is actually applied at the point of sale. A policy that the sales team works around is not a policy.

Align provisioning rules with inbox success, not only with signup conversion targets. The commercial pressure for frictionless signup is exactly what erodes list quality, and it is the same pressure that keeps subscription bombing alive.

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

The three data tiers

Spamhaus describes the monitoring problem by where the data lives, because that decides how quickly you can act on it:

Tier Data Delay and access
1. Instant-access Your own platform's delivery and engagement statistics Real time. Build your first alerts here
2. Cross-team request Custom reports, exports, and data your team has to pull Slower. Needs an internal workflow
3. Third-party Google Postmaster Tools (GPT), seed-list testing, deliverability monitoring vendors, Spamhaus reputation data External delays. GPT is unreliable, with ~2-day data delays. Treat it as confirmation, not as an early warning

The stance is proactive, not reactive. Monitor from a "10,000-foot view", using delivery and engagement data to catch problems before the customer reports them. The third-party tier lags: the 2-day delay in GPT means an emerging issue stays invisible until it has already hurt the customer. The behavioral signals in your instant-access tier are what actually give you time to act.

Signals to watch

  • Trends in delivery statistics: deferrals, temporary failures and block messages, by destination.
  • Engagement metrics: open and click rates. A falling open rate is an early warning. Falling engagement comes before reputation loss, and before the sender starts mailing deep into unengaged segments, which is what triggers trap hits.
  • Domain reputation as well as IP reputation: IP reputation alone is no longer enough, because domain and content reputation now dominate (see Blocklists & Spamhaus).
  • Volume anomalies: drops, or spikes to dangerous levels. A sudden spike is the classic sign of a compromised account or of injected spam (see Compromised Accounts).

Before building this, answer the two scoping questions Spamhaus asks: "What is it you'll monitor, and how?" Decide which dashboards, data feeds and tools already exist, and which you must build or buy. Outbound Monitoring describes a concrete design for watchers and alerts.

Educate customers in business terms

The most widely applicable idea in the series is how to get a customer to act on a recommendation. Deliverability teams lose this argument when they talk about reputation in the abstract. They win it by talking in the customer's terms:

  • Communicate in dollar signs, not sender reputation. Frame every recommendation around revenue and the customer's daily workload, not around a metric the customer does not feel.
  • Quantify the missed recipients. Track and show how many valid recipients the customer expected to reach, how many were actually reached, and how many were missed. Then put a value on it. Spamhaus's illustration: if each valid recipient is worth $1, the missed count becomes a dollar figure the customer feels immediately. Visualizing the revenue impact is what persuades.
  • Check that the request is realistic. Before pushing a change, assess whether it is reasonably possible with the customer's platform and resources (for example, can they segment manually at all?), and whether it deserves priority in their organization. A technically correct recommendation that the customer cannot carry out wastes your leverage.
  • "Show, don't tell." Use the customer's own data, or anonymized examples from similar senders, to show how performance improved after a change, rather than asserting best practice.
  • Deliver education in stages. Give manageable, achievable guidance on what the customer needs to know at each stage to succeed. Do not deliver everything at once, because information overload prevents adoption.
  • Correct myths actively. Customers often believe that 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 point of contact, not only support tickets: the website, the company blog and newsletter, the terms of service and product documentation, support and sales conversations, onboarding email sequences, and resources available before signup, so that prospects who are a poor fit rule themselves out before they cost you a listing. Given the requirements of the major providers, make setting up authentication records a mandatory onboarding step.

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

Education and monitoring are not enough against a customer who will not or cannot comply. Part 3 of the series is about platform mechanisms that protect the rest of your senders, whatever one customer does.

Risk-tiered IP segmentation

  • A shared or dedicated pool for new senders, so that you can observe how new accounts behave before they can affect the reputation of established customers.
  • Separate pools by reputation tier: "riskier senders mingle with similarly questionable customers while stellar customers can be isolated." Contamination stays within a tier.
  • Dedicated IP addresses with DKIM signing on the sender's own domain for senders who warrant isolation. Reputation then attaches to that sender alone.

Multi-Tenant Architecture covers the architecture of IP pools, automated promotion and demotion, and how reputation is isolated. IP Warm-Up covers warm-up.

Automation that removes manual bottlenecks

Mechanism Purpose
List scanning on upload Scan lists when they are uploaded to catch poor-quality lists (purchased, scraped or badly managed) before the first send. This is the single most effective control, because bad lists are the main cause of listings. Screen for role accounts, known traps, disposable domains and typo domains, and signs of purchase (see Customer Vetting and Spam Traps).
Auto-warmup Automated IP warm-up, so that segmentation is not a manual onboarding task that gets skipped under time pressure.
Behavioral routing Automatically detect suspicious increases in volume, or senders with poor statistics, and route that traffic to restricted IP addresses with stricter sending limits. This isolates the risk without waiting for a person to act.
Automated performance alerting Systems that notify customers of "low performance and associated risks" automatically, without a person having to notice each problem and write each warning.
Customer-facing hygiene tools Give customers list segmentation and a feature to suppress unengaged contacts, so that the right action takes one click rather than 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 while you investigate. This does two things at once. It protects the reputation of the pool, 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 the list, where a lecture about reputation failed. MTA Delivery Tuning covers the mechanics of adaptive traffic shaping.

Enforcement of last resort: termination

When remediation fails, remove the customer. Spamhaus sets out a process so that the termination holds up if disputed and does not itself become a business problem:

  1. Documented communication of the required changes;
  2. Multiple attempts to intervene, on record;
  3. Agreement among stakeholders (the same cross-functional group as in Phase 1) before ending the account.

Refer to Spamhaus's delisting instructions for the remediation workflow, and use community support channels for help with troubleshooting. Spamhaus Listings Deep Dive covers escalation to Spamhaus and delisting from it. Under the SBL escalation policy, tolerating one bad customer can widen a listing to your whole address allocation, which is why this last-resort step exists.

Fighting fraudulent sign-ups at registration

Spamhaus's separate guidance for hosting providers addresses a different threat from the sender-quality problem above: criminals who open accounts fraudulently to abuse the platform from the first day. Spamhaus puts it bluntly. In some services "50% of all new subscriptions are fraudulent — every second subscription," and "a good balance between abuse prevention and abuse handling" costs far less than cleaning up after abuse, because "an understaffed and overwhelmed abuse desk will make your service attractive to cybercriminals."

These controls are about fraud when someone signs up for an ESP account. Subscription Bombing covers a different problem, abuse of customers' signup forms. The fraud-prevention material in Customer Vetting covers preauthorization, records of fraudulent accounts, fraud scoring and tiered rights. The controls below are the concrete mechanics at registration.

Verification: reverse the direction

The key insight: criminals use disposable email and SMS providers to receive verification codes, but they cannot send from them. So reverse the flow:

  • Email verification: display a code at signup and require the customer to send it to you from the address being registered, instead of you sending a code to them.
  • Phone verification: apply the same send-based check. Block numbers already seen in fraudulent signups. A phone number assigned to a real person is harder to compromise or replace than an email address.
  • Suspension when information cannot be verified: hold the account until the customer makes contact through another channel.

Payment controls

Control Rationale
Reject cryptocurrency (BTC, ETH) and WebMoney Payments cannot be reversed and are pseudonymous, which fraud favors.
Require 3-D Secure, SafeKey, SecureCode or ProtectBuy Authentication by the card issuer defeats signups with stolen cards.
High-fraud regions: 6+ months prepayment, by methods that cannot be reversed (wire transfer, cleared check) Removes the chargeback route, and raises the cost of a throwaway account.
Consider requiring a scanned passport from high-risk jurisdictions A manual know-your-customer (KYC) check for the riskiest signups.

Customer blocklist (match every new signup against it)

Maintain an internal blocklist of first and 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 a concrete way to follow the Customer Vetting advice to "keep records of previously terminated fraud accounts and match new signups against them."

IP and network reputation at signup

  • Check the signup IP address against the Spamhaus SBL and XBL, and reject signups from listed address space. The SBL lists spam sources and operations. The XBL lists compromised or exploited hosts. See Blocklists & Spamhaus.
  • Reject Tor exit nodes, using a Tor DNSBL service.
  • Deploy Spamhaus DROP and EDROP (the Don't Route Or Peer lists of hijacked and criminal netblocks) on network routers, through BGPf (the paid BGP feed) where available, to refuse traffic from proxy and forwarding nodes outright, before signup.
  • Monitor traffic with Netflow or similar tools: watch for patterns unlike legitimate use, detect VPN connections to known blackhat forwarding nodes, and look for the same VPN endpoints across several terminated fraudulent accounts. The same exit point appearing again is a strong sign that the accounts are linked.

Policy, geography, and abuse response

  • A strong acceptable use policy (AUP) and terms of service that prohibit spam, malware and botnet activity, allow suspension and null-routing on credible abuse reports, and state an intention to cooperate with law enforcement and security organizations. Spamhaus offers an AUP Document Builder tool to draft or revise one.
  • Geographic restraint: limit how many foreign customers you accept until your abuse handling can keep up. Accepting signups worldwide that you cannot police is what produces the figure of "every second signup is fraud".
  • A fast abuse desk: null-route customer IP addresses immediately on credible abuse reports, and suspend the account until the customer makes contact. A rapid response is itself a deterrent. See Abuse Desk.
  • Outsource fraud checks to specialized third-party services when internal resources are not enough. Vetting Automation lists the vendors.

Sources. The three Avoiding Blocklistings parts and the article on fraudulent sign-ups at hosting providers are posts in Spamhaus's resource hub. They are operational guidance close to marketing material, not specifications. Their content was extracted from the live pages in July 2026. The figure of "$1 per valid recipient" is Spamhaus's illustrative example, not a benchmark. The figure of "50% of subscriptions fraudulent" is Spamhaus's stated observation "in some cases", not a universal rate. These sources give few numeric thresholds. The quantitative material is in the linked articles on the mechanics.

Check your own record

The free check reads what your domain publishes in DNS.

In this topic

All 16 in ESP Operations →