Email Security8 min read

"Blocked using Spamhaus" — Causes & Fix

A receiving server refused your message because your sending IP is on Spamhaus or another blacklist (RBL/DNSBL). Here is how to find which list, fix the cause, and request delisting.

A rejection like "blocked using Spamhaus" means the receiving mail server looked up your sending IP address in a blacklist (an RBL/DNSBL such as Spamhaus, Barracuda, or SpamCop), found it listed, and refused the connection before your message was even accepted. It is a reputation block, not an authentication one — SPF, DKIM, and DMARC are irrelevant if the IP itself is on a blocklist. The fix has three parts: find which list has you, fix the reason you were listed, then request delisting.

What the Error Looks Like

The bounce names the blacklist and usually links to a lookup page for the offending IP. Different receivers and different RBLs word it differently, but they all mean the same thing:

text
# Spamhaus (via a receiver that queries ZEN) 550 5.7.1 Service unavailable; Client host [203.0.113.9] blocked using Spamhaus; https://www.spamhaus.org/query/ip/203.0.113.9 # Explicit zone reference 554 5.7.1 Rejected because 203.0.113.9 is in a black list at zen.spamhaus.org # Other common RBLs 550 5.7.1 Mail from 203.0.113.9 refused - see http://www.barracudacentral.org/rbl 550 5.7.1 Blocked - see https://www.spamcop.net/bl.shtml?203.0.113.9

The IP in brackets is the one that matters — it is the server that actually made the SMTP connection. For a self-hosted mail server that is your own IP; if you send through a provider or relay, it is their outbound IP, which changes who has to fix it.

Check the IP against Spamhaus and other RBLs

How Blacklist Blocking Works

An RBL (Realtime Blackhole List), also called a DNSBL, is a list of IPs published over DNS. When a receiving server accepts a connection from 203.0.113.9, it reverses the octets and queries a special zone — if an answer comes back, the IP is listed:

bash
# The receiver reverses the IP and appends the RBL zone # 203.0.113.9 -> 9.113.0.203 + .zen.spamhaus.org dig +short 9.113.0.203.zen.spamhaus.org # An answer like 127.0.0.4 means "listed"; NXDOMAIN means "not listed" # The TXT record explains why and links to the removal page dig +short 9.113.0.203.zen.spamhaus.org TXT

Because this happens at connection time, the block is independent of your message content or your authentication records. A perfectly configured domain still gets rejected if its sending IP is listed.

Why It Happens

1. A compromised account or device sent spam

The most common cause. A phished mailbox, a hacked web app with a contact form, or a malware-infected machine on your network sent bulk spam through your server, and the IP earned a listing.

2. Poor sending practices tripped a spam trap

Mailing to purchased or stale lists, high bounce rates, spammy content, or a sudden volume spike from a new IP (no warm-up) all damage reputation. Hitting a spam trap address — one that only exists to catch senders who do not clean their lists — is a fast route onto Spamhaus.

3. You are on shared or dynamic IP space

On shared hosting or a residential/dynamic IP, a neighbor's bad behavior can get the whole range listed. Spamhaus PBL specifically lists dynamic and end-user IP ranges that should not be sending mail directly.

4. Missing reverse DNS or a generic PTR

Many receivers penalize or block IPs with no reverse DNS (PTR) or a generic-looking one (e.g. 203-0-113-9.dynamic.isp.net). It is not a blacklist per se, but it produces the same "client host rejected" result and often accompanies a listing.

5. An open relay or misconfigured server

A server that relays mail for anyone, or one leaking through a proxy or open port, gets discovered and listed quickly. This is the reason Spamhaus XBL/CBL exists.

Find the right IP firstIf you send through Google Workspace, Microsoft 365, SendGrid, Mailgun, or any relay, the listed IP is usually theirs, not yours — and shared-pool reputation is the provider's job to manage. Confirm the bracketed IP in the bounce before spending time on your own DNS. Only self-hosted senders delist their own IP.

How to Diagnose It

Pull the exact IP from the bounce, then check it against the major lists and read the reason each one gives. Spamhaus ZEN combines SBL, XBL, and PBL, so it is the single most useful zone to query:

