How to remove your IP from an email blacklist

What a blocklist is, and what a receiver actually does with one

A DNSBL, or DNS-based blocklist, is a DNS zone. That is the whole trick, and it is why the mechanism is so widely deployed: every mail server already has a DNS resolver, so consulting a list costs one lookup and no new software.

To ask whether an IPv4 address is listed, a receiver reverses the four octets, appends the list's zone name, and asks for an A record. RFC 5782 defines the convention: an answer inside 127.0.0.0/8 means the address is listed, and NXDOMAIN means it is not. A TXT record at the same name usually carries a human-readable reason and a URL. IPv6 works the same way with the address written out as 32 reversed nibbles.

The decision is the receiver's, not the list's. Lists publish data; each mail server operator decides which lists to consult and what to do with an answer. One receiver rejects at the SMTP connection, another adds points to a spam score, a third ignores the list entirely. This is the single most important thing to understand about a listing, because it is what determines whether a given listing matters to you at all.

Because the check happens at connection time, the failure is visible to your sender as an SMTP rejection rather than as a message that quietly went to spam. That bounce is the most useful diagnostic you have: it names the list, and usually links to the listing page.

RFC 5782 also requires every IPv4 list to contain an entry for 127.0.0.2 and to not contain one for 127.0.0.1. That pair is a self-test: if the first answers and the second does not, the zone is alive and is not wildcarding. If both answer, the list is returning a positive answer for everything and any result you get from it is meaningless.

# is 203.0.113.10 listed? reverse the octets, append the zone
dig +short 10.113.0.203.zen.spamhaus.org
dig +short TXT 10.113.0.203.zen.spamhaus.org

# a domain listing is queried without reversing anything
dig +short example.com.dbl.spamhaus.org

# the RFC 5782 self-test: the first MUST answer, the second MUST NOT
dig +short 2.0.0.127.zen.spamhaus.org
dig +short 1.0.0.127.zen.spamhaus.org

IP listings, domain listings and URI listings are three different things

They are queried the same way and people call all of them blacklists, but they key on different things, they are caused by different things, and different people have to fix them.

• An IP blocklist keys on the address that connected. It is about a machine and a network, not about your brand. Move your outbound mail to a clean address and the listing stops affecting you, which is why a listing can be inherited from whoever used that address before you.

• A domain reputation list, of which the Spamhaus DBL is the best known, keys on the domain name. It follows the name everywhere: changing hosts, changing mail providers and changing addresses do nothing. A domain listing usually means the domain is appearing in the body of spam, whether sent by you, sent by somebody forging you, or advertised through a compromised page on your own website.

• A URI list, of which SURBL, URIBL and the invaluement ivmURI list are examples, keys on the domains found in the body of a message rather than on the sender at all. Your mail can be caught by a URI listing because of a link shortener, a tracking domain, an image host or a customer's site you linked to. The listed domain is often not yours.

The DBL is queried by prepending the domain to the zone, with no reversing, and wildcards down: a listing on example.com covers its subdomains. Spamhaus documents DBL answers in the 127.0.1.x range, including 127.0.1.2 for a spam domain, 127.0.1.4 for phishing, 127.0.1.5 for malware and 127.0.1.6 for botnet command and control. An answer of 127.0.1.255 means you queried an IP address against a zone that only accepts domain names.

Our own blocklist check is an address check. It resolves your domain's mail server addresses, or takes a single address you give it, and queries the address lists we are licensed to query. Domain and URI lists are reported as not performed, with the reason stated: the free public feeds for Spamhaus DBL, SURBL and URIBL are licensed for non-commercial use only and we have not bought the commercial equivalents. That is a real gap in coverage and the check says so on every run rather than letting a narrow clean result read like a broad one.

Finding out which lists you are on

Start by working out which addresses actually send your mail, because that is the thing being listed and it is frequently not what people check. Your website's address is not it. Your MX records point at the servers that receive your mail, which on many setups are not the servers that send it. The reliable answer is in a message you have actually sent: open the full headers at the receiving end and read the Received line closest to the sender, which names the address your mail left from.

If you send only through a provider — Google Workspace, Microsoft 365, an email service provider — the sending addresses are theirs, they are shared with their other customers, and the listing, if any, is theirs to resolve. That is worth establishing before you spend a day on it.

Then check those addresses. Our blacklist checker queries the lists we can query and names both the ones it asked and the ones it did not. Spamhaus is the list most mail providers actually consult and we do not query it, for the licensing reason above, so check it yourself at check.spamhaus.org — the lookup is free and public, and if you only do one check, do that one.

