Free tool
Two questions everyone runs together, asked at once. Anti-spam blacklists decide whether your email arrives; Google Safe Browsing decides whether Chrome puts a red screen in front of your site. A domain can be spotless for one and flagged by the other.
The mechanism
“My domain is blacklisted” covers two systems that never talk to each other: the one a mail server queries before it accepts your message, and the one a browser checks before it shows your page. Start from what you're actually seeing — the circuit involved lights up.
Anti-spam blocklists (DNSBL)
What gets judged: the sending IP, and sometimes the domain — never your website's content.
Safe Browsing
What gets judged: your site's addresses — never your mail server.
Pick what you're seeing: the circuit at fault lights up, the other one fades.
The two systems are independent. Getting off one changes nothing on the other, and a domain can be perfectly clean on one side and flagged on the other.
A listing always turns up after the fact. By the time you think to open this page, mail has been bouncing for three days, or Chrome's red screen has been sitting in front of your client's site since morning. The question isn't whether you're listed today, it's who tells you the day it happens. DomainVigil queries these same lists around the clock and writes to you within the hour.
A mailbox whose password leaked and now sends spam in your name. A compromised WordPress site hosting a phishing page you know nothing about. A shared-hosting neighbor whose IP address is also yours. An unprotected contact form turned into a relay. In all four cases you're listed for mail you never sent, and a removal only holds once the cause is fixed.
What this check queries
Four numbers say what gets tested — and why a domain can be green on one side and red on the other.
7
Blacklists queried
Two answer on the domain name, five on the IP addresses. SORBS was dropped when it closed in June 2024: its silences would have read as “nothing flagged”.
6
Addresses tested at most
Your site's address, plus your mail servers'. The one that ends up listed is almost always a mail address, not the site's.
24h
The removal that happens on its own
Roughly twenty-four hours after the last report, at SpamCop, with nothing to ask for. PSBL removes you self-service; UCEPROTECT level 1 expires seven days after the last recorded abuse.
4
Addresses submitted to Google
The domain and “www”, over http and over https. That check says nothing about your email — it says what three browsers show in front of your pages.
The seven lists and the six addresses are what this check does, identical to the product's own monitor. The removal delays are the ones each list's operator publishes, repeated in the table below.
Three states per list, four for Google. None of them follows from another.
A removal you got without fixing the cause does not last a week.
What causes it: The list drops the entry, the machine keeps sending, and the listing comes back. Most lists stretch the delay a little further with each repeat.
What fixes it: Find what's sending first: the mail server logs, the queue, the accounts whose passwords leaked. Removal comes after that.
What causes it: There are two families of list. Domain lists answer on the name, address lists on the IPs. A check that only tests the name misses the most common case of all.
What fixes it: This tool tests both, and shows on the right which addresses actually went out. A listed mail server IP blocks mail without touching the site.
What causes it: Plenty of public tools show a green check when the query fails. Spamhaus, for one, turns away queries from a public resolver and returns a usage code — which looks exactly like not being listed.
What fixes it: We keep the three states apart. A silent list shows in gray, never in green, and the finding says so.
What causes it: On shared hosting, your site shares its IP with dozens of others. One of them sending spam is enough to get the address listed, and yours with it.
What fixes it: Compare the listed address with your site's. If it's a shared address, the removal request isn't yours to make: take it to your host, or ask for a dedicated address.
What causes it: Google doesn't lift a flag on its own the same day. It waits for a review request, then checks again.
What fixes it: Open Search Console for the domain, go to “Security issues”, and request the review once the site is clean. While the malicious page is still being served, the request gets refused.
A short, documented set — the same one the product's own monitor uses. Dead lists get dropped: SORBS closed in June 2024 and no longer answers, so its silences would read as “nothing flagged”.
| List | What it lists | What it punishes, and how you get out |
|---|---|---|
| Spamhaus ZEN | IP addresses | The most widely used list in the world. It merges four databases: known spam source, misconfigured server, infected machine, and residential ranges that have no business sending directly. Removal at check.spamhaus.org. |
| Spamhaus DBL | Domains | The name itself: spam, phishing, malware, botnet command and control. A separate code marks a legitimate domain that has been abused, which is what a compromised site looks like. Removal at check.spamhaus.org. |
| SpamCop BL | IP addresses | Fed by user reports. Delisting is automatic roughly 24 hours after the last report, which makes it the most forgiving — and the quickest to come back if the cause is still there. |
| Barracuda | IP addresses | Reputation measured by Barracuda across its own gateway network. Removal requests are handled in about twelve hours. |
| SURBL multi | Domains | Domains CITED inside spam, even when the message itself came from somewhere else. It separates phishing, malware, cybersquatting and abuse. Analysis and removal at surbl.org. |
| PSBL | IP addresses | Fed by spam traps: an address writing to a mailbox that never existed. Immediate self-service removal at psbl.org. |
| UCEPROTECT level 1 | IP addresses | The address on its own, and it expires seven days after the last recorded abuse. Levels 2 and 3 list whole ranges and entire autonomous systems — too coarse to say anything about a single domain, so we don't query them. |
Google Safe Browsing is not an anti-spam blacklist and doesn't play in the same league: it decides nothing about your email, it decides what three browsers show in front of your page. The four addresses submitted are the domain and “www”, over http and over https.
Type it in above. Seven lists get queried: two against the domain name, five against the IP addresses of the site and the mail servers. Each list returns one of three states, and a list that didn't answer shows in gray — never in green.
Blacklists are only part of the decision. Incomplete authentication weighs more: no SPF, DMARC left at “p=none”, no DKIM signature. A brand-new domain counts too, because it has no sending history. Check authentication with the dedicated tool before you look any further.
It depends on the list. PSBL removes you immediately, self-service. SpamCop clears on its own about 24 hours after the last report. Barracuda handles a request in about twelve hours. UCEPROTECT level 1 expires seven days after the last abuse. Spamhaus reviews the request. In every case, a removal you got without fixing the cause comes straight back.
First find and remove whatever got flagged: a phishing page dropped into a compromised site, an injected script, a file uploaded through an unchecked form. Then open Google Search Console for the domain and request a review under “Security issues”. While the content is still being served, the request gets refused.
Because a listed mail IP blocks your email without touching the site, and that's the most common case. Plenty of tools only test the site's address, the one in the A record, which isn't the one that sends. We resolve your MX records and test their addresses too.
No, it's the absence of news. The major lists rate-limit and turn away queries from a public resolver: their answer is then a usage code that plenty of tools paint green. We show it in gray, and the finding under the table counts how many lists are affected.
The timeline
Six moments, and each time the lead everyone follows first. It's wrong every time, and it costs the morning.
What you conclude : The mail server is down.
What's happening : A 5xx is a refusal from the server at the other end, not a failure of yours. 5.7.1 is the classic policy refusal, and the text right after it almost always carries the name of the list and the address of the removal form.
What you conclude : The problem is on their end.
What's happening : Every provider picks which lists it consults. A listing hits the ones following that particular list first, then spreads as others pick it up. Silence from the first two is not a clean bill of health.
What you conclude : We're not listed, the cause is somewhere else.
What's happening : There are two families of list, and they answer different questions. Domain lists answer on the name; address lists answer on the IP that sends — and that's almost always the one listed. A check that only tests the name misses the case that comes up most.
What you conclude : Done.
What's happening : Nothing has been fixed. If the machine is still sending, the relisting lands before the end of the day, and most operators stretch the delay with each repeat. A removal you got too early costs more than half a day of waiting.
What you conclude : Password changed, problem solved.
What's happening : The server queue still holds thousands of messages ready to go. While it drains, the address keeps sending spam and keeps getting relisted. Purge the queue first, then ask for removal.
What you conclude : The domain is clean.
What's happening : For mail, yes. If the site had been flagged in a browser, that warning wouldn't have moved a pixel: different system, different form, different delay. The diagram above separates the two desks.
Worth bookmarking
Every bounce carries two codes: the three-digit one, which says whether the refusal is temporary or final, and the three-part enhanced code, which says why. The second is the only one that tells you anything.
| Code | What it means | What it says about your reputation |
|---|---|---|
| 421 | Service unavailable, the connection is closing. | Temporary refusal. Almost always a rate limit: too many connections, too many messages in too little time. Your server is supposed to retry later — and if your mail never arrives, yours is the one giving up too early. |
| 451 4.7.1 | Temporary refusal on policy grounds. | Usually greylisting: the server refuses a first attempt from an address it doesn't know, then accepts the same message minutes later (RFC 6647). Says nothing about a listing. |
| 550 5.1.1 | The recipient's mailbox does not exist. | No direct bearing on reputation — but a sending list full of dead addresses wrecks it on its own. It's the easiest signal to clean up. |
| 550 5.7.1 | Delivery not authorized, message refused. | The classic policy refusal, and the one most listing refusals arrive under. All the value sits in the free text that follows: name of the list, address of the form, sometimes the offending IP. |
| 550 5.7.23 | The SPF check failed. | Your SPF record doesn't authorize the address that sent. Nothing to do with a listing: it's a missing authorization, and you fix it in your zone in minutes. |
| 550 5.7.25 | Reverse DNS validation failed. | The sending IP has no reverse name, or that name doesn't point back to it. Plenty of providers make it a condition of entry, and your host publishes that name, not you. |
| 550 5.7.26 | More than one authentication check failed. | SPF and DKIM both fail. It's the code you get when the sending domain asks for rejection on failure, or when the receiving provider applies its own rule to unauthenticated mail. |
| 554 5.7.1 | Transaction failed, after the message was sent. | The refusal landed after the content was read, not at connection time: content, signature, combined reputation. A 554 differs from a 550 in when it happens, and it points at the message rather than at the address. |
The first digit decides: 4xx is temporary and will be retried, 5xx is final (RFC 5321, § 4.2.1). Enhanced codes are defined in RFC 3463 and extended for authentication by RFC 7208 and RFC 7372; IANA's “SMTP Enhanced Status Codes” registry keeps the list current. Providers append whatever text they like after the code — and that's the part carrying the removal link.
Where the tool stops
Seven lists and a safe browsing service answer one precise question: are you on a public list. They answer none of the ones below, and an all-green result doesn't cover them.
The right party
Half of all removal requests go to the wrong place. Here's what each party actually holds, and the sentence it will never say.
The vocabulary
They turn up in the bounce, in the removal form, on the operator's page. Not one of them is explained there.
DNSBLSafe Browsingsilent listdelisting550 5.7.1greylistingreverse namefeedback loopA removal you got without fixing the cause does not last a week.