1. Enter a target
Use one public IP, domain, or email address. URLs, paths, IP ranges, and custom DNS zones are intentionally not accepted.
Check a public IPv4 address, supported IPv6 address, domain, or email domain’s mail infrastructure against the DNS-based blacklist providers configured for Netest.
Enter 8.8.8.8, example.com, or [email protected]. Email inputs always check the domain’s MX infrastructure.
No listing was detected only on the configured providers that successfully answered this lookup.
An IP blacklist checker asks selected DNS-based blocklists, commonly called DNSBLs or RBLs, whether they return a listing response for a public address. Mail servers and spam filters may use their own combination of these services with additional reputation signals.
For a domain, the checker can resolve web-facing A records or mail exchangers. For an email address, it extracts the domain and checks the mail infrastructure instead of making the misleading claim that an individual mailbox is on an IP DNSBL.
Use one public IP, domain, or email address. URLs, paths, IP ranges, and custom DNS zones are intentionally not accepted.
Use A for a domain’s address records; use MX when investigating mail delivery. Email addresses use MX automatically.
Review listings and unavailable providers first. A timeout or provider error is never displayed as Not Listed.
Use the provider’s own documentation for a listing reason and delisting process after fixing the underlying cause.
For IPv4, a DNSBL lookup reverses the address before adding the configured provider zone. For example, 1.2.3.4 becomes 4.3.2.1 followed by the provider’s DNS zone. A listing response and an absent response have different meanings, while DNS failures remain failures.
IPv6 uses different query formats and provider support varies. This tool shows Unsupported for a provider that has not been explicitly configured for IPv6 rather than applying incorrect IPv4 reversal logic.
A DNSBL is one provider’s current listing state; sender reputation is a broader, changing assessment.
| Signal | What it indicates | Important limitation |
|---|---|---|
| Blacklist status | A configured provider returned or did not return a listing response at check time. | Different mail systems use different providers. |
| IP reputation | Historical behavior, authentication, complaints, and delivery patterns. | It cannot be reduced to a single DNS query. |
| Delivery outcome | A recipient’s decision for a particular message. | Content and recipient policy also matter. |
Spam, compromised mailboxes, poor list hygiene, and spam traps can cause complaint or abuse signals.
Malware, bot activity, insecure web applications, and open relays can generate traffic that damages reputation.
Shared hosting and shared mail IPs can affect multiple customers when one tenant behaves abusively.
Identify the provider, investigate the reason, stop abusive traffic, secure affected systems, and verify relevant email authentication. Then use the provider’s official delisting instructions and recheck after remediation. Do not promise a fixed delisting time or change an IP address without fixing the underlying problem.
Blacklist status changes over time, providers can be temporarily unavailable, and absence from these configured lists does not guarantee deliverability. Check MX, DNS, SPF, DKIM, and DMARC context as part of a broader investigation.
Enter it above to see its result on the providers configured for this service.
Domain and IP reputation differ. This tool resolves relevant infrastructure and checks its addresses.
Yes. Shared infrastructure can inherit the impact of another user’s abusive traffic.
A VPN changes the visible address for some services, but it does not remediate the original server and VPN exit IPs may have their own reputation issues.
They are common terms for DNS-based or real-time blocklists used as email reputation signals.
No. Sender reputation, authentication, message content, and recipient policy still apply.