Be sceptical of multi-list checkers that query a hundred zones and present the result as a count. A count treats a list one large provider consults and a list its own operator abandoned as equal, and the number it produces is almost entirely noise. What matters is which list, and who uses it.

A list that did not answer is not a clean result. A timeout, a SERVFAIL, or a refusal because the resolver you asked from is not registered with that list all look exactly like not listed if you are not careful, and reporting a silent list as clean is the most damaging thing a check of this kind can do. Our own check reports those separately for exactly that reason, and the pass beside them is explicitly scoped to the lists that answered.

One specific trap: Spamhaus's public mirrors refuse queries from large public resolvers. A query that arrives that way answers 127.255.255.254, and an address making too many queries gets 127.255.255.255. Both are in 127.0.0.0/8 and both look like listings to anything that just checks whether an answer came back. They are error codes, not reputation data. If you are querying by hand through a public resolver, this is what you will see.

Reading the return code

The answer is not a boolean. The last octet identifies which of the operator's sublists you landed on, and that determines what the listing means and what you should do about it.

Spamhaus's combined zone, zen, contains its address-based lists together and answers with one record per list you are on, so a single query can return several answers at once. Its documented codes include 127.0.0.2 for the Spamhaus Blocklist, the hand-maintained list of abuse-related resources; 127.0.0.3 for Combined Spam Sources, an entirely automated sublist of SMTP emitters associated with low reputation or confirmed abuse; and 127.0.0.10 and 127.0.0.11 for the Policy Blocklist, the two codes distinguishing a range entered by Spamhaus from one entered by the network's own ISP. The Exploits Blocklist has its own codes in the same range; we have not reproduced them here because we could not confirm the current values from Spamhaus's own documentation, so read them off the listing page rather than from a third-party table.

Every other operator uses its own code scheme, and RFC 5782 explicitly notes there is no widely used convention for mapping sublists to values. Do not carry a code from one list's documentation to another's.

Always fetch the TXT record as well as the A record. It is where the reason and the listing URL live, and on most lists it is the difference between knowing you are listed and knowing why.

$ dig +short 10.113.0.203.zen.spamhaus.org
127.0.0.3        -> Combined Spam Sources: automated, low-reputation SMTP emitter
127.0.0.10       -> Policy Blocklist: this range should not send mail directly

$ dig +short TXT 10.113.0.203.zen.spamhaus.org
"https://check.spamhaus.org/sbl/query/SBLxxxxxx"

# and the two you must not read as listings:
127.255.255.254  -> you queried through a public/open resolver
127.255.255.255  -> too many queries from your resolver

Some listings mean something entirely different from spam

This is the part most delisting advice skips, and it is the part that decides whether you should be requesting a delisting at all.

A Policy Blocklist listing is not an accusation. Spamhaus's own description of the PBL is that it detects end-user address ranges that should not be attempting to deliver unauthenticated SMTP mail directly to internet mail servers, and states plainly that the addresses in it are not necessarily bad — simply that they should never be sending email. Residential broadband, dynamic ranges and most consumer cloud allocations are in it by policy, and being in it is normal. If your mail is being rejected on a PBL listing and you are sending from a residential or dynamic address, the remedy is not delisting: it is to send through your provider's relay or a mail service, which is what the listing is telling you to do.

If you genuinely do run a legitimate mail server on a static address inside a PBL range, there is a self-service exclusion at check.spamhaus.org. As of September 2026 it requires the address to be static, to be configured as an outbound mail server, to have proper DNS, and to be assigned to you; single-address exclusions expire after a year and have to be renewed.

A Combined Spam Sources listing is also not a hand-made accusation. It is automated, it fires on the behaviour of the emitter rather than on a researcher's judgement, and it clears automatically once the behaviour stops — but it also relists automatically if it does not. A CSS listing usually means your sending pattern looks like a low-reputation emitter to a machine, which most often means complaint rates or mail to addresses that never opted in.

There is also an ordering rule worth knowing: Spamhaus processes removals in a required order, and a CSS, Exploits or Policy listing cannot be dealt with while a Spamhaus Blocklist listing on the same address is outstanding. The reputation checker shows the listings in the order they have to be cleared.

Finally, some operators list by network rather than by behaviour. UCEPROTECT levels 2 and 3 list an entire allocation or an entire autonomous system because of what other customers of that network did. Nothing you configured caused it and nothing you can configure clears it. Our own scan shows a UCEPROTECT listing because it is real and worth knowing about, and gives it zero score weight, because letting a neighbour's behaviour cap your grade would tell you something untrue about your own domain.

