Blacklisted Domain or IP: Diagnosis, Cleanup & Delisting

A blacklisting is unusual among security findings because it is a consequence rather than a vulnerability. Something already went wrong — a compromise, a misconfiguration, or a sending practice recipients rejected — and the listing is the internet's response. That makes the order of operations critical: delisting before fixing the cause almost always ends in relisting, on worse terms.

This guide is platform-agnostic. It applies whether you run WordPress, a custom application, a static site or nothing but a mail domain.

What a Listing Actually Costs You

The damage is disproportionate to how quietly it starts:

• Email stops arriving. Not bouncing visibly — frequently just filtered to spam or silently discarded. Password resets, order confirmations, invoices and support replies vanish, and you find out through customer complaints days later.
• Browsers may block your site outright. A Google Safe Browsing listing shows a full-page red interstitial in Chrome, Firefox and Safari. Traffic does not decline — it stops.
• Reputation compounds. Mailbox providers weigh listings when scoring future mail, so a listing that lasted three days can depress delivery for weeks after removal.
• It follows the asset. A listed IP stays listed for the next tenant; a listed domain carries the history even after you move hosts.

The cruelty of a mail blacklisting is that everything appears to work. Your server reports the message as sent. Nobody receives it.

Two Different Systems People Confuse

Before diagnosing anything, know which of these you are dealing with, because the appeal paths, timelines and fixes differ entirely:

• Mail blocklists (DNSBLs). Spamhaus, Barracuda, SORBS, SpamCop and others. They list sending IPs and sometimes domains, and affect message delivery. Removal is usually a request to the list operator, and many entries expire automatically once abuse stops.
• Web reputation systems. Google Safe Browsing, Microsoft SmartScreen, and vendor malware feeds. They flag sites serving malware, phishing or unwanted software, and affect browsing and search. Removal requires a review request after cleanup.

Our scanner reports domain and IP reputation findings from the mail-blocklist side. If visitors are seeing a browser warning, you are dealing with the second category as well, and should treat that as the more urgent of the two.

Step 1: Find Every List and the Stated Reason

Do not guess. Each list publishes why it listed you, and the stated reason determines the entire remediation path — a compromised-server listing and a spam-complaint listing require completely different work.

# Which IP does your mail actually come from? (not always your web server)
dig +short A yourdomain.com
dig +short MX yourdomain.com

# Query a DNSBL directly: reverse the IP octets and append the list's zone.
# For IP 203.0.113.45 on Spamhaus ZEN:
dig +short 45.113.0.203.zen.spamhaus.org

# Any 127.0.0.x answer means LISTED. No answer means not listed.
#   127.0.0.2  SBL   — direct spam source
#   127.0.0.3  CSS   — snowshoe spam
#   127.0.0.4  XBL   — compromised machine / exploited device
#   127.0.0.10 PBL   — residential/dynamic range, not authorized for direct mail

# Read the reason record
dig +short 45.113.0.203.zen.spamhaus.org TXT

Then check the lookup pages that aggregate dozens of lists at once — Spamhaus, MXToolbox and MultiRBL all offer this — plus the two reputation surfaces that affect browsing:

• Google Search Console → Security Issues. The authoritative source for a Safe Browsing action, and the only place you can request review.
• Google Postmaster Tools → domain and IP reputation, spam rate. Essential for Gmail delivery, and it requires DKIM to be configured to show data.
• Microsoft SNDS → equivalent visibility for Outlook and Hotmail.

Step 2: Diagnose the Root Cause

Five causes account for nearly every listing we see. Work through them in order of likelihood:

1. A compromised site or server. Injected code sending mail directly, or a web shell used as a relay. Signature: a listing on your web server IP, unexplained outbound connections on port 25, and a mail queue full of messages nobody in your organization composed.
2. A compromised mailbox. A stolen or brute-forced password used to relay through your legitimate mail server. Signature: authenticated sending from one account at implausible volume, often from unfamiliar geographies, at unusual hours.
3. An open relay or abusable form. A mail server accepting mail from anyone, or a contact form that lets a submitter control recipients and content. Signature: high volume with no authenticated user attached.
4. Shared-IP contamination. On shared hosting or a shared sending pool, a neighbour's behaviour lists the IP you both use. Signature: you find nothing wrong, and the listing reason references activity you cannot correlate with your own logs.
5. Legitimate mail, poorly received. Real marketing to a purchased or stale list, generating complaints and spam-trap hits. Signature: no compromise, a listing citing complaint rates, and a marketing send that correlates in time.

Practical checks, whatever your platform:

# Is your server sending mail you did not author?
mailq | head -50                       # Postfix queue
exim -bp | head -50                    # Exim queue

# Who is sending, and how much?
grep "from=" /var/log/mail.log | awk '{print $7}' | sort | uniq -c | sort -rn | head

# Outbound SMTP connections from a web server are a red flag
ss -tanp | grep ":25"

# Files modified recently — a fast compromise indicator
find /var/www -type f -mtime -7 -name "*.php" | head -40

# Are you an open relay? (test from OUTSIDE your network)
swaks --to test@example.com --from test@example.org --server yourmailserver.com

Step 3: Remove the Cause Completely

This is the step that determines whether delisting holds. Match the work to the cause you identified.

If the server or site was compromised:

1. Take it offline or block outbound port 25 immediately, so abuse stops while you work. Continued abuse resets any progress with list operators.
2. Find and remove the malicious code. Compare against a known-good deployment or restore from a clean backup taken before the compromise. Manual cleanup risks leaving a second backdoor — attackers rarely install only one.
3. Close the entry point. An outdated component, a weak administrative password, an exposed configuration file, a vulnerable upload handler. If you do not find the door, you will be cleaning again shortly.
4. Rotate every credential the server could reach: mail accounts, database, hosting panel, API keys, SSH keys. Assume everything on that machine was read.
5. Patch and harden before returning it to service.

