IP blacklist check

Run an IP blacklist check for a mail server

An IP blacklist check helps investigate a specific mail-delivery problem by asking whether named sources currently list a sending address. Start with the public address of the server that actually delivers your messages. The address shown on your browser’s homepage may belong to a different connection entirely. A hosted email service can send through infrastructure unrelated to your office, home router, or website hosting account.

This IP blacklist check queries two mail-focused sources: SpamCop SCBL and the Passive Spam Block List, or PSBL. Their names are visible beside their individual results. There is no hidden claim that these are every list a recipient might use. A receiver can consult different services, maintain its own policy, or reject a message for reasons unrelated to address listings.

For an IP blacklist check, paste one public IPv4 address and select Check two mail lists. Do not paste an email address, domain, complete URL, or address followed by a port. The example button only fills a public example address; it does not run a lookup. The IP blacklist check waits for your explicit submission before making its DNS requests.

Find the relevant address before an IP blacklist check by reviewing a delivery failure notice or asking the administrator of your outbound mail service. A message may pass through several relays. Identify the server mentioned in the recipient’s rejection rather than choosing the first address you see. Keep the original failure notice so you can compare its time and stated reason with your later observation.

An IP blacklist check here accepts a public IPv6 address only to explain the coverage limit. This integration does not query either source for IPv6. An unsupported result must not be read as an empty list or successful check. IPv4-mapped input is normalized by the shared address parser; private, loopback, documentation, and other special-use inputs are rejected.

The IP blacklist check runs through our server using Google Public DNS. The resolver receives the DNS query names, which encode the submitted IPv4 address, and the list operators may receive those queries through the resolver. Your own configured DNS server is not being tested. The workbench keeps its result in the current tab until you clear it, leave, or explicitly copy a report.

Read each source independently

A Listed by this source result means the IP blacklist check received a recognized positive answer for that address, after source controls passed. It does not identify a person or establish why an individual message was sent. Read the operator’s criteria and compare the result with actual mail logs before changing service configuration or making an accusation.

A Not listed in this response result means the IP blacklist check received an expected negative DNS response with the required evidence for that source. The wording is deliberately limited to the response received. It does not mean that every receiver will accept your mail, that the address was never listed, or that other reputation systems have no information about it.

A Listing status not established result means the IP blacklist check could not safely interpret that source. Causes include unsuccessful controls, resolver errors, rate limits, unexpected return codes, malformed answers, or timeouts. Retrying later may help, but repeatedly submitting requests immediately can worsen a rate limit. An unavailable source never adds a positive or negative verdict to the report.

The IP blacklist check shows a separate observation time for each list. These are times when our service handled the evidence, not timestamps supplied by a spam reporter. DNS caches can serve previously obtained records within their permitted lifetimes. Consequently, two checks through different resolvers can briefly disagree without either result proving deliberate manipulation.

Expand the evidence panel of an IP blacklist check to inspect the target query name, response code, returned address codes, and cache lifetime. A lifetime of zero is a valid value and is displayed as zero seconds. A missing measurement is shown as missing. The cache lifetime is not the age of a listing or a countdown guaranteeing when removal will occur.

Copying an IP blacklist check creates a JSON report containing the submitted address, source links, controls, timestamps, and measured evidence. Review it before sharing: public infrastructure information can still reveal something about an organization’s mail setup. The report does not contain an invented aggregate safety score or a claim that the chosen sources cover every recipient’s filtering policy.

Why an IP blacklist check needs controls

Before testing your target, this IP blacklist check asks each list about a known positive control and a negative control. Both must behave as expected before the target query proceeds. This helps catch failures such as a resolver returning the same positive address for every question or a list appearing completely empty because the query path is unavailable.

For the IP blacklist check controls, the test addresses are 127.0.0.2 and 127.0.0.1. These are DNS test inputs only; the service does not connect to those loopback addresses. The general DNSBL convention is described in the informational RFC 5782. Passing controls improves interpretation of this query path, but it cannot certify a source’s complete dataset.

A failed control stops that source’s target query in the IP blacklist check. The other source can still finish independently. This means you might see one useful result and one unavailable result. Keep the distinction instead of collapsing the entire response into “clean,” and record which list was actually checked if you share the outcome with a mail administrator.

What this IP blacklist check cannot establish

An IP blacklist check is one part of mail troubleshooting. Successful delivery also depends on the recipient’s policy, message content, domain authentication, sending patterns, account restrictions, and other signals. This tool does not send a test email, connect to the recipient’s mail server, or inspect your mailbox. A positive DNS answer is not a diagnosis of all those systems.

