When Your Domain Lands on a Blacklist

A customer wrote in to say the site was down. It loaded fine from the office, from my phone, from the monitor, and from three countries through a VPN. Their screenshot showed the browser insisting the address could not be found, and they were telling the truth.

The domain had been put on a list, and the customer's network was one of the many that consult that list before answering a DNS query. For them, and for everyone on a network like theirs, the domain had stopped existing. For everyone else it was a normal Tuesday.

This post is about that failure. How domains end up on lists, why an unrelated app on a subdomain goes down with the site that caused it, how to find out it has happened, and how to get off the list once it has.

Two kinds of list

People say "blacklist" and mean two different things.

DNS filtering lists are consulted by resolvers that promise to protect their users. Cloudflare's 1.1.1.2, Quad9, AdGuard DNS, OpenDNS, and the filtering built into a great many corporate and school networks all refuse to resolve domains they believe host malware or phishing. A user on one of those resolvers asks for your domain and gets back either nothing (NXDOMAIN) or a placeholder address like 0.0.0.0. Their browser shows "site can't be reached." The resolver operators pull from threat feeds run by security vendors, and a domain flagged by a couple of those feeds gets blocked across all of them within hours.

Mail blocklists such as Spamhaus DBL, SURBL and URIBL are consulted by mail servers and spam filters. A domain on one of those gets its email rejected or shoved into spam, and links to it in other people's email get the same treatment. Some web filters read the mail lists too, so a listing there can bleed into the first kind.

The two overlap in causes and differ in symptoms. A DNS filtering listing makes the site unreachable for a slice of visitors. A mail listing makes you invisible in inboxes. Either can happen without a single failed request from your own monitor, because the monitor uses a clean resolver and never sends email.

How a domain ends up listed

Almost always, something on the domain did something bad. Occasionally it is a mistake. The common causes, roughly in order of how often I have seen them:

The site was compromised and is serving malware or phishing. A plugin with a known vulnerability, a theme bought from a marketplace, an admin password reused from a breached service. The attacker injects a script and your domain starts distributing something nasty. Security scanners notice within days.

The site is sending spam, or something on the server is. A contact form with no rate limiting, a forgotten SMTP relay, a compromised mailbox.

The domain is new, and some lists treat a domain registered last week and already sending email as suspicious by default. This clears itself with time and good behaviour.

A neighbour is bad. Shared hosting means shared IP addresses, and some lists are IP-based. Your domain gets caught in the blast radius of whoever else is on that box.

The domain used to belong to somebody else. Expired domains get re-registered, and the history comes with them.

Something on the domain looks like phishing even though it is legitimate. A login page that resembles a bank's, a subdomain called secure-account-verify, a URL shortener anyone can use. Heuristics catch these.

The case that changed how I think about this

A company I know ran their marketing site on WordPress at example.com, and their actual product, the thing customers paid for, at app.example.com. Different servers, different codebases, different teams. The only thing they shared was the registrable domain.

The WordPress site picked up an injection through an outdated plugin. The injected script showed visitors a fake "verify you are human" checkbox, styled to look like a Cloudflare challenge. Clicking it copied a command to the clipboard and told the user to press a key combination to "complete verification," which ran the command and installed a credential stealer. This campaign has been everywhere since 2024, and it works because the page looks completely ordinary.

Within days the threat feeds had example.com down as a malware distributor. Then the phone calls started, and they were about the app.

Most threat feeds, and nearly all the resolvers acting on them, work at the level of the registrable domain, the part you pay the registrar for. A listing for example.com meant that filtering resolvers refused to answer for app.example.com, api.example.com, and the customer status page, none of which had anything to do with WordPress. Every customer whose office used Quad9 or a filtering firewall lost access to a product that was running perfectly. The first instinct was to look for a bug in the app, and it cost a day.

The marketing site was cleaned in an afternoon. Getting the domain off every list took a great deal longer, and for that whole stretch the product had an availability problem that showed up on nobody's dashboard.

Three lessons came out of it. A marketing site is an attack surface for the product that shares its domain. A monitor that only uses a clean resolver cannot see this class of outage. And the blast radius of a listing is the whole domain, so you want to find out on the first day, while it is one list, because by the tenth it is all of them.

How to tell it has happened

The symptom is that the site works for you and fails for some other people, and the failure is at the DNS stage. Nobody gets an error page from your server, because nobody reaches your server.

