DroneBL delisting: why entries do not expire and what removal requires

DroneBL tracks IP addresses associated with compromised machines: botnet members, open proxies, open relays, and hosts seen participating in attacks. It grew out of the IRC network world, where drone and proxy abuse was the immediate problem, and it is still actively maintained. Unlike report-driven mail blocklists, DroneBL entries do not expire on their own — the project's position is that most listed problems stay unfixed for years, so active entries require a removal request.

That single design decision changes how you should treat a listing. It will not clear by waiting.

What DroneBL means for email

DroneBL is used by IRC networks, some mail servers and various network operators. For email specifically its direct reach is modest compared with Spamhaus or Barracuda. Its diagnostic value is high: the listing categories describe active compromise, so a DroneBL entry against your sending IP is evidence that something on that address was behaving as an exploited host. That is a security incident first and a deliverability problem second.

If your mail goes out through Google Workspace, Microsoft 365, SES, SendGrid, Mailgun or Postmark, the sending IP is the provider's and a DroneBL listing against your office or server address is not what is affecting your campaigns — but it still means a machine on your network needs attention.

Check from the affected address

dig +short 9.113.0.203.dnsbl.dronebl.org      # reversed octets
dig +short -t txt 9.113.0.203.dnsbl.dronebl.org

DroneBL's web lookup pre-fills the IP you are browsing from, which is convenient if you are on the affected network and misleading if you are not. If you are checking someone else's address, get the real IP first and type it in deliberately. The lookup result includes the listing type and the date, both of which you need for the removal request.

Read the listing type before you act

DroneBL's A-record answer is a type code, not a generic "listed" flag, and the TXT record spells out what it means. The codes that come up most often for mail-adjacent incidents:

Note that on DroneBL, unlike most DNSBLs, 127.0.0.1 is a genuine listing class, not the standard RFC 5782 test entry — so do not read a 127.0.0.1 answer as "the zone is just confirming it's alive."

Remediate before you request

A removal request that arrives before the host is cleaned will be refused or will simply be followed by a relisting. In order:

1. Identify the host behind the IP. With NAT, one public address can hide dozens of machines. Check outbound connection logs at the firewall to find which internal host generated the traffic in the listing's category.
2. Take it off the network or restrict its outbound traffic while you work.
3. Remove the malware or close the proxy. For a server, that usually means an exploited web application, an unauthenticated service exposed to the internet, or a legitimate proxy that was configured without access control. Open SOCKS and HTTP proxies are a common listing cause and are a configuration error, not an infection.
4. Patch and rotate. Operating system and application patches, then every credential that host held: SMTP, SSH, database, API keys.
5. Look for persistence. A second backdoor is normal. Rebuilding from a known-good image is usually faster and more trustworthy than cleaning in place.
6. Verify from outside. Scan your own address range for exposed proxy and relay ports, and confirm outbound attack traffic has stopped.

Submitting the removal

Use DroneBL's removal form, for an address you are actually responsible for. Reference the specific entry, state the listing type, and describe concretely what was found and what you did — "exploited WordPress instance on 203.0.113.9 removed, host rebuilt, credentials rotated, outbound filtering added" is the kind of detail that gets a request approved. Manual review takes a day or two in normal circumstances. Removal requests for addresses you do not control will be rejected, which is the correct behaviour.

What not to do

• Do not request removal first and investigate afterwards. DroneBL is reviewed by humans who deal with recurring offenders.
• Do not clean one symptom. A single removed file on a compromised server is not remediation.
• Do not leave an open proxy running "because internal tools use it". Bind it to the internal interface, require authentication, or shut it down.
• Do not treat a DroneBL listing as merely a deliverability problem. The likely cause is that someone else is using your infrastructure.
• Do not assume the listing is the worst consequence. A compromised host that can send mail will also have produced Spamhaus XBL exposure, complaints and possibly data loss.

After delisting

Expect the listing to clear within a few days of approval, and expect reputation at the big receivers to lag behind it. If the compromised host sent mail, reduce sending volume temporarily, send first to recipients who reliably engage, and rebuild over a week or two rather than resuming where you left off.

MailPilot warms mailboxes at a controlled pace and measures per-provider inbox placement daily, with SPF, DKIM and DMARC checks on your sending domains — which is what tells you whether delivery has genuinely recovered after a security incident, rather than only that a DNS entry disappeared.