Fix the cause before you request delisting

Almost every operator relists faster the second time, and several deny automatic removal to addresses that have been removed repeatedly so a human can talk to you first. Requesting removal before the cause is fixed is therefore worse than doing nothing.

Four causes account for nearly all address listings.

• A compromised mailbox or a compromised web script. Look for outbound volume you did not send: the mail queue, the outbound log, and the authentication log for a mailbox signing in from somewhere it should not. A contact form or an old content management system that can be made to send mail is the usual web-side culprit.

• An open relay. Test it rather than assuming; the command is below. This one is uncommon on modern software and catastrophic when present.

• Mail sent to addresses that never opted in. This produces complaint-driven and spam-trap-driven listings, and it is the one that has no technical fix. The cause is the list, not the server.

• A shared address whose neighbour is the actual sender. On shared hosting or a small cloud provider, establish whether the address is yours alone before you spend time on your own configuration.

Reverse DNS is not itself a listing cause, but it is closely associated with one. An address with no PTR record, or with a PTR that does not resolve back to the same address, is treated by many receivers as an unmanaged host, and it is a hard requirement at Google for every sender regardless of volume. Fixing it will not lift a listing, but leaving it broken is part of why the address attracted attention. The reverse zone belongs to whoever holds the address block, not to your DNS host, so this is a request to your hosting provider or ISP.

openssl s_client -starttls smtp -connect mail.example.com:25 -servername mail.example.com

EHLO test.example.net
MAIL FROM:<nobody@example.test>
RCPT TO:<someone@example.org>

# a correctly configured server answers here with something like
#   554 5.7.1 <someone@example.org>: Relay access denied
# a 250 means you are relaying for anyone: stop and fix that before
# you do anything else, including requesting a delisting
QUIT

The delisting process, operator by operator

Read from each operator's own site on 2026-09-17. These processes drift, so treat the detail as a dated snapshot and the shape as the durable part.

• Spamhaus. Everything now runs through the reputation checker at check.spamhaus.org, which replaced the old Blocklist Removal Center; Spamhaus announced that change in March 2021. Look the address up, and the tool shows every listing, in the order they must be cleared, with the removal path for each. Spamhaus Blocklist entries generally need your network's abuse desk to make the request, because the listing is usually about the network rather than about you alone. CSS and PBL listings have self-service paths. Where a removal cannot be processed immediately the tool raises a ticket with the delisting team rather than silently failing. Removal is free, always, and re-listing is automatic if the behaviour resumes.

• Barracuda. The Barracuda Reputation Block List has a removal form at barracudacentral.org/rbl/removal-request taking the address, your email address, a phone number and an optional reason. Requests are reviewed by a person. That form is the only route; there is no other channel and no expedited one.

• SpamCop. The SpamCop Blocking List is largely self-clearing. Its own documentation says that without further reports a listed address stays on the list for only 24 hours, and that reports about mail older than a week are ignored. If you are listed repeatedly the answer is not a removal request, it is that reports are still arriving, and the source is what needs attention.

• UCEPROTECT. Level 1 lists an address, level 2 an allocation and level 3 an entire autonomous system. Its own policy says a level 3 entry is removed automatically once the provider stops matching the level 3 criteria, and that until a provider implements the steps it asks for, the only removal it offers is on a payment basis. Read that clearly: the operator itself sells removal from its own list. It is one reason many receivers do not consult levels 2 and 3, and it is the reason our own scan carries a UCEPROTECT result at zero weight.

• invaluement. Its ivmSIP, ivmSIP/24 and ivmURI lists are consulted by a number of receivers and have a free removal request form on invaluement.com. We could not retrieve that page directly when checking this guide — the site returned an HTTP 403 to our request — so we are not describing the form's fields; go to the site and start from the listing page.

• SORBS. Gone. Proofpoint, which owned it, shut it down in June 2024. If a multi-list checker still shows a SORBS zone answering for your address, treat the result as meaningless: an abandoned zone that has been re-pointed or that wildcards is worse than one that answers nothing at all, and there is nobody to delist you.

Whatever the operator, the request itself should be short and specific: what the address is, what was wrong, what you changed, and when. A request that says the listing must be a mistake, with no account of what was fixed, is the one that gets queued.

When the listing is on a list nobody uses

It is worth saying plainly, because most delisting advice will not: a listing on a low-quality list can be safe to ignore, and chasing every listing a hundred-zone checker reports is a poor use of a day.