The IP blacklist check does not treat any returned address as a valid listing automatically. These integrations recognize their expected code and reject unexpected data, including aliases or unrelated answer owners. Some services use special codes to describe access restrictions rather than listed senders. An unrecognized response therefore remains unavailable instead of becoming a misleading warning about the target.

This IP blacklist check does not include every commercial or community DNSBL. Each additional source requires a current review of its query policy, supported address families, response semantics, maintenance, and operational suitability. Adding a large number of names without those checks can create a more impressive count while making the conclusions less reliable.

An IP blacklist check is also different from a broad abuse-report database or VPN classifier. A mail-focused listing does not by itself prove that an address runs a VPN, hosts malware, or belongs to a particular subscriber. Shared addresses and reassigned infrastructure make personal attribution especially unreliable. Use the precise category reported by the source rather than substituting a wider allegation.

If an IP blacklist check shows a listing, start with the operator’s guidance linked from that result. Review the mail server and account activity you administer, identify the cause, and follow the source’s process. MyIP.dog does not remove entries or charge for removal. Only the relevant operator controls its listing policy and any review process.

After resolving the underlying issue, a later IP blacklist check can record a fresh observation. Compare source names and times before comparing statuses. Do not interpret a changed result as proof that your intervention caused removal: the list, reports, cache state, or query conditions may also have changed. Keep operational records that connect the troubleshooting steps to the actual mail failure.

An IP blacklist check investigation workflow

Use the IP blacklist check alongside the delivery notice, rather than as a replacement for it. First identify the outbound address and the recipient’s stated rejection reason. Then compare the named list with the sources available here. If the notice cites a different source, a negative result on these two lists does not contradict the notice.

Follow an IP blacklist check with IP WHOIS lookup when you need the registered network and its published contact information. Registration data describes an allocation, not an individual mail sender. If you use a hosted provider, its support team may be responsible for investigating the shared outbound address and communicating with the receiver.

For DNS configuration questions beyond an IP blacklist check, use DNS lookup to inspect published records and reverse DNS lookup for PTR information. Merely finding a TXT record is not a full SPF, DKIM, or DMARC validation. Likewise, a PTR record is not evidence that a sender is authorized to use a particular domain.

Do not repeatedly run an IP blacklist check as a background monitor from this interactive page. The service limits requests and bounds each run. If you need sustained operational monitoring, plan a dedicated integration that meets the source’s current usage terms, handles caching correctly, and reports failures without turning them into false all-clear notifications.

IP blacklist check questions

Does an IP blacklist check explain a website block?

An IP blacklist check here concerns two mail lists. A website can enforce its own policy for many unrelated reasons, including account state or traffic behavior. Compare the actual website error and contact its operator when appropriate. The mail-list response alone cannot explain a browser access decision, and changing networks does not correct every underlying account or service problem.

Which address belongs in an IP blacklist check?

Your browser and mail service can leave through different networks. An IP blacklist check should use the outbound address associated with the failed delivery, not assume that the browser’s current address is relevant. Webmail commonly delegates message delivery to provider infrastructure. A VPN used by your browser may have no effect on those servers’ outgoing connections.

Can an IP blacklist check guarantee delivery?

No. An IP blacklist check can describe only its named sources and current observations. It cannot guarantee a receiver’s future decisions or represent a source it did not query. Even the same recipient can handle two messages differently. Preserve the result’s scope when forwarding it to colleagues so that a narrow negative response does not become a broad promise.

Why does this IP blacklist check use two sources?

This IP blacklist check prioritizes explicit source coverage and interpretable responses. It currently includes SpamCop and PSBL, with controls on every IPv4 run. Additional providers can be added after their capabilities and usage conditions are reviewed. The count shown by this tool should always match implemented, named integrations rather than a marketing target.

What does stopping an IP blacklist check do?

Stopping the IP blacklist check stops waiting and invalidates the pending result in this tab. A request already received by the service or resolver may have begun processing; stop is not a promise to undo that work. Clear also resets the input and removes the displayed report. A late response cannot restore a report that you have cleared.

Where are the IP blacklist check sources documented?

The IP blacklist check implementation is documented on our methodology and data sources pages. Read SpamCop’s DNS query instructions, SpamCop’s list description, and PSBL’s usage documentation for the services’ own explanations. Source information was reviewed on September 28, 2026; policies and datasets can change after that review.