A blacklisted sending domain is the closest thing cold email has to a heart attack: everything stops at once, across every campaign and every mailbox on the domain. The useful news is that the fix is a fixed sequence, and none of it costs money.
In order: confirm the listing, stop sending, find the cause, fix it, request removal, then re-warm. Skipping to the removal form before fixing the cause is the most common mistake, and it earns a re-listing.
- Where to check: check.spamhaus.org. Your domain and your sending IP are separate lookups, and usually separate problems.
- How long: Spamhaus processes an approved removal in minutes, and most DBL listings expire on their own once the activity stops. Getting delivery back to normal takes another two to four weeks.
- What it costs: nothing. Spamhaus states there is never any charge or fee for removing a listing.
What the bounce message is actually telling you
The rejection you got names the list. The number in front of it doesn't. 550 only means a permanent refusal, and 5.7.1 is the generic "delivery not authorized, message refused" status from RFC 3463, which covers everything from a blocklist hit to a rule the recipient's admin wrote last Tuesday. The useful part is the text after it.
Most of those strings look alike because most receiving servers run Postfix, whose default rejection template is Service unavailable; $rbl_class [$rbl_what] blocked using $rbl_domain. So the zone name it prints is the list that actually blocked you, and the thing in brackets is what got listed.
| What the bounce says | What blocked you | Whose problem it is |
|---|---|---|
blocked using zen.spamhaus.org, or Microsoft's Client host [IP] blocked using Spamhaus | Spamhaus ZEN: one lookup returning SBL, CSS, XBL and PBL results for an IP | Your sending platform's shared IP pool, in almost every case |
blocked using dbl.spamhaus.org | Spamhaus DBL: a domain listing | Yours. Your sending domain, or a domain you link to |
blocked using multi.surbl.org, or a MULTI-SURBL reference | SURBL: a domain found inside the message body | Yours, and often the link domain rather than the From domain |
blocked using b.barracudacentral.org | Barracuda Reputation Block List: an IP listing | Your platform's IP pool |
blocked using bl.spamcop.net | SpamCop Blocking List: an IP listing | Your platform's IP pool |
blocked using dnsbl-1.uceprotect.net (or -2, -3) | UCEPROTECT. Level 1 lists single IPs, level 2 whole allocations, level 3 whole ASNs | Your platform's, and levels 2 and 3 aren't about your sending at all |
blocked using Blocklist 1; To request removal ... forward this message to delist@microsoft.com | Microsoft's own internal blocklist, not a public DNSBL | Your platform's IP. Delisting goes through Microsoft's portal, not Spamhaus |
550-5.7.1 ... likely unsolicited mail, or 421 4.7.28 Gmail has detected an unusual rate of unsolicited mail | Gmail's own filtering and rate limiting. No blocklist involved | Yours, but it's reputation and volume, not a listing |
550 5.7.1 ... very low reputation of the sending domain | Gmail's domain reputation score | Yours, and no delisting form will move it |
Two things fall out of that table. First, if the bounce names an IP-based list, buying a new domain won't help, because the listed thing is your provider's shared IP. Second, a good share of the "blacklist" bounces cold senders panic about aren't blacklists at all. Gmail refusing you on reputation looks near-identical at a glance and has a completely different fix.
If your mail server prints the raw DNS answer instead of a zone name, the code decodes it. 127.0.0.2 is the SBL, 127.0.0.3 is the CSS, 127.0.0.4 is the XBL, and 127.0.0.10 or 127.0.0.11 is the PBL depending on whether the ISP or Spamhaus entered the range. Domain answers live in the 127.0.1.x range: 127.0.1.2 is a spam domain, 127.0.1.4 phish, 127.0.1.5 malware, and the codes from 127.0.1.102 to 127.0.1.106 mark a legitimate domain that's been abused or a spammed redirector rather than one built for spam.
Step 1: Confirm which list you're actually on
The lookup is free and takes under a minute. Do it in this order.
- Enter your sending domain at check.spamhaus.org. That's the domain your mailboxes send from, for example
outreach-yourbrand.com. - Check your link domain too. Reputation lists watch the domains inside messages, not just the From address. SURBL in particular lists them. If you send from
outreach-yourbrand.comand link toyourbrand.com, a listing on either one hurts you, so check both. - Check your sending IP separately. If you send through Instantly, Smartlead or EmailBison, that IP belongs to the platform and is shared with hundreds of other senders. It's still worth knowing whether a shared-pool listing is dragging you down.
- Read which list came back. A domain hit is the DBL. An IP hit is one of the SBL, CSS, XBL or PBL, returned together as ZEN.
You get one of two useful answers. Not listed means Spamhaus isn't your problem, and if delivery is still bad the cause is elsewhere: authentication, content, warmup, or placement drifting to spam without an outright block. Listed gives you the specific list, usually a reason code, and a link to the removal process.
That domain-versus-IP read is the whole game. A domain listing means your setup earned it and you have to fix the cause. An IP listing on a shared platform pool usually means someone else in the pool caused it and the platform handles the delisting, so pause sending and report it to their support rather than filling in a Spamhaus form for an IP you don't control.
For a wider sweep, MXToolbox checks roughly 100 blocklists in one pass, and our free deliverability checker checks Spamhaus and SURBL alongside SPF, DKIM and DMARC in one go, which matters because auth gaps and listings tend to travel together.
Not every list carries the same weight. The full picture:
| Blocklist | What it lists | Whose problem it usually is |
|---|---|---|
| Spamhaus DBL | Domains seen in spam or with a bad reputation | Yours. Your sending domain or your link domain |
| Spamhaus SBL | IPs Spamhaus judges to be spam sources | Your sending platform |
| Spamhaus CSS | IPs auto-detected as low-reputation or snowshoe senders | Your sending platform |
| Spamhaus XBL | Compromised, hijacked or malware-infected IPs | Your platform, or a server you own that's been hacked |
| Spamhaus PBL | IP ranges that shouldn't send mail directly, such as residential and dynamic | Your platform or ISP. It's a policy statement, not an accusation |
| Spamhaus ZEN | Nothing of its own — one lookup returning SBL, CSS, XBL and PBL together | Whichever underlying list actually fired |
| SURBL | Domains appearing in message bodies and links | Yours. Your links can trigger it even if the sending domain is clean |
| Barracuda, SpamCop | IPs, mostly | Your platform |
| Small regional lists | Varies | Often negligible. Only chase the ones that demonstrably affect delivery |
If the bounce names a list you don't recognise, the Spamhaus SBL, XBL, PBL, and DBL explainer breaks each one down in more depth.
Step 2: Stop sending. Now.
Every email sent from a listed domain digs the hole deeper — more spam-folder placements, more provider-side evidence that the listing is deserved, more complaint opportunities. Pause every campaign on the affected domain (and its mailboxes) before doing anything else.
If you're running an agency, this is also the moment to check whether other domains in the same workspace share infrastructure with the listed one — same IP pool, same tracking domain, same link domain. Blast radius is rarely just one domain.
Step 3: Find the root cause
Delisting without a root cause fix is a short vacation before re-listing. Work through the likely causes in order of frequency for cold senders:
Spam trap hits (the #1 cause). Purchased, scraped, or aged lists contain trap addresses that exist solely to catch senders with bad list hygiene. One pristine trap can trigger a Spamhaus listing. If you sent to a bought or unverified list recently, this is almost certainly your cause.
Complaint rate spike. Check Google Postmaster Tools for the domain. If complaints crossed 0.3%, the targeting or volume was wrong — see the Google & Yahoo requirements for the thresholds.
Volume behavior that looks like a takeover. A new or quiet domain that suddenly sends hundreds of emails a day matches the fingerprint of a compromised account. If you skipped or rushed warmup, or jumped volume past the safe daily limits, that's the cause.
Broken authentication. Missing or misaligned SPF/DKIM/DMARC doesn't blacklist you by itself, but it removes the identity signals that would otherwise vouch for you when other signals look marginal. Confirm all three pass with the 15-minute setup guide.
Compromised mailbox. Rare but real: an actually-hijacked mailbox on your domain sending genuine spam. Check the sent folders of every mailbox on the domain for mail you didn't send.
Step 4: Fix the cause, then request delisting
Only after the cause is fixed:
- Spamhaus — look the listing up at check.spamhaus.org and follow the removal flow it offers for that specific list. Be honest in the form. Spamhaus expects the request to say what caused the problem, what you did about it, when, and what you've changed to stop it recurring; a request that doesn't acknowledge a cause reads as spammer boilerplate.
- SURBL — surbl.org has a lookup and a delisting request form.
- Smaller lists — most expire on their own within days to weeks. Only chase removals on lists that demonstrably affect your delivery.
On timing: Spamhaus says an approved removal is processed immediately and should take a few minutes, though some users may lag up to 24 hours as the change propagates. Most DBL listings are also highly automated and expire on their own once the associated activity stops, which means for a genuinely one-off cause the fastest route is sometimes to fix it and wait rather than to file anything. What Spamhaus is equally clear about is that a domain re-lists if the behaviour resumes.
Why Spamhaus removal requests get rejected
Spamhaus states plainly that submitting a removal request doesn't guarantee removal. Most rejections are procedural rather than reputational, and they cluster around a short list:
- The cause isn't fixed. The big one. Spamhaus expects the underlying problem resolved before you ask, and the request to explain it. A blank "please remove me" on a domain still hitting traps goes nowhere.
- You're not the registered owner. Requests have to come from the registered owner of the listed domain or IP, or through the provider that controls it. SBL removals in particular have to be submitted by the ISP in charge of the listed IP, not by you.
- You used a free email address. Spamhaus won't process removals sent from Gmail, Hotmail, Yahoo or any other free or disposable domain, and the PBL removal system automatically invalidates them. Use an address on the domain or network you're asking about.
- You submitted through a VPN. The request is expected to come from an IP that can be associated with the listed resource. A VPN or proxy breaks that link.
- The host still fails the basics. For CSS listings the checker runs configuration tests first: a valid reverse DNS (PTR) record resolving to a fully qualified domain name, a HELO that matches that record, and forward-confirmed reverse DNS. Any red cross there and Spamhaus says the request is likely to be unsuccessful.
One more thing worth knowing, because it's the setup for a common scam: Spamhaus states there is never any charge or fee for removing a listing. Anyone selling you a paid Spamhaus delisting is charging you for something Spamhaus gives away. Spamhaus only charges for high-volume automated query access to its data feeds, which is a different product entirely.
Does delisting actually restore deliverability?
Not by itself, and this is the part that catches people out.
Delisting and reputation are two different systems. A blocklist is a yes/no answer a receiving server looks up at delivery time; once you're removed, the answer flips back within minutes. Sender reputation is the mailbox provider's own long-running record of how its users treat your mail, and it doesn't consult Spamhaus to decide what it thinks of you.
The proof is in Gmail's own error codes. Gmail rejects mail with 550 5.7.1 ... very low reputation of the sending domain and rate-limits with 421 4.7.28 Gmail has detected an unusual rate of unsolicited mail originating from your DKIM domain. Neither mentions a blocklist, because neither depends on one. You can be clean on every public list and still be refused on reputation alone.
So the honest sequence is: delisting is necessary, fast and free. Reputation recovery is separate, slow, and the actual reason your numbers stay flat for a few weeks after the listing clears. Google Postmaster Tools is the closest thing to a scoreboard while you wait — it shows the domain reputation Gmail is actually holding against you, which no blacklist checker can tell you.
Step 5: Re-warm before returning to full volume
Delisting restores your ability to deliver; it does not restore trust. The providers that filtered your mail during the listing remember the episode. Treat the domain as semi-cold:
| Week after delisting | Volume |
|---|---|
| 1 | ~25% of previous volume, best segments only |
| 2 | ~50%, watching placement daily |
| 3–4 | Back to full volume if placement is clean |
Keep a warmup baseline running underneath, prioritize your most engaged segments (replies are reputation gold), and verify every list twice.
When to retire the domain instead
Fix-and-recover is the default, but retire the domain when:
- It's been listed more than once. A domain that keeps earning listings has a structural problem, and each request you file is reviewed against a history that now includes the last one.
- The listing won't clear after a legitimate removal request and a clean cause fix.
- It's a young sending domain with no reputation worth saving — two weeks of history isn't worth four weeks of recovery.
If you retire it, let it rest — don't redirect it, don't reuse its mailboxes on a new domain immediately, and never migrate its lists to your primary domain without re-verification. Start the replacement domain from a proper warmup.
The real fix is catching it early
The uncomfortable reality: most blacklistings announce themselves days before the listing. The tells usually arrive together, and on one domain rather than all of them:
- Bounce messages that mention "blocked," "listed," or a Spamhaus or SURBL URL.
- Reply and open rates collapsing on one domain while your others hold steady.
- A bounce-rate spike that appears overnight rather than creeping.
Any one of those is a cue to run the lookup immediately, because a listing compounds every hour you keep sending into it. Solo senders with one domain sometimes catch this. Agencies running 15 client workspaces almost never do, because nobody is staring at per-domain bounce trends across 20 sending domains every morning.
ColdOps watches deliverability signals and blacklist status across every sending domain in your Instantly, Smartlead, and EmailBison workspaces and alerts you at the "bounce rates creeping" stage — when the fix is a paused list, not a Spamhaus removal request and a month of rebuilt trust.
Start with the diagnosis: run your sending domains through the free deliverability checker — blacklist status, SPF, DKIM, DMARC, and domain age in one pass.
Frequently asked
How do I know if my domain is blacklisted?
What does '550 5.7.1 blocked using zen.spamhaus.org' mean?
How long does it take to get delisted from Spamhaus?
Why was my Spamhaus removal request rejected?
Does delisting restore my deliverability?
Why did my domain get blacklisted?
Should I abandon a blacklisted domain or fix it?
Keep reading
Email Deliverability Monitoring Tools: What to Watch
What email deliverability monitoring tools track, the signals that matter, when manual checking breaks down and how to choose a tool that fits your sending setup.
ReadDeliverabilityShould you turn off open tracking in cold email?
Should you turn off open tracking in cold email? For most campaigns, yes. How the pixel costs placement, what you lose, and what to measure instead.
ReadDeliverabilityGoogle Retired Domain Reputation in Postmaster Tools
Google removed the Domain and IP Reputation dashboards in Postmaster Tools v2. Here is what replaced them, the arithmetic that decides whether your domains report at all, and what to watch instead.
Read