bash
# Is the IP listed on Spamhaus ZEN? (127.0.0.x = listed) dig +short 9.113.0.203.zen.spamhaus.org # Why? The TXT gives the reason and the removal URL dig +short 9.113.0.203.zen.spamhaus.org TXT # Confirm reverse DNS resolves to a real hostname on your domain dig +short -x 203.0.113.9
Scan every major RBL at onceThe Blacklist Checker queries dozens of RBLs so you see every list your IP or domain is on.
Check blacklists now

How to Fix It

Delisting without fixing the cause gets you re-listed within hours. Work in order: stop the source, close the configuration gaps, then request removal.

Fix A — Stop the source of the abuse

Find and shut down whatever generated the spam: reset credentials for any compromised mailbox, patch or lock down a hijacked web form or CMS, scan machines on your network for malware, and check your outbound queue for a backlog of unfamiliar mail. Nothing else matters until the source is stopped.

Fix B — Close the configuration gaps

Make the IP look like a legitimate sender so it is not immediately re-flagged:

  • Set a proper reverse DNS (PTR) record that resolves to a real hostname on your domain, and make sure that hostname has a matching forward A record.
  • Publish and align SPF, DKIM, and DMARC so receivers can authenticate your mail.
  • Ensure the server is not an open relay and only accepts authenticated submission.
  • Remove stale addresses from your lists and fix anything causing high bounce rates.

Fix C — Request delisting from each RBL

Once the cause is fixed, use each list's removal form (the URL is in the bounce and the TXT record). Be honest about what happened and what you changed — reviewers look for evidence the problem is resolved:

text
Spamhaus (SBL/XBL/PBL): https://www.spamhaus.org/lookup/ Barracuda: https://www.barracudacentral.org/rbl/removal-request SpamCop: https://www.spamcop.net/bl.shtml # Paste the IP, follow the zone-specific removal steps, and wait for propagation.
Never request delisting before fixing the causeMost RBLs let you self-remove once, then re-list you fast — and repeatedly delisting a still-abusive IP escalates to a harder-to-remove listing. Confirm the spam has stopped and your queue is clean before you submit the removal.

Fix D — If you cannot fix the IP, change it

On shared/dynamic space or an IP with a poisoned history, the pragmatic fix is to send from a clean one: move to a reputable email provider or a dedicated IP you can warm up properly. This sidesteps a shared listing you have no control over.

Verify the Fix

Confirm the IP is clean before you resume sendingRe-scan the RBLs — every major list should return "not listed" before you send volume again.
Re-check blacklists

Delisting is not instant — RBL DNS zones cache, so allow time for the removal to propagate. Confirm the query now returns NXDOMAIN (not listed) and that reverse DNS resolves, then send a small test before resuming normal volume:

bash
# Should now be NXDOMAIN / empty (not listed) dig +short 9.113.0.203.zen.spamhaus.org # Reverse DNS resolves to a real hostname on your domain dig +short -x 203.0.113.9 # Send a low-volume test and watch for a clean 250 acceptance, not a 5xx block

Then ramp volume gradually. A sudden spike right after delisting looks exactly like the behavior that got you listed. If mail is landing in spam rather than bouncing, that is a separate deliverability problem — see why emails go to spam.

Frequently Asked Questions

My SPF, DKIM, and DMARC all pass — why am I still blocked?

Because a blacklist block happens at the IP/connection layer, before authentication is even considered. Passing SPF/DKIM/DMARC proves who you are; it does not clear a bad reputation on the sending IP. You must get the IP delisted.

How long does Spamhaus delisting take?

Once you submit a valid removal and the cause is fixed, removal is often processed within hours, but RBL DNS zones cache, so receivers may keep rejecting until the change propagates. Wait for the lookup to show "not listed" before resuming volume.

The listed IP is not mine — it is my email provider's. What do I do?

Then it is a shared-pool reputation issue on the provider's side. Open a support ticket with them; you generally cannot delist an IP you do not control. Persistent problems are a reason to move to a provider with better pool hygiene or a dedicated IP.

Will fixing reverse DNS get me delisted?

Not by itself — PTR is one factor receivers weigh, not a blacklist. But a correct PTR is often required before a delisting request is accepted and helps prevent re-listing, so fix it as part of the cleanup.

I got delisted but keep landing on the list again — why?

The source of the abuse was not actually stopped, or a spam trap is still being hit. Audit your outbound queue, rotate all credentials, verify no web form or app is being abused, and clean your lists before requesting removal again.

Related