IP or domain on a blacklist: how to check, understand and get delisted

Reviewed by: Holger D. Erbe, Managing Director of LOGIN SystemHaus GmbH Published: August 2, 2026 Last reviewed: August 28, 2026

Your email stops arriving, and the log mentions a blocklist. This guide shows you how to find out which list is responsible, how delisting works and why it usually only sticks if you fix the cause first.

Check first: which list, which entry

The error message almost always names the list. A typical case looks like this:

554 5.7.1 Service unavailable; Client host [203.0.113.5] blocked using zen.spamhaus.org

That gives you both: the affected IP address and the list. Before you request anything, answer two questions. First: is the address actually yours? If you send through a hosting provider's server, you often share the address with many others, and then the listing is neither your fault nor yours to fix. Second: is the domain affected or the IP? You can recognize a domain block by the fact that sending fails from every address.

The lists that matter

There are dozens, but only a handful are actually used by the large mailbox providers. If you are on an obscure list, you will not notice a thing. There are two kinds to tell apart:

• Public blocklists with clear rules and a removal process. Requesting removal is worth it here.
• Internal ratings at the large mailbox providers. Microsoft, Google and other large providers keep their own assessments that cannot be looked up anywhere. There is usually a form anyway, but the decision is made by an automated process, not a person, and it is based on your sending behavior over the past few weeks.

Steer clear of services that promise delisting for a fee. They do nothing you cannot do yourself.

Requesting delisting, and why it often does not stick

The process is the same for most lists: fill out a form, enter the address, confirm that the cause has been fixed. Many lists also remove entries on their own once nothing suspicious has come from the address for a while.

The mistake almost everyone makes: they request delisting before they have found the cause. Two days later the address is back on the list, and the second request gets more scrutiny than the first. Some lists impose a waiting period after repeated requests without any change in behavior.

Fix the cause: five typical triggers

• Compromised credentials. The most common cause of sudden listings. Someone got hold of login credentials and is sending spam through your server. Rotate passwords and check the log for unfamiliar sender addresses.
• An outdated address list. Lots of unknown recipients are the clearest sign of unmaintained lists for receiving servers. Hard bounces need to be suppressed consistently, see SMTP error codes and bounces.
• Spam traps. Old, abandoned addresses that list brokers put back into circulation. Anyone who emails them has demonstrably not collected their addresses properly. That is exactly why purchased address lists are a deal breaker.
• A sudden jump in volume. Going from 200 emails a month to 20,000 in one day looks like a takeover from the outside. Ramp up volume over several days.
• The neighbor in your IP block. With shared hosting addresses, there is little you can do yourself. That is the point where a dedicated sending path pays off.

Building reputation, explained simply

Reputation is not a setting you configure, but an impression receiving servers form over weeks. They look at how evenly you send, how many recipients do not exist, how often someone clicks "Spam" and whether the From address, SPF and DKIM line up.

So a warmup is nothing mysterious: in the first few weeks, the daily volume is increased step by step instead of sending everything at once. With a sending service, the provider handles this, because it knows the addresses and maintains their history. That is exactly what it is there for.

How MailBridge handles it

Sending runs through well-maintained addresses whose reputation is monitored continuously; warmup, blacklist monitoring and resolving listings are part of the service and included in every plan. Your own server IP no longer appears to the outside world.

In the portal, you see the original reason and a plain-language explanation for every undeliverable message, plus the bounce rate over time. That way, a problem gets noticed before it turns into a listing. How to use it is covered in the guide to bounces and NDRs.

First, find out whether it is a block at all

Not every undelivered message is caused by a blacklist. Before you file any requests, narrow it down:

1. Does it affect all recipients or just one provider? If only messages to a single large provider fail, it is that provider's internal rating and not a public list.
2. Does it affect all senders or just one? If only one address fails, the sender domain is the more likely issue, for example a missing DKIM record.
3. What exactly does the response say? "blocked using" names the list, "policy reasons" does not. The text tells you more than the number code before it.
4. Since when? A clear starting point suggests a specific event: compromised credentials, a bulk send, a server move.

Missing authentication often looks like a block, but it is not one. Delisting will not help then; the guide to SPF, DKIM and DMARC will.

When Microsoft or Google blocks you

These two cases work differently from a public list, because there is no listing you can look up.

• Microsoft often responds with 550 5.7.708 or a reference to its own blocklist. There is a delisting form that works for individual addresses. In repeated cases it is no longer accepted, and then only a different sending path helps.
• Google rarely gives a reason and points to its general guidelines. What matters there is the complaint rate and whether the From address, SPF and DKIM line up. There is a form, but no quick decision.

Both evaluate your behavior over the past few weeks. A request without a change in practice changes nothing.

Prevention is the whole trick

• Suppress hard bounces automatically instead of by hand.
• Increase volume in steps, not jumps.
• Use separate credentials for each application, so one compromised login does not drag down all of your sending.
• Bind the sender domain to the credentials, so that if they are abused, nobody can send in the name of other domains.
• Check your bounce rate regularly. It is the early warning sign that is easiest to miss.