Email Blacklist Checker

Email blacklists, also called blocklists or DNSBLs, are lists of IP addresses and domain names that their operators tie to spam or other abuse. They are published in DNS, so a mail server can look up the address of every server that connects to it. RFC 5782, which describes how these lists work, says it plainly: “Network managers typically use DNSBLs to block traffic”. Each list decides on its own whom it lists and how you get off it; the RFC “does not describe or recommend policies for adding or removing addresses”.

This blacklist checker asks each list we use about the IP address or domain you enter:

1. An IP address goes to the lists of addresses: 11 lists for an IPv4 address (12 when Spamhaus is asked too) and 2 for an IPv6 address, because we send IPv6 addresses only to lists that document IPv6 data. The name we look up is the address written backwards in front of the list's name (RFC 5782 §2.1): for 80.241.213.11 on SpamCop, 11.213.241.80.bl.spamcop.net.
2. A domain name goes to the 3 lists of domains (4 with Spamhaus). Most of them are asked about the registered domain, so for mail.example.com about example.com: URIBL says its lists “only have the top level domain information”, and for the others that is our reading of their documentation.
3. Before we trust a list, we check its own test entries, which every list must answer in a known way (see below). A list that fails that test is not sent your address at all.
4. A list that has a record for the name lists it: we read the code in the answer (the A record) and the list's own text (the TXT record), as RFC 5782 asks: “Client software MUST check the A record and MAY check the TXT record.” A list that answers that the name does not exist (NXDOMAIN) does not list it: “if an IP address is not listed in the DNSxL, there MUST NOT be any records for the address.”

An IP address and a domain are two different questions. Mail servers that use a list look up the IP address of the server that is sending to them, so for your mail the address that matters is the one of the server that sends it (see how to find the IP address your mail is sent from). A domain is checked on the domain lists only: we do not look up its MX servers, because those receive mail, and when a provider hosts your mail they are the provider's servers, not the ones that send your messages.

The check only reads DNS: it sends no email and connects to no mail server. Every DNS answer behind the result, with the resolver that gave it, is in the Raw evidence panel under the result. A clean result covers the lists we asked, not every list there is, and not the lists mailbox providers keep for themselves: in Amazon SES's words, “many email providers have their own internal deny lists.” The domain lists are also part of the email domain check, and the deliverability test checks the server that actually sent your test message.

The panel at the top of the result is the verdict: a colored icon and a short label. A blacklist check can end in Pass, Warning, Fail or Could not check, in this order of precedence: a listing on a blocking list is a Fail even when another list could not be checked; otherwise any list that could not be checked makes the result Could not check, even next to a listing on an informational list; a listing on informational lists alone is a Warning; and the result is a Pass only when every list we asked answered and none of them lists the address or domain. Under the verdict, a table shows what each list answered, then the lists we did not ask and why. Every finding links to its explanation here.

Fail: listed on a blocking list

