# Check the Spamhaus blacklist: identify and fix a listing > Check a Spamhaus result, identify the list owner, repair the cause, use the correct removal path, and validate the sending route. To check the Spamhaus blacklist, use Spamhaus's official IP and Domain Reputation Checker with the exact public IP address or domain named in the rejection. Record the named blocklist, the evidence shown, and who controls the listed resource. A PBL policy listing, a DBL domain listing, and a CSS, SBL, or XBL IP listing have different owners and removal paths. Fix the supported cause first, follow the official path for that list, then repeat the lookup and the original sending-path test. Spamhaus calls these datasets blocklists. This guide keeps “blacklist” in the title because that is the common search phrase, but uses the vendor's current terminology in the procedure. ## Quick takeaways - Check the exact public IP or domain from the failure, not only the visible From domain. - Save the named list, listing text, timestamp, sending path, and SMTP rejection before changing anything. - Treat a PBL result as a sending-policy signal, not automatic proof of abuse. - The IP or domain owner, ISP, ESP, hosting provider, or domain administrator may need to act. A customer cannot always submit the request. - Repair the cause before requesting removal. A request made while the evidence still fails can be denied. - A clean checker result does not guarantee inbox placement, sender reputation, or acceptance by every receiver. ## What does the failure mean? A Spamhaus result means the submitted resource matched at least one Spamhaus dataset at the time of the lookup. It does not mean every receiver will reject the message, and the word “listed” does not identify the cause on its own. The official [Spamhaus Reputation Checker](https://check.spamhaus.org/) accepts an IP address, domain, ASN, SBL number, email address, or hash. For outbound mail troubleshooting, start with the connecting IP or domain that the receiving server actually named. If the rejection includes an IP address, do not substitute the marketing domain. If it names a linked domain, do not assume the sending IP is the only relevant resource. ```text Observed rejection: 550 5.7.1 [public IP] listed by Spamhaus Resource checked: 192.0.2.44 Result timestamp: 2026-07-27T14:30:00Z Named list: PBL | CSS | SBL | XBL | DBL Sending path: application -> relay -> public IP -> recipient MX Evidence owner: network | mail platform | security | web/domain owner ``` The values above are a documentation format, not a live listing. Use the real resource and exact checker result from your incident. > Use only account-specific values from your own incident. Do not reuse another organization's IP address, domain, HELO name, PTR hostname, account email, verification code, listing reference, or support-ticket detail. Shared or provider-owned resources must be handled by the ISP, ESP, or hosting provider that controls them. The current public checker can also return a clean result. The capture below used the public IP `8.8.8.8` on July 27, 2026 and returned “has no issues.” It teaches the result surface only. It does not prove what a listing detail or removal form looks like, and it does not say anything about another sender. ![Spamhaus IP and Domain Reputation Checker showing that the public IP 8.8.8.8 has no issues.](/images/editorial/check-spamhaus-blacklist/spamhaus-8-8-8-8-no-issues.jpg "1728x996") *Source: current public result from the [Spamhaus IP and Domain Reputation Checker](https://check.spamhaus.org/), captured July 27, 2026. [Open the full-size capture](/images/editorial/check-spamhaus-blacklist/spamhaus-8-8-8-8-no-issues.jpg). The result is time-bounded and applies only to the submitted public resource.* ## What usually causes it? ### The connecting IP matches an IP blocklist Spamhaus's [ZEN Blocklist documentation](https://www.spamhaus.org/blocklists/zen-blocklist/) says ZEN combines SBL, CSS, XBL, and PBL. A ZEN response should therefore be interpreted by its component list, not treated as a fifth generic cause. - **PBL** covers end-user IP ranges that should not deliver unauthenticated SMTP directly to destination mail servers. - **CSS** concerns IPs associated with low-reputation email. - **XBL** concerns compromised systems and illegal third-party exploits. - **SBL** concerns spam sources and operations that Spamhaus has identified. The named component changes the owner and repair. Do not request a PBL exclusion simply to keep sending directly from an address range whose policy requires authenticated submission through a relay. ### A PBL listing is expected for the IP range The official [PBL policy](https://www.spamhaus.org/blocklists/policy-blocklist/) states that listed end-user IP ranges should submit mail with authentication to an SMTP server that performs final delivery. It also states that PBL IPs are not necessarily bad. A residential, dynamic, or non-MTA address can therefore be correctly listed even when its user has not sent spam. For that case, the durable repair is usually routing outbound mail through the organization's authorized authenticated relay. An exclusion is appropriate only when the network policy and Spamhaus's checker say that the IP is eligible to deliver mail directly. ### A domain matches the DBL The [Spamhaus Domain Blocklist documentation](https://www.spamhaus.org/blocklists/domain-blocklist/) says DBL contains domains associated with spam or malicious activity, including domains controlled by bad actors and legitimate domains that have been hijacked. A DBL result can relate to the HELO name, envelope sender, message headers, or a domain in message content. That means a DBL investigation may belong to the website, DNS, redirect, account-security, or marketing owner rather than the mail-server owner. Check for compromised CMS files, unauthorized DNS changes, abused redirects, stolen credentials, unexpected subdomains, and links inserted into current campaigns. SPF, DKIM, and DMARC can help authenticate mail, but they do not erase malicious web content or a compromised account. ### CSS troubleshooting identifies a mail-host configuration problem Spamhaus's current [checker troubleshooting guidance](https://www.spamhaus.org/resource-hub/ip-and-domain-reputation-checker/spamhaus-reputation-checker-troubleshoot-your-listing/) describes checks for the recent HELO value, PTR record, forward resolution, and whether those identities agree. A mismatch can block a successful CSS removal request. The same guidance is not a universal explanation for every list. Use the checker steps presented for the actual resource and named listing. ## How do I diagnose the failure? ### 1. Preserve the original rejection and route Start with the unaltered SMTP log or delivery status notification. Save the basic and enhanced status codes, remote host, diagnostic text, timestamp, Message-ID, envelope sender, visible From domain, sending application, relay, and public egress IP. The [bounce-back email evidence guide](/learning/common-email-bounce-messages) explains why a generic `550` is not enough. The named receiver and transaction stage establish which resource it evaluated. ### 2. Submit the exact resource to the official checker Use the exact IP or domain. If an email platform uses a shared pool, identify whether the platform or your organization controls the IP before attempting a network change. If a message contains several branded and tracking domains, check the one named by the receiver or checker before expanding the investigation. Spamhaus's official documentation shows the Checker accepting a single IP, domain, ASN, SBL number, email address, or hash. Start there instead of using a generic contact form or a paid third-party removal service. ![Spamhaus IP and Domain Reputation Checker input for a single IP, domain, ASN, SBL number, email address, or hash.](/images/editorial/check-spamhaus-blacklist/spamhaus-checker-input-live.jpg "1728x940") *Source: live public [Spamhaus IP and Domain Reputation Checker](https://check.spamhaus.org/), captured July 27, 2026. [Open the full-size capture](/images/editorial/check-spamhaus-blacklist/spamhaus-checker-input-live.jpg).* Capture the full result or save its text. Record the exact named list, description, any reference number, and the official next step. Do not paste a different customer’s listing into a ticket as evidence. ### 3. Route by list before touching configuration ![Diagnostic flow for routing a Spamhaus result by resource type and named blocklist.](/images/editorial/check-spamhaus-blacklist/spamhaus-listing-diagnostic-flow.svg "1200x760") *Source: Palisade deterministic flow based on [Spamhaus's ZEN, PBL, DBL, and Checker guidance](https://www.spamhaus.org/blocklists/zen-blocklist/), checked July 27, 2026. [Open the full-size diagnostic flow](/images/editorial/check-spamhaus-blacklist/spamhaus-listing-diagnostic-flow.svg).* Use the diagram as an ownership router: - PBL goes first to the public-IP and relay owner. - CSS, SBL, or XBL goes to the mail, security, and network owners with the checker evidence. - DBL goes to the domain, web, DNS, account-security, and message-content owners. - A clean result goes back to the original receiver evidence instead of becoming a delivery guarantee. ### 4. Confirm root cause with independent evidence For IP listings, examine queue volume, authentication logs, outbound connections, malware alerts, recent credentials, complaint signals, PTR, forward DNS, and HELO. For a domain listing, examine DNS history, registrar events, CMS and plugin changes, redirect behavior, access logs, and the exact campaign content. Use [domain reputation checks](/learning/how-can-you-check-and-improve-your-email-domain-reputation) as supporting evidence, not as a substitute for the Spamhaus detail. A second generic reputation score cannot override the named list. ## How do I fix it? ### Repair a PBL route Move the application or device to authenticated message submission through the approved relay. Confirm that the relay, not the end-user IP, makes the external SMTP connection. If the IP is genuinely a static MTA address and the network policy permits direct sending, follow the eligibility and exclusion steps shown by the checker. Do not bypass an expected policy listing with another direct-send IP from the same unsuitable range. ### Repair a mail host or compromised IP Stop unauthorized outbound traffic before requesting removal. Rotate exposed credentials, remove malware, close open relays or proxies, restrict direct outbound port 25 where appropriate, correct HELO and PTR identity, and review queue and authentication logs for continued abuse. For CSS, use the current checker’s HELO, PTR, and forward-confirmed reverse DNS evidence. The guidance says a removal request is likely to be unsuccessful while those checks still show a configuration problem. The mail server's HELO name, its forward A or AAAA result, and its reverse PTR result must describe the same sending host for this CSS workflow. Operators of a shared hosting IP must contact the hosting provider instead of changing provider-owned DNS or claiming the address. ### Repair a compromised or abused domain Remove malicious files, links, redirects, or unauthorized DNS records. Patch the CMS, plugins, server, and administrative access path. Rotate credentials, enable multifactor authentication where available, and review all domains used in mail headers and content. If a legitimate sender or redirect service introduced the listed domain, pause it until ownership and remediation are clear. ### Follow the list-specific owner and removal path After the cause is fixed, use the instructions attached to the exact result: The live test result below uses `dbltest.com`, Spamhaus's published DBL test domain. It shows a real current listing surface, identifies the named DBL, and states that SBL removal belongs to the ISP. It is test evidence only, not an incident or an account value to reuse. ![Spamhaus Checker showing the official dbltest.com test domain with one DBL listing and the SBL ISP ownership warning.](/images/editorial/check-spamhaus-blacklist/spamhaus-dbltest-listing-live.jpg "1728x971") *Source: live public [Spamhaus result for its DBL test domain](https://check.spamhaus.org/results?query=dbltest.com), captured July 27, 2026. [Open the full-size capture](/images/editorial/check-spamhaus-blacklist/spamhaus-dbltest-listing-live.jpg).* - For a CSS listing, complete the Checker's [troubleshooting steps](https://www.spamhaus.org/resource-hub/ip-and-domain-reputation-checker/spamhaus-reputation-checker-troubleshoot-your-listing/). Spamhaus says a resolved case can proceed to the verification form. If automatic removal is allowed, no further action is required. Otherwise, the Checker opens a ticket and sends the operator to the Ticket Center. - For an SBL listing, Spamhaus says the ISP in charge of the listed IP must submit the removal request after the abuse is stopped. An end user should contact the system administrator, ISP, or ESP instead of claiming control of the address. - For a PBL listing, a single static IP should be excluded only when it is an outbound mail server with suitable forward and reverse DNS and is assigned to the requester. Multiple addresses or provider-owned ranges belong to the ISP's PBL account. - For an XBL listing, follow the instructions on the exact Checker result and involve the network, security, or ISP owner that can remove the exploited host or proxy condition. - For a DBL listing, the domain, website, redirect, DNS, or account-security owner must remove the abuse or compromise, then start the removal procedure in the official Checker. The [SBL removal FAQ](https://www.spamhaus.org/faqs/spamhaus-blocklist/) and [PBL eligibility rules](https://www.spamhaus.org/blocklists/policy-blocklist/) show why the requester must match the resource owner. The [DBL FAQ](https://www.spamhaus.org/faqs/domain-blocklist/) routes abused legitimate domains through the Checker after remediation. Spamhaus also says removal is free and no third party can expedite it. Record the request time, verified requester, and reference. Do not submit repeated requests while the cause remains visible. ## How do I validate the repair? Validation has four separate layers. Passing one layer does not make the other three unnecessary. ### Layer 1: DNS and public-list evidence Recheck authoritative and public DNS for the HELO A or AAAA record, PTR result, and forward-confirmed reverse DNS when those records were part of the repair. Repeat the official Spamhaus lookup after any approved removal has had time to propagate. Save the new timestamp and result beside the original evidence. ### Layer 2: Spamhaus workflow state Confirm that the Checker no longer reports the issue, the verification flow completed, or the ticket has the expected status. A pending ticket is not the same as a cleared listing. A clean result applies only to the submitted resource at the time of that lookup. ### Layer 3: A real message on the affected path Send one controlled message through the same application, authenticated submission service, public egress IP, envelope sender, visible From domain, content path, and recipient provider that produced the failure. Compare the new SMTP response with the original one. If the message is delivered, inspect the [receiver-added `Authentication-Results` field defined by RFC 8601](https://www.rfc-editor.org/rfc/rfc8601.html) from a trusted receiving system. Acceptance proves only that transaction. ### Layer 4: DMARC aggregate reporting and cause monitoring Review DMARC aggregate reports for the affected source and authentication path. [RFC 9990](https://www.rfc-editor.org/rfc/rfc9990) defines the aggregate-reporting format, but those reports do not prove that Spamhaus or every receiver has cleared the IP. Also check outbound traffic, queue behavior, credential use, DNS change logs, CMS integrity, and complaint controls. Monitoring the cause is more durable than watching the removal request alone. If the Spamhaus result is clean but the rejection continues, use the [email deliverability learning center](/learning/email-deliverability) to follow the authentication, DNS, content, or provider-policy evidence named by the receiver. ## Check the IP again after the Spamhaus removal For an IP-list incident, run the affected public IP through Palisade's [IP Reputation Check](https://www.palisade.email/tools/ip-reputation) after the official Spamhaus Checker clears it, then compare that result with a fresh production-path test. [Check the IP reputation](/tools/ip-reputation) This public check cannot submit or speed up a Spamhaus removal, read a receiver's private reputation system, prove why one message was rejected, continuously monitor the IP, or guarantee delivery. For a domain-only DBL incident, keep the official Checker and the repaired domain evidence as the primary validation. A cleared listing still does not inventory every service sending as the organization's domains or show which production sources later fail authentication or alignment. Palisade's [documented domain workflow](https://docs.palisade.email/page-breakdowns/domain-overview/) uses DMARC aggregate-report data to identify sending sources and authentication or alignment issues. Palisade's DMARC Agent analyzes that report data, creates prioritized remediation tickets, detects when a domain appears ready for the next policy stage, and proposes the move. A human reviews the evidence and applies every DNS or policy change. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=sender_reputation&utm_content=check-spamhaus-blacklist) Palisade does not remove Spamhaus listings, change a receiver's private reputation decision, or guarantee delivery. ## Sources and further reading - [Spamhaus IP and Domain Reputation Checker](https://check.spamhaus.org/) - [Spamhaus checker troubleshooting guidance](https://www.spamhaus.org/resource-hub/ip-and-domain-reputation-checker/spamhaus-reputation-checker-troubleshoot-your-listing/) - [Spamhaus ZEN Blocklist](https://www.spamhaus.org/blocklists/zen-blocklist/) - [Spamhaus Policy Blocklist](https://www.spamhaus.org/blocklists/policy-blocklist/) - [Spamhaus SBL and DBL removal FAQs](https://www.spamhaus.org/faqs/spamhaus-blocklist/) and [Domain Blocklist FAQ](https://www.spamhaus.org/faqs/domain-blocklist/) - [Receiver-added authentication results in RFC 8601](https://www.rfc-editor.org/rfc/rfc8601.html), [DMARC aggregate reporting in RFC 9990](https://www.rfc-editor.org/rfc/rfc9990), and [Palisade's domain evidence workflow](https://docs.palisade.email/page-breakdowns/domain-overview/) ## Frequently asked questions ### Is a Spamhaus PBL listing proof that an IP sent spam? No. Spamhaus says PBL contains end-user IP ranges that should not send unauthenticated SMTP directly to destination servers and that listed IPs are not necessarily bad. Use an authorized authenticated relay unless the IP and network policy support direct MTA operation. ### Should I check my domain or my IP address? Only check the resource named in the rejection first. For an IP-list rejection, use the public egress IP that connected to the receiver. For a DBL or linked-domain result, use the exact domain shown by the evidence. Expand to related resources only after preserving the original result. ### Does a clean Spamhaus result guarantee delivery? No. It says the submitted resource had no issue in that checker result at that time. Receivers can apply other reputation, authentication, content, rate, and account rules. ### Can a company pay someone to remove a Spamhaus listing faster? No. Spamhaus says there is no fee for removing a listing and that third parties cannot influence or expedite removal. Use the official checker process after fixing the cause. ### Can I remove a shared or provider-owned IP myself? No. The provider that controls the address normally owns the investigation and request. Spamhaus says SBL requests must come from the ISP responsible for the listed IP, and its CSS example routes a shared hosting address to the hosting provider. Send the provider the exact result, timestamp, route, and remediation evidence. ### How soon should I resend after removal? Wait for the checker to show the current state, then send one controlled test through the same route. Avoid restarting full volume from a single clean lookup or accepted message. Confirm the original cause is closed and increase traffic only under the sender's normal change controls.