Five questions tell you which kind you are looking at.

• Does the list publish its listing and delisting criteria, and do those criteria describe behaviour by the address rather than membership of a network? A list that lists whole allocations to apply pressure to a network operator is telling you about your provider, not about you.

• Did a bounce you actually received name this list? That is direct evidence that a receiver you care about consults it, and it outweighs every other consideration here. No bounce naming it, across any provider your recipients use, is meaningful evidence in the other direction.

• Is there a removal path that does not involve payment, and does it complete in hours or days rather than weeks?

• Does your own sending data show anything? A listing that coincides with a measurable drop in delivery or acceptance at a specific provider is real. One that coincides with nothing usually is.

• Is the list still alive? Check when its own site was last updated and whether its self-test entries behave as RFC 5782 requires.

If the answers are all negative, write the listing down with the date and move on. The test that settles any remaining doubt is empirical: send a message to a mailbox you control at each provider that matters to you, and read where it lands and what the headers say. A listing that changes nothing about that result is a listing that changes nothing.

Why paying a removal service is not a thing

Search for any list's name and you will find services offering to get you delisted for a fee, often with a same-day guarantee. They cannot do anything you cannot do, and the operators say so themselves.

Spamhaus states in as many words that there is never any charge or fee associated with removing any Spamhaus listing, and that any offer from anyone to remove a Spamhaus listing for a fee is a scam. It goes further: it has no affiliation with anyone offering a blocklist removal service, and no third party can influence or expedite a removal from any of its databases. Barracuda's position is the same in practice — its own form is the only route, and third parties charging for instant delisting are not affiliated with it.

The reason a paid service cannot help is structural. Delisting is a form submission that takes two minutes and is free. What actually determines whether the listing comes back is the cause — the compromised account, the open relay, the list you should not have been mailing — and no external service has access to your mail server, your logs or your subscriber list.

There is one genuine exception, and it is not a third-party agency: UCEPROTECT sells removal from its own lists, as described above. That is the list operator charging for its own product. It is legal, it is disclosed on their own site, and it is precisely why a UCEPROTECT listing carries so little weight with receivers and with us.

Verifying the removal, and staying off

Query the zone directly rather than trusting the confirmation page. The removal is real when the query returns NXDOMAIN, and the TXT record is gone with it.

Allow for caching in both directions. Your own resolver may hold the previous answer for the zone's TTL, and so will the receivers who were rejecting you; most lists clear within minutes but a day is a reasonable window before concluding that a removal did not take.

Then send a real message to a mailbox you control at each provider that matters, and read the full headers at the receiving end. Delivery to the inbox with clean authentication results is the outcome you were after; the DNS query only tells you the list changed its mind.

Finally, close the gaps that made the listing possible or plausible. Forward-confirmed reverse DNS on every address you send from. An SPF record that authorises your senders and nothing wider. DKIM signing on every sending system. DMARC at quarantine or reject, with aggregate reporting on, so that mail forged as your domain shows up in a report instead of in a listing. Our domain health check runs all of those in one pass, which is a faster way to confirm the supporting configuration than checking each one separately.

Then check on a schedule rather than when somebody complains. A listing caught in its first day is a traceable incident; one caught three weeks later is an archaeology project.

What commonly goes wrong

• Requesting delisting before finding the cause. The listing returns within days, and several operators lengthen the cooling-off period or withdraw automatic removal for repeat requests, so the second delisting is harder than the first.

• Checking the wrong address. The website's address and the MX addresses are frequently not the address your outbound mail leaves from, so a clean result can be a clean result about a machine that sends nothing.

• Treating a Policy Blocklist entry as an accusation and requesting removal. A PBL listing on a residential or dynamic address is correct and is telling you to relay through a provider; the removal request will be refused and the mail will keep bouncing.

• Reading 127.255.255.254 as a listing. It means your query arrived through a public resolver and was refused, which is the opposite of a result. Anything that checks only whether an answer came back will report it as listed.

• Treating a silent list as a clean list. A timeout or a SERVFAIL is not evidence of anything, and a tool that converts it into a green tick is why people believe they are not listed when they are.

• Paying for a removal service. It submits the same free form you can, cannot touch the cause, and in Spamhaus's own words any offer to remove one of its listings for a fee is a scam.

• Fixing the listing and leaving the authentication alone. The listing was a symptom of how your mail looks to receivers; without reverse DNS, SPF, DKIM and an enforcing DMARC policy, the next one is a matter of time.