At least one list that is meant for refusing mail, or that we treat as one (the table of lists says when that is our reading rather than the list's own words), lists the address or domain. Mail servers that use that list may refuse your mail or file it as spam. The table shows what the list said: its reason, the code it answered and its own text, which often names a page with details. The list of fixes under the result gives that list's way to get off it; the full procedure is in how to get off a blacklist. Which lists count as blocking, each with the list's own words, is in the table of lists.

Warning: listed on an informational list

Some lists ask not to be used for refusing mail, and UCEPROTECT's Level 2 and Level 3 list whole provider networks rather than one address. A listing there is a Warning, not a Fail; the finding gives the list's own words, or says when the reading is ours. Today these are UCEPROTECT Level 2, UCEPROTECT Level 3, Spam Eating Monkey SEM-BLACK, Spam Eating Monkey SEM-IPV6BL, Spam Eating Monkey SEM-URI and URIBL. A network listing is one only your hosting provider or network operator can fix.

Pass: not listed

Every list we asked answered that it has no record for the address or domain, after its test entries answered correctly. A Pass covers exactly the lists we asked. Lists we did not ask, because they are turned off here or because Spamhaus is asked only through our own resolver, are named under the result as “not checked”, which is not the same as “not listed”; they do not change the verdict. When a list wants the registered domain, the finding says which name we asked about.

Could not check

We did not get an answer we can trust from at least one list, so we do not know whether it lists the address or domain. This is not a pass and not a fail. We never read a missing answer as “not listed”, and never read an error as “listed”. The table names the list and the reason:

• the DNS query timed out, the resolver reported a server failure (SERVFAIL) or refused it, the answer could not be decoded safely, or the check reached its own limit on DNS queries;
• the list answered with an empty response (NODATA) instead of saying that the name does not exist (NXDOMAIN), which is not how lists say “not listed”;
• the list answered with one of its error codes: values that look like a listing but report a problem with the question instead. Spamhaus says of its own: “none of these return codes relate to the reputation of the query – they are error codes.” The error codes of the lists we ask:
  • URIBL: 127.0.0.1, query blocked, possibly due to high volume; 127.0.0.255, query blocked (split-horizon filter).
  • Spamhaus ZEN: 127.255.255.252, typing error in the blocklist name; 127.255.255.254, query sent via a public/open resolver or from generic, unattributable rDNS; 127.255.255.255, excessive number of queries.
  • Spamhaus DBL: 127.0.1.255, IP queries are prohibited on the DBL; 127.255.255.252, typing error in the blocklist name; 127.255.255.254, query sent via a public/open resolver or from generic, unattributable rDNS; 127.255.255.255, excessive number of queries.
• the list answered with a code it does not document as a listing, or with an address outside 127.0.0.0/8, where RFC 5782 §2.3 says list answers belong (a resolver that rewrites answers can cause that), or with an alias (CNAME) that leads nowhere.

When no list at all could be asked about the target, the result says so and is Could not check too. A result that could not be checked is never reused, so a new check asks the lists again. Two cases do not clear that fast: a list that failed its own test is not asked again until the failed test is 15 minutes old, and a list whose query allowance is used up waits until the allowance refills (both explained below).

Could not check: a list failed its own test

Every list must answer a few test names in a known way. RFC 5782 §5: “IPv4-based DNSxLs MUST contain an entry for 127.0.0.2 for testing purposes. IPv4-based DNSxLs MUST NOT contain an entry for 127.0.0.1.” Domain lists have the same pair, TEST and INVALID, and some lists document test entries of their own, which we use instead. The RFC asks clients to check them: “DNSxL clients SHOULD periodically check appropriate test entries to ensure that the DNSxLs they are using are still operating.” A list that has shut down can answer “not listed” to every name, and a list that blocks a resolver can answer every name with the same code, or not at all; both show up in the test entries first.

• We test each list before we ask it about your address or domain, and reuse a good or a failed test for 15 minutes. When the test fails or cannot be completed, we do not send your target to that list at all, and it is Could not check; a test that could not be completed is tried again after 60 seconds.
• A “not listed” answer counts only if the listed test entry was confirmed in the last 60 seconds; otherwise we ask for it once more first.
• The answer has to come from the same DNS server that passed the test. If another server answered (our DNS client moves on to the next server when one does not answer), the list is Could not check for that run.

Could not check: our query allowance for a list is used up

Some lists limit how many questions one user may ask, and this checker keeps to those numbers. It and the domain blocklists of the email domain check share one allowance per list; test entries and the list's explanation text count too. The allowances:

• SpamCop Blocking List: 10,000 queries a day, our own cap, because the list publishes no number.
• Passive Spam Block List (PSBL): 10,000 queries a day, our own cap, because the list publishes no number.
• Mailspike Blacklist: 100,000 queries a day, the number the list publishes.
• UCEPROTECT Level 1, UCEPROTECT Level 2 and UCEPROTECT Level 3: 100,000 queries a day together, the number the list publishes.
• NordSpam IP Blacklist and NordSpam Domain Blacklist: 10,000 queries a day together, the number the list publishes.
• JustSpam: 10,000 queries a day, our own cap, because the list publishes no number.
• Spam Eating Monkey SEM-BLACK, Spam Eating Monkey SEM-IPV6BL and Spam Eating Monkey SEM-URI: 100,000 queries a day and 5 a second together, the number the list publishes.
• DroneBL: 10,000 queries a day, our own cap, because the list publishes no number.
• 0spam Project DNSBL: 800 queries a second, the number the list publishes.
• URIBL: 5,000 queries a day, our own cap, because the list publishes no number.

When an allowance is used up, we do not ask that list; the list is Could not check, and the result names the allowance in its “Safety limits” box. The allowance refills over time, so a later check can ask the list again.

What you can enter

• One IPv4 or IPv6 address, such as 80.241.213.11. An address inside a URL, with a port (80.241.213.11:25) or in square brackets is checked as the address alone. An IPv6 address takes a port only in square brackets ([2001:db8::1]:25), so text made only of hex digits, colons and dots, with two colons or more, that is not a valid IPv6 address is refused rather than read as an address and a port. An IPv4-mapped IPv6 address (::ffff:80.241.213.11) is checked as the IPv4 address it holds.
• A domain name, such as example.com; a URL gives its host name and an email address its domain.
• Not a range. Lists are asked about one address at a time (RFC 5782 §2.1), so 80.241.213.0/24 is refused rather than reduced to one address that would then stand for the whole range. A prefix of full length, /32 for IPv4 or /128 for IPv6, is one address, and is checked as that address.
• Not a private or reserved address, such as 10.0.0.5 or 192.168.1.10. Public lists never list them, and we do not send them anywhere. Enter the public address other servers see your server connect from.
• Not a lookup name. A name the check builds itself, such as 11.213.241.80.bl.spamcop.net, or a reverse DNS name such as 11.213.241.80.in-addr.arpa, is refused: enter the address or domain itself. So is a name with an underscore prefix, such as _dmarc.example.com.
• A public suffix such as co.uk has no registered domain, so lists that want one cannot be asked about it: those lists are Could not check. The same happens when a name would make a lookup name longer than DNS allows (253 characters).

Spamhaus

Spamhaus is a special case. Its rules allow free lookups only when Spamhaus can tell which network they come from, for example from a DNS resolver run on the checker's own network under a name Spamhaus can trace back to it. Its fair use policy: “you must query the Spamhaus DNSBL Public Mirrors from a recursive resolver run on your own network or from a public resolver which supports ECS.” So we ask Spamhaus ZEN and Spamhaus DBL only through our own resolver, and never through a public one. When the result says “Spamhaus ZEN not checked” or “Spamhaus DBL not checked”, we did not ask Spamhaus on that run: that is “not checked”, never “not listed”, and it does not change the verdict. You can look the address or domain up yourself on Spamhaus's website, whose lookup Spamhaus describes as “Provided for people to check their own IPs or domains.” We never query that page from our server: Spamhaus asks “Do NOT automate queries of our website lookup form!”

Could not check: a fault on our side

Rarely, the result says the check could not be completed because of an internal error. That is a fault in our software, not a finding about your domain and not a network problem, so trying again will most likely give the same result. Please write to support@mxverdict.com with the address of the result page, and we will fix it.

Removal is up to each list's operator, not to us or to the receivers of your mail. Every list has its own rules; what they share is the order:

1. Find and stop the cause first. Mailspike names the usual ones: “Compromised Email accounts being used to send spam/malware/phishing” and “Compromised PCs/servers under the control of criminal organizations”. PSBL adds another, mail to harvested addresses: “If you send email to harvested email addresses, or email addresses of other dubious origins, you run the risk of being listed on many DNSBLs”. A request made before the cause is gone rarely lasts: “if the behavior that caused the listing persists, it is very likely that the IP address will eventually get listed again” (Mailspike).
2. Then follow the list's own procedure. The fix under your result names it for each list that lists you, and the table below has it for every list: a removal form, an email, or nothing to request because the listing expires on its own. The times lists give can have exceptions: Mailspike delists “within 6h-36h”, but when a spam botnet caused the listing, only “after we collect network records that the Malware threat is mitigated”.
3. Check again after the time the list states. We reuse a result for 60 seconds, and DNS resolvers, ours as well as those of the mail servers that use the list, may keep a list's old answer until its time to live (TTL) runs out. Each list chooses its TTL (RFC 5782 §4); the Raw evidence panel under the result shows the TTL of each answer, in seconds.

Your own mail server

When you run the server that sends your mail, the address is yours, and so is the request: NordSpam, for example, wants it “sent from the blacklisted IP block owner”. Look for the cause on the server itself: a hacked mailbox or website, an open relay, malware on a machine behind the address, or mail to old or bought lists. A new server can also come with a listing: its address may have been used by someone before you (see the question below). A listing on UCEPROTECT Level 2 or 3 covers your provider's network, not only your address; only the provider can deal with it. The reverse DNS lookup shows the host name (PTR record) of the same address and whether it points back.

Google Workspace, Microsoft 365 and Zoho Mail

When your mail goes out through a mail provider, the sending address is the provider's server, not yours, and its removal is the provider's business: DroneBL, for example, takes requests only from the primary user of an address, and advises: “If you are using a server and you are not the administrator of it, you should talk to the administrator.” So send the provider's support (Zoho Mail's or Microsoft's; for Google Workspace, see below) the address, the list and the result.

Google Workspace: Google's help says “Google regularly asks denylist services to remove our IP addresses if they get blocked. However, because we can't prevent services from blocking any of our IP addresses or guarantee the removal of them, Google doesn't remove IP addresses on a denylist.” For mail that bounces meanwhile, its advice is on the receiving side: “Ask the recipient to add your domain name to their approved senders list.”

Microsoft 365: Microsoft documents how this happens: spam from compromised accounts and similar sources “can result in the IP address of the affected Microsoft 365 datacenter servers appearing on non-Microsoft blocklists”, which is why “all outbound messages from Microsoft 365 datacenter servers that are determined to be spam are sent through the high-risk delivery pool”. An administrator can see which pool sent a message in Message trace, in the OutboundIpPoolName property. If your own messages go out through that pool, the fix is on your side: Microsoft sends a message there when it judges it to be spam, and always when the sender's domain has no A record and no MX record in public DNS.

SendGrid, Mailgun and Amazon SES

All three offer shared addresses, which many customers send from, and dedicated ones, which only you send from. Mailgun warns: “When you use a shared IP, you are sharing your reputation with those other senders.”

• Twilio SendGrid: the Trial and Essentials plans use shared addresses, and Twilio “can't move your account to another IP pool” because of a listing. It watches those addresses itself: “If Twilio detects issues and delisting is possible, it'll attempt remediation.” On Pro and Premier plans with your own address: “If you discover your Twilio SendGrid IP address on a blocklist, make the delisting request first.”
• Amazon SES: for its shared addresses, SES watches the lists that could affect its whole service or delivery to major mailbox providers, Spamhaus among them, and when one of them lists an address, “we take immediate action to have that address removed from the DNSBL as quickly as possible.” It does not watch the rest: “The DNSBLs offered by SORBS and UCEPROTECT fall into this category. Because of the specific listing and delisting practices of the vendors who operate these lists, we are unable to have our IP addresses removed from these lists.” For a dedicated address, “you must request removal yourself directly to the RBL administrator.”
• Mailgun: “Mailgun offers both shared and dedicated IPs” and says of them: “We are constantly monitoring the traffic on these IPs”. A shared address is Mailgun's, so send its support the result. A dedicated address sends only your mail, so a listing that appears while you use it comes from your own sending: fix that first, as above.

A listed domain

A domain is listed for what it is used for. NordSpam, for example, lists domains that “appear to be under the control of, used by, or made available for use by spammers and abusers”: spam sent from addresses at the domain or linking to it, or a hacked website on it. The request is the domain owner's to make; SendGrid: “If someone added your domain, and not your IP address, to a blocklist, the domain administrator must make the delisting request.” NordSpam wants it sent from an address at the listed domain itself. Changing DNS records does not take a domain off a list, so there is nothing to change at your DNS host for this: fix the cause, then follow the list's procedure as above.

Every mail server that receives a message adds a Received line at the top of its header. RFC 5321 §4.4 asks each one to note where the message came from: “an address literal containing the IP address of the source, determined from the TCP connection”, in square brackets. Since each server adds its line above the others, read from the top down:

1. Send a message from your usual address to a mailbox you can read at another provider, for example a Gmail account.
2. Open its full header. In Gmail: open the message, then next to Reply click More (the three dots) and Show original.
3. Going down from the top, find the Received: from line where the receiving provider's server took the message from a server outside it. That line names your sending server, or your provider's, and the address in square brackets is the one to check.
4. Enter that address in the form above.

Easier: the deliverability test on our home page gives you two addresses to send one message to. Its report shows the address of the server that delivered it and checks it on the same lists as this page.

A bounce often names the list, too: the list's explanation text “is often used as the text of an SMTP error response” (RFC 5782 §2.1). Amazon SES gives this example of such a bounce: 554 5.7.1 Service unavailable; Client host [192.0.2.0] blocked using DNSBLName; See: http://www.example.com/query/ip/192.0.2.0.

These are the lists this checker knows, with what each one lists, what a listing means in our result (a Fail on a blocking list, a Warning on an informational one, with the reason in the list's own words or marked as ours) and how a listing goes away. The table comes straight from the registry of lists the check itself uses, so it always matches what the check asks. We read each list's terms and documentation before adding it, and last checked the removal rules in this table against the lists' own pages on September 27, 2026.

Lists we never ask:

• SORBS (sorbs.net): Shut down: Proofpoint decommissioned SORBS on June 5, 2024, and its zones hold no data; sorbs.net itself does not exist in DNS any more (NXDOMAIN), so a checker that still asked it would report "not listed" forever. Source.
• Abusix Mail Intelligence (abusix.zone): Every query needs an Abusix account key; our test query without one got SERVFAIL. Abusix has a free plan of 5,000 queries a day and paid plans above it; this site asks only lists that need no key. Source.

A list is an ordinary DNS zone, so any DNS tool can ask it. Write the IPv4 address backwards and add the list's zone: for 80.241.213.11 on SpamCop, the name is 11.213.241.80.bl.spamcop.net. An IPv6 address is written as its 32 hexadecimal digits in reverse order, separated by dots; a domain goes in front of the zone as it is, or as its registered domain for the lists that want one (see the table of lists). On September 26, 2026, from our development machine:

$ dig +short 11.213.241.80.bl.spamcop.net
$ dig +short 2.0.0.127.bl.spamcop.net
127.0.0.2
$ dig +short 2.0.0.127.bl.spamcop.net TXT
"Blocked - see https://www.spamcop.net/bl.shtml?127.0.0.2"

No output for our address means no record: the full answer said status: NXDOMAIN, so SpamCop does not list it. The second name is the test entry every IPv4 list must have, 127.0.0.2, so it answers “listed”, and the TXT record is the list's explanation. The same for a domain list:

$ dig +short mxverdict.com.dbl.nordspam.com
$ dig +short test.dbl.nordspam.com
127.0.0.2

nslookup, which Windows has too, does the same; on macOS it printed, after two lines that name the resolver:

$ nslookup 11.213.241.80.bl.spamcop.net
** server can't find 11.213.241.80.bl.spamcop.net: NXDOMAIN

Ask the test entry first. An empty answer proves nothing when the list does not answer your resolver properly. Spamhaus has an error code for queries it refuses to answer, 127.255.255.254: “Query via public/open resolver/generic unattributable rDNS”; and URIBL warns: “If you abuse it, we will block your IP, or your nameserver IP that is producing the excessive queries.” If the test entry does not answer 127.0.0.2 (or the value the list documents), the answer for your address means nothing. This checker tests every list before it trusts the list's answer (see above).