WordPress specifically has its own cleanup path — our WordPress malware removal guide covers it in detail. For other stacks the principles above are the same; only the file locations change.

If a mailbox was compromised: reset that password, enable multi-factor authentication, revoke active sessions and app passwords, and check for a forwarding rule or filter the attacker left behind — a persistent mail-forwarding rule is the most commonly missed artifact of a mailbox takeover.

If you are an open relay or have an abusable form: restrict the mail server to authenticated senders and your own networks, and ensure no form permits the submitter to control recipients, headers or arbitrary content.

If the cause was sending practice: stop the campaign, remove non-engaged and purchased addresses, implement confirmed opt-in, and honour unsubscribes immediately. No technical fix compensates for mail people did not ask for.

Step 4: Verify Before You Ask

Prove the problem is gone before submitting anything. Operators check, and a request submitted while abuse continues is worse than no request at all.

• Watch the mail queue for 24 hours. It should contain only mail you can account for.
• Confirm no outbound port 25 traffic from servers that should not send mail.
• Re-scan the site for injected code, and confirm no malicious files have reappeared — reappearance means a backdoor remains.
• Verify SPF, DKIM and DMARC pass by sending a test to a mailbox you control and inspecting the received headers.
• Confirm you are not an open relay from outside your network.

Step 5: Submit Delisting Requests

Each list has its own process. General principles first, because they matter more than the specific form:

• Submit once. Repeat submissions push you to the back of a manual queue and signal panic rather than diligence.
• Be specific and honest. "We identified a compromised WordPress plugin, removed the injected mailer, rotated all credentials, patched to 6.5 and blocked outbound port 25 from the web tier" is credible. "Please remove, we did nothing wrong" is not, and operators read a great many of the latter.
• Never claim a false positive unless you have genuinely verified it. Operators keep records, and a false claim costs you the benefit of the doubt on every future listing.

Where to go:

• Spamhaus — the Blocklist Removal Center handles SBL, XBL and PBL. XBL entries frequently clear automatically once the infection stops; PBL entries are usually resolved by your ISP or by sending through a proper relay rather than directly.
• Barracuda, SORBS, SpamCop, UCEPROTECT — each publishes its own removal form. SpamCop entries expire automatically once reports stop.
• Google Safe Browsing — Search Console → Security Issues → Request Review. Describe the cleanup concretely. Review typically completes within one to three days for a genuinely clean site.
• Microsoft — Outlook.com deliverability support handles Outlook and Hotmail blocks; SNDS provides the diagnostic data to support the request.
• Your hosting provider — if the IP is shared, they must act. Ask them directly whether the listing originates from a neighbour, and if it recurs, request a different IP or move to a dedicated sending address.

Step 6: Rebuild Reputation

Delisting restores permission to deliver. It does not restore reputation, and this distinction explains why many teams believe the problem persists after removal.

1. Resume at low volume. Start with your most engaged recipients — people who open and reply. Positive engagement is the strongest recovery signal available to you.
2. Increase gradually. Roughly double daily volume every few days rather than returning to full send immediately. Providers evaluate trend, not absolute volume.
3. Watch complaint rate. Google Postmaster Tools and SNDS both report it; aim well below 0.1%. Above 0.3% you are heading back toward a listing.
4. Separate your streams. Send transactional mail (password resets, receipts) from a different subdomain and IP than marketing. This way a marketing problem never blocks a password reset, which is the failure that generates support tickets and lost accounts.
5. Move DMARC toward enforcement. Progress from p=none to p=quarantine to p=reject as your reports come back clean, so nobody can spoof you into another listing.

Preventing the Next One

• Monitor continuously. Listings are silent — you will not notice until customers complain. Automated blocklist checks turn a three-week outage into a same-day fix.
• Block outbound port 25 from any server that has no reason to send mail directly. This single control prevents most compromise-driven listings from ever reaching a list.
• Enforce DMARC so your domain cannot be spoofed into someone else's spam run.
• Use a reputable sending provider for bulk mail rather than sending from your web server, and keep transactional and marketing streams separate.
• Keep everything patched. The overwhelming majority of compromise-driven listings begin with an outdated component — see our website security checklist.

Frequently Asked Questions

How long does delisting take?

It depends on the list and on whether the cause is genuinely fixed. Automated lists often clear within hours to days once abuse stops, and some expire on their own. Manually reviewed lists can take several days. Google Safe Browsing usually reviews a clean site in one to three days. Mailbox-provider reputation is separate and slower — earned back over weeks of consistent, low-complaint sending.

Should I request delisting immediately?

No. Request removal only after the cause is fixed and verified. Delisting a still-compromised server leads to prompt relisting, and repeated cycles damage your standing with the operator, who may then impose longer minimum listing periods.

Why am I blacklisted if I never send spam?

The common causes involve no intentional sending: a compromised site relaying mail, a stolen mailbox password, an open relay or abusable form, a neighbour on a shared IP, or a missing SPF/DMARC policy that let someone spoof your domain. The abuse is real even though you did not author it.

Does a blacklisting affect my website too?

It can. Mail blocklists mainly affect delivery. Web reputation systems like Google Safe Browsing affect browsing directly — a full-page red warning in Chrome, Firefox and Safari that removes almost all organic traffic while active. Check both categories; the remediation and appeal paths differ.

My host says the listing is not their fault. What now?

If you have verified your own systems are clean and you are on a shared IP, the listing is likely a neighbour's. Ask your host directly to confirm the source and act on it. If it recurs, that is a strong argument for a dedicated IP, or for routing mail through a reputable sending provider so your delivery no longer depends on shared-IP behaviour.