Checking and Delisting Your Mail Server from DNSBLs

When mail that delivered fine yesterday suddenly starts bouncing with 554 5.7.1 Service unavailable; client host blocked, the most likely explanation is that your sending IP has landed on a DNSBL — a DNS-based blocklist. Nearly every large receiver (Gmail, Outlook, corporate gateways) queries the connecting IP against lists like Spamhaus and Barracuda the moment the SMTP session opens. If the IP is listed, the mail is rejected before the content is ever read — no amount of well-crafted copy will get it through.

This guide follows the order you should actually work in: ① confirm which lists you are on with a DNSBL lookup, ② find and fix the root cause first, ③ request delisting per list, and ④ prevent a repeat with SPF/DKIM/DMARC and monitoring. Step ② is the one people skip — and skipping it means you get relisted within days, at which point operators treat your IP as a repeat offender and delisting becomes much harder.

What a DNSBL is and how receivers use it

A DNSBL (DNS-based Blackhole List) is a database of IP addresses with spam history, published so that it can be queried over ordinary DNS. A receiving server reverses the octets of the connecting IP and prepends them to the list's zone: to check whether 203.0.113.25 is on Spamhaus ZEN, it looks up the A record for 25.113.0.203.zen.spamhaus.org. Any answer in the 127.0.0.xrange means "listed", and the mail is rejected or heavily penalized.

Typical symptoms that point at a listing:

• Bounce messages carrying 554 5.7.1 or 550 5.7.606 together with text like listed at zen.spamhaus.org or Blocked using Barracuda — the bounce often names the exact list, so read it carefully.
• Bounces only from certain destinations (say, Outlook domains) while others deliver — you are on a list only that receiver consults.
• No bounces, but mail lands straight in spam — score-based filters such as SpamAssassin add points for DNSBL hits instead of rejecting outright.
• It happened without any change in your legitimate volume — a strong hint that something is sending mail you don't know about (compromised account, abused web form).

Step 1 — Check every major list at once

Dozens of DNSBLs exist, with very different listing criteria and real-world impact, so start by checking your sending IP against all the major ones in one pass. Drop the server's public IP into the DNSBL blacklist checker and note two things:

1. Which lists you are on. A hit on Spamhaus ZEN or Barracuda matters enormously; a hit on an obscure hobby list that almost no receiver queries may not be worth chasing at all.
2. The return code, which encodes the reason. On Spamhaus, 127.0.0.4-7 (XBL) means malware or a compromised account is sending from your IP; 127.0.0.2-3 (SBL) is a manual spam-source listing; 127.0.0.10-11 (PBL) means the IP sits in a range that is not supposed to send mail directly at all — a policy statement, not a spam accusation.

If you are unsure which IP your mail actually leaves from (NAT, cloud egress), send yourself a test message and read the IP in the last Received: header — that is the address receivers see and score.

Step 2 — Fix the root cause before you ask for delisting

List operators track relistings. An IP that gets delisted and then trips a spam trap again days later is flagged as a repeat offender, and subsequent removal requests face far more scrutiny. Work through these causes and eliminate yours before touching any removal form:

• Compromised account / leaked credentials — the single most common cause. Check auth logs for successful logins from unusual countries or hours and for one mailbox suddenly sending thousands of messages. Reset the password, purge the outbound queue, force re-authentication.
• Abused web forms or CMS — contact forms without CAPTCHA, vulnerable WordPress plugins, anything that turns your site into a free mail cannon. Look for POST spikes in web logs; add CAPTCHA and rate limits, remove the vulnerable component.
• Open relay — a server that relays external-to-external mail without authentication. On Postfix, confirm smtpd_relay_restrictions includes reject_unauth_destination.
• Missing or mismatched PTR (reverse DNS)— an IP with no PTR, or a PTR that doesn't match your HELO name, is penalized on its own and is a listing criterion for some lists. Verify yours with the reverse DNS lookup; if it's missing, set it in your hosting/VPS provider's panel(PTR records belong to the IP owner, not your domain's DNS zone) to a hostname like mail.example.com.
• Spam traps in your list — ancient address books and purchased lists contain trap addresses maintained by blocklist operators. Remove hard bounces immediately, stop mailing bought lists, switch to double opt-in.
• A bad neighbor on a shared IP— on shared hosting or a shared sending pool, someone else's spam can get the whole IP listed. Report it to your provider; the durable fix is a dedicated IP or a reputable sending service.

Step 3 — Delist, list by list

Once the cause is gone, request removal. Procedures differ: some lists offer instant self-service, some simply expire entries after a quiet period, and a few dangle "pay to remove instantly" offers.

Worked example — a VPS IP on Spamhaus XBL after a credential compromise. Gmail recipients start returning 554 5.7.1 ... listed at zen.spamhaus.org. ① A DNSBL check shows the ZEN answer 127.0.0.4— XBL, meaning "malware or hijacked account traffic from this IP". ② The SMTP auth log reveals a foreign IP logging into a staff mailbox at 3 a.m. and pumping out tens of thousands of messages. You reset that password, delete ~30,000 queued spam messages, force re-auth for all users, and enable two-factor on the abused account. ③ With the phishing entry point closed, you submit the XBL removal on the Spamhaus lookup page — it clears within minutes. ④ For the next 24 hours you watch the outbound queue and re-run the DNSBL check to confirm you stay clean. Had you delisted first and investigated later, the bot would have resumed sending and the relisting would have been near-instant.

Step 4 — Stay off the lists: authentication and monitoring

Delisting is the beginning, not the end. To keep the IP clean, harden the whole sending setup:

• Align SPF, DKIM, and DMARC — domain authentication reduces your dependence on raw IP reputation and stops forged mail from poisoning it.
• Match PTR ↔ HELO ↔ sending domain — receivers treat the trio agreeing as the mark of a real mail server.
• List hygiene — suppress hard bounces automatically, honor unsubscribes instantly, warm up any new IP gradually.
• Routine checks — re-run a DNSBL scan at least weekly and watch reputation dashboards such as Google Postmaster Tools.

To verify that SPF, DKIM, DMARC and PTR are all in place for your domain in one pass, run the email deliverability check right after delisting and fix whatever it still flags — that is what keeps this from happening again.