You can check by hand. Ask a filtering resolver and a clean one the same question and compare:

dig +short example.com @1.1.1.1       # Cloudflare, no filtering
dig +short example.com @1.1.1.2       # Cloudflare, malware filtering
dig +short example.com @9.9.9.9       # Quad9
dig +short example.com @94.140.14.14  # AdGuard

A clean resolver returns your address. A filtering resolver that has you listed returns 0.0.0.0, or nothing at all. If the answers differ, you are on somebody's list.

For the mail side, look the domain up on Spamhaus, SURBL and URIBL directly. Each has a public lookup page. VirusTotal is useful for the web side because it shows which of dozens of security engines has an opinion about your domain, and therefore whom you need to talk to.

Doing this by hand once is easy. Doing it every day for every domain you are responsible for is why Barkme runs both checks automatically. Web reputation compares the answers from security-filtering resolvers against clean ones, plus Quad9's own attribution data for which threat feed flagged you. Mail reputation queries Spamhaus DBL, SURBL and URIBL. You get one alert when a domain appears on a list, naming the sources, and one when it clears. An inconclusive lookup never counts as a listing.

Getting off the list

The order matters. Fix the cause first. Every delisting form asks whether the problem is resolved, and a domain that gets relisted a week later is treated with much more suspicion the second time.

Clean the site properly

For a compromised WordPress site, "properly" means more than deleting the script you found.

1. Take a backup of the current state for forensics, then assume everything is suspect.
2. Update WordPress, every plugin and every theme. Remove plugins and themes you do not use, including inactive ones.
3. Search the database, particularly wp_options and wp_posts, for injected <script> tags and base64 blobs. Injections frequently live in the database, so scanning files alone misses them.
4. Reinstall core and plugins from clean sources, and compare theme files against the originals.
5. Rotate every credential: WordPress admins, database, FTP or SSH, hosting panel, and any API keys stored in the site.
6. Check for backdoors: unfamiliar admin users, PHP files in the uploads directory, cron entries you did not create.
7. Run a scanner from outside, such as Sucuri's SiteCheck or VirusTotal's URL scan, until it comes back clean.

If that list feels like a lot, it is. It is also why a marketing site with a wide plugin footprint is worth keeping on a domain that does not carry your product.

Ask each list to remove you

There is no central place. Each list has its own process, and each will re-check the domain before removing it.

• Spamhaus DBL. The lookup at check.spamhaus.org shows the listing reason and links to the removal request. Most DBL listings clear within a day of a fix.
• SURBL and URIBL. Both have lookup pages with a removal request. Expect a short questionnaire.
• Google Safe Browsing. The transparency report shows the status. If you are flagged, Search Console's Security Issues section lets you request a review once the site is clean. This one matters more than most, because Chrome, Firefox and Safari all read it.
• Cloudflare. Cloudflare Radar has a domain categorisation feedback form for disputing a classification.
• Quad9. Takes false-positive reports through its support channel, but it aggregates around twenty threat feeds, so the listing usually needs to clear at the source before Quad9 stops blocking.
• AdGuard. Accepts reports through its filter repository on GitHub.
• Everything else on VirusTotal. Each engine has its own reporting address, and VirusTotal's detail page tells you which ones flagged you.

Response times range from a few hours to a couple of weeks. Some lists expire entries automatically once the domain has been clean for a while. Keep checking daily, because entries also reappear when a feed re-scans a cached copy of the old infected page.

While you wait

If the listed domain carries a product on a subdomain, and your customers are the ones who cannot resolve it, you have two options. Tell affected customers to switch their resolver, which is a bad thing to have to say. Or serve the product from a second domain temporarily, which is only possible if you have one ready and the app's configuration allows it.

The second option is why the company in the story now runs its product on a domain with no WordPress on it anywhere.

Reducing the odds

Nothing here is exotic.

• Keep the CMS, plugins and themes current, and delete what you do not use.
• Put the product on a different registrable domain from the marketing site, or at least go in knowing that they share a fate.
• Rate-limit contact forms and anything else that sends email on a visitor's behalf.
• Set up SPF, DKIM and DMARC so your mail is clearly yours.
• Watch the lists every day, so that a listing is caught on day one.

That last point is the whole reason Barkme checks domain reputation. If you want the background on why a resolver gets to decide whether your domain exists, how DNS works covers it. And the other silent failure, certificate and domain expiry, belongs on the same checklist.