What is a DNSBL and how does it block my email?

A DNSBL (DNS blocklist, sometimes called an RBL or blacklist) is a list of sending IP addresses or domains published over DNS. Receiving mail servers query it before accepting a message. If your sending IP or domain is listed, the receiver can reject the message outright or file it as spam — and it happens at the receiver, so nothing in your app or your sending dashboard necessarily records a failure.

How do I check if my domain or IP is on a blocklist?

Query the blocklist zone directly over DNS: reverse the four octets of your sending IP, append the zone, and look up the A record. For example, to check 203.0.113.45 against zen.spamhaus.org, run dig +short 45.113.0.203.zen.spamhaus.org — an answer in the 127.0.0.x range means listed, and no answer means not listed. Check the zones your recipients actually consult rather than a long tail of obscure ones.

How do I get removed from a blocklist?

Fix the cause first, then request delisting through the list operator's own removal form. Delisting before the cause is fixed usually results in a faster re-listing with a longer penalty. If you send through a shared IP at an email provider, you generally cannot delist it yourself — that is the provider's job, and it is a strong argument for a dedicated sending identity once volume justifies it.

How often should I check blocklist status?

Continuously, because a listing can appear between two sends and the damage is done silently. An hourly check against the major zones is enough to catch a listing within an hour of it happening, which is usually well before enough customers notice to tell you.

Deliverability

Your mail stopped reaching people. Did a blocklist just decide that?

A DNS blocklist listing is the quietest outage you can have. Your app is fine, your sending provider reports no errors, your SPF and DKIM records are perfect — and receiving mail servers are refusing your messages before they reach a single inbox. Here is how to check whether your domain or sending IP is listed, what actually causes it, how delisting really works, and how to be told within the hour next time.

Start 14-day trial Copy the checklist

why it happens

The decision is made somewhere you can’t see.

Every other delivery problem leaves a trace on your side of the wire. A blocklist listing doesn’t: the receiving server queries a list over DNS, decides against you, and either rejects the message or files it away. Depending on how your provider handles the rejection, you may see nothing at all. And because listings are often triggered by something you didn’t do — a neighbour on a shared IP, a form of yours being abused, a list someone else imported into your account — the first signal is usually a customer saying “I never got it” days after it started. The value of watching blocklist status is simply that it turns a week of invisible damage into an alert.

the checklist

Six ways a domain or IP ends up listed

You share a sending IP with a bad neighbour

Symptom: Deliverability collapsed overnight and nothing about your own sending changed.

Fix: On a shared IP at a low-cost provider, another customer’s spam gets the whole range listed. Check the IP your provider actually sends from, then push the provider to delist — or move to a sending identity you control.

A form on your site is being used to send mail

Symptom: Volume from your domain jumped, complaints followed, and the listing came shortly after.

Fix: An unprotected contact or signup form that emails arbitrary addresses is a spam relay. Rate-limit it, add a challenge, and confirm it can’t put attacker-supplied content into an outbound message.

You imported a list and mailed it cold

Symptom: A campaign to a purchased or years-old list produced a bounce and complaint spike, then a listing.

Fix: Stop sending to the list, remove every address that bounced, and let the domain’s reputation recover before you send again. Spike-then-listing is the pattern these lists are built to catch.

A new domain sent too much, too soon

Symptom: A freshly registered domain started sending at volume and got listed within days.

Fix: New domains have no reputation, and sudden volume from one reads as a snowshoe pattern. Warm up gradually and keep early sends transactional and expected.

The listing is on the domain, not the IP

Symptom: Your sending IP checks clean everywhere, and mail is still being filtered.

Fix: Domain-based lists (DBL-style zones) list the domain in the message, including URLs in the body. Check the sending domain and any link-shortener or tracking domain you use, not only the IP.

You were delisted and listed again days later

Symptom: A removal request worked, then the listing came back with a longer wait.

Fix: The underlying cause was never fixed — usually a compromised form, a leaked credential on the sending account, or a list that keeps generating complaints. Find and fix that before requesting removal again.

copyable runbook

Paste this into your incident notes

DNSBL / blocklist triage

[ ] Find the IP your provider actually sends from (it is usually NOT
    your website's IP). Check a message's Received headers.
[ ] Query the zone with the octets reversed. An answer in 127.0.0.x
    means LISTED; no answer means not listed:
    dig +short 45.113.0.203.zen.spamhaus.org
[ ] Repeat for the other zones your recipients consult.
[ ] Check the DOMAIN too, not just the IP — domain lists catch URLs
    in the message body, including tracking and shortener domains.
[ ] Read the listing reason on the operator's lookup page.
[ ] Find the cause before requesting removal:
      - shared IP?        -> the provider must delist, not you
      - volume spike?     -> which campaign or list caused it
      - abused form?      -> rate-limit and challenge it now
      - leaked credential?-> rotate the sending API key
[ ] Fix the cause. THEN submit the operator's delisting request.
[ ] Re-check the zone after delisting, and keep checking hourly —
    a re-listing carries a longer penalty than the first one.

how to catch it automatically

An hourly check against the zones that matter

Nightlamp runs a dnsbl monitor against your sending IP or domain, querying a curated set of blocklist zones on a schedule — hourly by default. The moment a zone answers with a listing, you get told, with the zone that listed you and the reason it published. Paired with the dns_record checks watching your SPF, DKIM and DMARC records and an email_flow check proving a real message still reaches a real mailbox, it closes the gap between “our email works” and “our email is being delivered”. When something does list you, an engineer works out which cause fits the evidence and sends you the delisting order of operations rather than a link to a lookup tool.

Sending IP listing status

Domain listing status

Which zone listed you

Time listed vs. delisted

SPF / DKIM / DMARC intact

Real message still delivered

Know within the hour, not the week

Start a trial, tell us the domain or IP you send from, and Nightlamp checks it against the major blocklist zones every hour — then tells you what listed you, what most likely caused it, and the order to fix and delist in.

Start 14-day trial · no card

Newsletter

One real no-code incident + the fix, monthly

A post-mortem from a real no-code outage — what broke, how it was found, and the fix — once a month. Confirming also gets you the no-code incident runbook pack.

Double opt-in. One-click unsubscribe. No spam, ever.

DNS and deliverability

Confirmation emails stopped after a domain change

Go deeper

Nightlamp pattern

A listing and a suppressed recipient look identical from your side — mail that vanishes with no error. We check both, in that order, because the fix is completely different: one is a delisting request, the other is a single row on your provider’s suppression list.

Watching the SEO side too?

Blocklists and search engines both judge a domain on reputation, and both do it out of sight. Nightlamp watches deliverability and uptime; for rankings and index coverage, see VectraSEO.