A blocklist (or "blacklist" in older terminology) listing means a third-party reputation service has flagged your domain or sending IP as a spam or abuse source, and mailbox providers that consult that list may reject or filter your mail as a result. Not every list carries equal weight - some are consulted widely, others barely matter - but the process to get delisted is similar across the ones that do.
Step 1: confirm you're actually listed, and where
Check your sending domain and IP against the lists that are actually consulted by major mailbox providers. Spamhaus remains one of the most widely consulted. Validity launched its Heatwave domain blocklist on 3 September 2026, checkable at lookup.validity.tools, with delisting requests submitted through its /delist path. Note that SORBS, once commonly checked, was shut down by Proofpoint in June 2024 - don't waste time investigating a SORBS listing or trying to delist from it; it no longer operates.
$ dig +short yourdomain.com.dbl.spamhaus.org 127.0.1.2
A response in the 127.0.1.x range confirms a listing on Spamhaus's domain blocklist (the DBL); no response means you're not listed there.
Step 2: find the actual cause before requesting removal
Delisting requests that don't address the underlying cause are routinely rejected, and a domain that gets delisted without fixing the cause typically relists within days. Common causes, in rough order of frequency:
| Cause | How to confirm |
|---|---|
| Spam-trap hits | Check recent list-growth sources; purchased or scraped lists are the usual source |
| Compromised sending credentials | Review SMTP/API logs for sending volume or patterns you don't recognize |
| Sudden volume spike with no warm-up | Compare the listing date against your sending-volume history |
| Complaint rate spike | Check ESP complaint data around the listing date |
| Shared infrastructure abuse | If on a shared IP, check whether other tenants on that IP caused the listing |
Step 3: fix it, then request removal
- Remove the cause identified above - suppress the list segment responsible, rotate a compromised credential, or pause sending from the affected source entirely.
- Wait a short period (list-specific, often 24-72 hours) with clean sending behavior before requesting removal, so the request isn't submitted mid-problem.
- Submit the delisting request through the list's own process - most have a web form; follow their specific instructions rather than emailing generically, since most delisting teams only act on requests through the designated channel.
- Monitor for relisting over the following weeks - a cause that wasn't fully addressed often resurfaces.
What not to do
- Don't request delisting before identifying and fixing the cause - most delisting teams can see sending patterns on their end and will reject a request with no corresponding change in behavior.
- Don't assume every list matters equally - focus effort on lists actually consulted by the mailbox providers your recipients use, rather than chasing every obscure list that shows a listing.
- Don't check SORBS or spend time on a "SORBS listing" - the service was shut down in June 2024 and no longer affects filtering anywhere.
- Don't keep sending at full volume from the listed domain or IP while the delisting request is pending - continued sending during an active listing compounds the reputation damage.
A worked example: tracing a listing back to its cause
A SaaS company's marketing domain gets flagged on Spamhaus's DBL on a Tuesday morning - the first anyone notices is a support ticket from a prospect saying their email "bounced as blocked." Running the dig check above confirms the listing. Working through step 2's cause table: authentication hasn't changed, there's no sudden volume spike, and SMTP logs show nothing unusual - but ESP complaint data shows a visible jump in complaints starting four days earlier, tracing to a single campaign sent to a list segment tagged "trade show 2026," which turns out to be a badge-scan list from an event, never actually opted into marketing email.
That one send is the cause: badge-scan data from a trade show captures a business card exchange, not email consent, and mailing that list at the company's full regular volume produced enough complaints and at least one spam-trap hit (an address on the badge list that was itself a trap, since trade-show lists are a known vector) to trigger the listing. The fix is specific - suppress the entire trade-show segment going forward, since there's no reliable way to separate the genuinely-interested badge scans from the traps and never-interacted addresses within it - and the company waits 48 hours of clean sending from its other, properly-consented segments before submitting the Spamhaus delisting request. The request is approved within a day, because Spamhaus's own visibility into the domain's sending pattern during that 48-hour window shows the behavior that caused the listing has actually stopped, not just that a form was submitted.
How long delisting actually takes, by list
| List | Typical turnaround after a valid fix | Notes |
|---|---|---|
| Spamhaus DBL/SBL | Hours to 1-2 days | Fast once the cause is genuinely fixed; automated relisting if it isn't |
| Validity Heatwave | Days, via the /delist path at lookup.validity.tools | Newer list (launched September 2026); process still maturing |
| Microsoft SNDS/JMRP feedback | No formal "delisting" - reputation recovers gradually with clean sending | Treat as a reputation-recovery timeline, not a discrete listing to clear |
MailPilot tracks per-mailbox reputation daily, which surfaces the kind of complaint or bounce spike that precedes a blocklist listing early enough to act before it happens - and once a cause is fixed, continued reputation tracking confirms the fix is holding rather than just assuming a delisting request solved it.
Ready to reach the inbox every time?
Automated email warmup across real peer mailboxes. Live inbox placement monitoring. Free 7-day trial - no credit card required.
Start free trial