A blocklist, also called a DNSBL or RBL, is a published set of IP addresses or domains associated with abuse. A receiving mail server queries it in the middle of the SMTP conversation and decides what to do with your connection based on the answer. Landing on one produces the most abrupt delivery failure in email: everything works, then nothing does, at whichever receivers consult that particular list.
How does a blocklist actually get used?
As a real-time lookup at several points in a delivery, not as a list someone reads.
Spamhaus, whose lists are the most widely queried, describes where a receiver should apply one:
- The initial connection – against the connecting IP.
- Throughout the pre-data phase of an email, i.e., the SMTP transaction - against the HELO string, and Mail From domain.
- Once the email data has been accepted - by looking up IP addresses hosting resources appearing in the mail headers and body e.g., URLs.
The third point is the one senders forget. A domain in a link inside your message can get the message filtered even when your sending IP is spotless, which is why a shortener or a compromised landing page can sink an otherwise clean campaign.
Which blocklists matter?
The ones your recipients' providers actually query, which is a much shorter list than the ones that exist.
Two operators account for most of the impact a normal sender will feel.
- Spamhaus publishes several IP lists that catch different things, including a blocklist of spam sources, an exploits list for compromised machines, and a policy list for address space that should not be sending mail directly. It also publishes a domain list. Its criterion is narrow and worth knowing: its definition of spam is "unsolicited bulk email" and it "does not evaluate the content or legality of the contents of an email message, merely whether that message constitutes spam by this definition."
- Barracuda publishes a reputation-based IP list used by its own filtering appliances and by others.
Dozens of smaller lists exist. Before spending a day on one, check whether any provider your recipients use consults it, because plenty are queried by almost nobody. The email header analyzer reports listings on the lists that matter for a domain and its IPs.
How do I get delisted?
Fix the cause, then ask, and expect the ask to be the easy part.
The order is not a formality. Every operator re-lists automatically when the behaviour continues, so a removal obtained before the fix buys hours. Barracuda states the constraint on repeated attempts directly:
Please note that the BRBL is generated by automated systems. Requests without valid information will be ignored. Multiple requests will also be ignored.
with a timescale once the request is sound:
Removal requests are typically investigated and processed within 12 hours of submission if provided with a valid explanation.
Spamhaus is structurally different, and this catches senders out. For its IP blocklist, the removal is not yours to request:
When a SBL listing is made, Spamhaus Project researchers send the network or hosting companies responsible for that IP an email notification. Due to the technical nature of these listings, only these companies can deal with SBL removals. If you are a general user, speak with your Internet Service Provider (ISP) to seek remediation.
It is the network owner's responsibility to notify Spamhaus of any changes that affect a SBL listing, and to request removal when the conditions that caused the SBL listing no longer apply.
If you send on shared infrastructure, that network owner is your sending platform, and the useful action is to open a support case with them rather than to fill in a form. If you have a dedicated IP the listing is about your traffic specifically, but the request still travels through whoever announces the address.
What actually caused it?
Almost always one of a handful of things, and the listing itself usually says which.
| Cause | What to change |
|---|---|
| Spam trap hits | Fix acquisition and hygiene, not the traps (why) |
| A compromised account or form | Close it, then rotate credentials and add a bot check on public forms |
| A sudden volume spike from a cold IP | Warm up gradually rather than resuming full volume |
| Bad reverse DNS on the sending IP | Fix the PTR record so it matches the hostname |
| A listed domain in your message body | Stop linking through shorteners and check your own landing pages |
Spamhaus publishes its own prevention checklist for network operators, and two entries on it are ordinary sender advice: use double opt-in "to avoid spam traps and ensure only real and interested recipients are sent your emails", and "ensure that your hostname and your HELO match, and that your reverse DNS (PTR record) is defined and pointing to the same hostname."
Should I be checking proactively?
Yes, and specifically as a symptom rather than as a score.
A blocklist entry is downstream of something else going wrong, so a monitoring alert on a listing is really an alert that a cause has been running unnoticed. Sender reputation monitoring covers where to watch, and if you are already filtered rather than blocked, why emails go to spam is the broader diagnosis. Do not treat delisting as the objective. It is the receipt for work you did somewhere else.