IP Blacklist Checker
Look up a sending IPv4 in public DNS blocklists and distinguish a listing from an unavailable query.
Enter the actual public sending IPv4, not your email address or domain. Documentation addresses such as 203.0.113.10 are placeholders and are rejected.
No registration required. Checks run on our server using Google Public DNS. The resolver and blocklist provider may cache DNS answers. No email test allowance is used.
How to use IP Blacklist Checker
- Obtain the actual public outbound IPv4 from your sending provider, SMTP delivery logs or the receiving system’s trusted
Receivedheader. It may differ from your website IP and your inbound MX server. - Enter one dotted-decimal IPv4 address.
203.0.113.10illustrates the format only: it is a reserved documentation address and is deliberately rejected. Replace it with your real sending IPv4. - Select Check blacklists. There are no optional fields. Domains, email addresses, IPv6, private IPs and reserved ranges are not accepted.
- Read each provider’s status and official help link. For a shared sending IP, ask the sending provider to investigate a listing; address the underlying cause before requesting removal.
What this tool checks
A DNS-based blocklist (DNSBL) answers a specially constructed DNS query about an IP. This checker reverses the IPv4 octets, queries each enabled provider through Google Public DNS, and interprets only configured response codes.
- The enabled provider set: PSBL, DroneBL. The result’s Provider coverage table also identifies disabled providers; they are not checked.
- A-record listing codes and optional TXT explanatory data for the entered IP, plus a known test record used to assess provider availability.
- Whether the answer contains recognized listing codes. A no-listing answer becomes Not listed only when the provider health check also responds as expected.
This is neither an all-blocklists search nor a general reputation score. It does not query private mailbox-provider reputation systems, inspect a domain’s reputation or test delivery. Provider A answers such as 127.0.0.2 are codes, not your server’s address and not links to visit.
Understanding your results
Investigate the reason for a listing and resolve abuse before requesting removal through the official provider. A clean result on these lists does not guarantee delivery.
| Finding | Meaning & likely cause | Next action |
|---|---|---|
| Listed · Fail | The provider returned configured listing code(s) for this IP. The reason shown maps those codes to that provider’s categories. | Review its Official help page, investigate abuse or compromised systems, fix the cause and follow its removal process. |
| Not listed · Pass | No listing answer was returned and the provider’s test record responded normally. | Treat this as a result for that provider at that time. If delivery is failing, read the recipient’s rejection and sender logs. |
| Blocked or unrecognized provider response · Unknown | An unexpected A code prevents a reliable listing conclusion. It may describe provider or resolver restrictions. | Consult the provider directly; do not treat the response as either Listed or Not listed. |
| Timeout / Unknown / query refused | The IP query or the provider health check was unavailable. An empty response without a working health check is inconclusive. | Retry later and use the official provider lookup if the issue persists. |
| Disabled | The service has not enabled that provider. Its table row explains why it is excluded. | Do not count it as checked coverage. Follow its official help link if that provider is relevant to your delivery problem. |
| Check your input | The value is not an accepted public IPv4; it may be a domain, IPv6 or a reserved example. No blacklist conclusion is produced. | Use the real outbound public IPv4 from the sending service or a trusted receiving log. |
What is an IP blocklist check and why does it matter?
An IP blocklist publishes signals associated with sending infrastructure or abusive network activity. Providers collect different evidence and define different categories. Receiving systems may use those lists as one input to their own filtering decisions.
Use this lookup when a bounce names a blocklist or when reviewing an outbound IP with your mail host. A listing is a provider-specific finding, not proof that every message from the IP is spam. Conversely, absence from the enabled lists does not guarantee delivery. If the bounce instead describes authentication, inspect the relevant SPF policy or DKIM key.
Frequently asked questions
How do I find the correct IP when I use an email platform?
Ask the platform for the outbound IP used for the particular delivery, or inspect its delivery logs and trusted Received headers. A platform can use multiple sending IPs. Looking up your website or inbound MX may identify a different server.
Why is the example IP rejected?
203.0.113.10 is reserved for documentation, so it is safe to show as an example but cannot be checked. Use an actual public sending IPv4. The form also rejects private, reserved and IPv6 addresses.
Which blocklists are included, and is Spamhaus checked?
The enabled set is shown above and in Provider coverage. In the current project configuration, PSBL and DroneBL are enabled; Spamhaus is disabled because this public service has no confirmed appropriate licence/resolver entitlement. Disabled is not a clean result.
I was delisted. Why can a listing still appear?
Confirm the exact IP and provider and check the provider’s current official status. DNS answers can be cached by the resolver or provider. This checker’s batch DNSBL path does not use the application’s five-minute DNS cache, and it cannot promise a fixed time for a removal to become visible.
Can this tool remove my IP or explain every rejected email?
No. Removal is handled by the provider after the cause is addressed. For a shared IP, involve your sending platform. Keep the exact bounce response: a rejection can come from another list, private reputation rules, authentication or recipient policy even when these checks show Not listed.