IP blacklist check

How a blacklist check actually works

A DNS blocklist is not a database you query with a special protocol. It is an ordinary DNS zone, and that is the whole trick. To ask whether 198.51.100.7 is listed, you reverse the octets, append the zone name, and ask for an A record:

7.100.51.198.zen.spamhaus.org

An answer in the 127.0.0.0/8 range means the address is listed. NXDOMAIN — no such name — means it is not. That is the entire protocol, and it explains why blocklists became universal: every mail server already speaks DNS, answers are cached by resolvers along the way, and the lookup finishes in milliseconds, which matters because the receiving server makes this decision during the SMTP handshake, before your message body has even been transmitted.

The return code carries meaning too, and this is where most check pages stop short. A combined list encodes why in the last octet — one value for a known spam source, another for an infected machine sending through a botnet, another for a range the provider itself has declared should never send mail directly. Those are different accusations with different remedies, and treating them as one verdict is how "you are blacklisted" becomes useless advice.

The answer that looks like a listing but is not

There is a failure mode worth knowing about, because it silently poisons a lot of blacklist checkers. The major lists — Spamhaus above all — refuse to answer queries that arrive through public resolvers such as 8.8.8.8 or 1.1.1.1, and they refuse queries from sources that exceed their free daily volume. The refusal is not an error message. It is an answer in 127.255.255.0/24, and to a naive parser that looks exactly like a positive listing.

A checker that does not distinguish the two will accuse every address it is given of being blacklisted, confidently and without any visible malfunction. This page queries through our own resolver rather than a public one, treats the refusal codes as a separate state, and tells you plainly when a list declined to answer instead of counting it as either "listed" or "clean". If several lists decline at once, you will see that as a number, because it means our result is incomplete — not that your address is fine.

Not all lists mean "you did something wrong"

This is the single most misunderstood thing about blocklists. They fall into several categories, and only some of them are accusations:

Policy lists

Ranges that the network operator itself has declared should not be sending mail directly to the internet — essentially every residential and mobile connection. Being on one is not a mark against you; it is a statement of fact about your connection type, published by your own provider. Mail from home is supposed to go through the provider's outgoing server.

Exploit and botnet lists

Addresses observed sending mail through malware, open proxies or hijacked devices. On a home connection this usually means something on the network is infected — not necessarily the computer you are reading this on. A printer, a camera or an old phone is a perfectly ordinary culprit.

Reputation and spam-source lists

Addresses that have actually sent unwanted mail, usually measured against spam traps — mailboxes that exist solely to receive it, and which no legitimate sender should ever reach.

Backscatter lists

Servers that send bounce messages to forged senders. The classic cause is a mail server that accepts a message and only afterwards discovers the recipient does not exist, then dutifully bounces it to an address that never sent anything.

There is also a category we deliberately leave out. Some operators list entire subnets, or even whole autonomous systems, because of one bad neighbour, and offer paid express removal. Reporting that as "your address is listed" would say something untrue about someone who did nothing, so this page queries the address-level list of that family and not the escalation tiers. For the same reason it omits reputation zones where the same 127.0.0.x answer means "good sender" — shared handling turns praise into an accusation.

Why your address got listed

In rough order of how often each turns out to be the real cause:

• You are on a shared or dynamic address. With carrier-grade NAT one public address fronts many subscribers, so a listing earned by any of them lands on all of them. The same applies to an address recycled from a previous customer hours ago.
• Something on the network is compromised. An infected device sending through a botnet gets the address listed within hours. Look for outbound connections to port 25 from anything that is not your mail server — a device that has no business sending mail is the one to suspect.
• A web application is being used as a relay. A contact form without rate limiting, an unpatched CMS, or a forgotten script that mails whatever it is handed. This is by far the most common cause for a server that "does not send mail" and yet is listed.
• Forwarding. If your server forwards mail to another address, you inherit responsibility for whatever you forward, spam included. Forwarders get listed for other people's messages constantly.
• A genuine mailing to people who did not ask for it. Buying a list, mailing lapsed customers after years of silence, or importing contacts from a bought database will hit spam traps quickly.

Getting removed, in the order that works

Almost every list offers self-service removal, and almost everyone uses it in the wrong order. The removal is the last step, not the first:

1. Find and fix the cause. If the address is still doing whatever got it listed, removal buys you a few hours. Most lists relist automatically and some apply a longer penalty on repeat.
2. Check the basics of your mail setup. Reverse DNS that resolves back to your sending name, a matching forward record, a valid SPF policy, DKIM signing and a DMARC record. These do not remove a listing, but their absence is why marginal mail gets rejected even from a clean address.
3. Read what the list actually says. The detail line in the results above usually names the reason and links to the operator's own page. That page tells you what evidence they have and what they want to see fixed.
4. Request delisting once. Repeated requests do not speed anything up and on some lists they extend the wait.
5. Then wait for the caches. Receiving servers cache DNS answers, so mail can keep bouncing for a while after the listing itself is gone. Hours, not days, in most cases.

One exception worth stating plainly: if you are on a residential connection and you are listed on a policy list, there is nothing to fix and nothing to request. Send through your provider's outgoing server, or through a mail service, and the problem disappears. Running a mail server on a home line is not a configuration problem — it is a fight with the entire receiving world, and the receiving world is not going to change its mind.

What this check does and does not prove

It tells you what a specific set of lists says about one address at this moment. Receiving mail servers each choose which lists to consult and how much weight to give them, so a clean result here does not guarantee delivery, and a single listing on an obscure list rarely explains a delivery problem on its own. If mail is being rejected, the bounce message itself is far more informative than any blacklist page: it usually names the list and the reason directly.

Related checks: who operates this address — worth knowing before you conclude it is yours to fix — and the domain's DNS records, where SPF, DKIM and DMARC actually live.