Home › Guides

Shared Hosting IP Blacklisted? What You Can Fix and What You Can't

Published 2026-11-03 ／ Updated 2026-11-03 ／ By Yuki Nakazawa

When a shared hosting IP is blacklisted, the first job is to establish who controls that IP and exactly which list it is on, with which return code. Then clean up anything on your own side and send your hosting provider the lookup evidence so they can act. On a shared IP, the cause may be another customer entirely, and for some lists only the network owner can request removal.

A freshly provisioned VPS or cloud IP can also look "blacklisted" from day one, either because of a previous user's history or because the range is listed as one that should not send mail directly. Whatever the situation, the decision to delist always rests with the list operator.

This guide is based on the official pages of Spamhaus, AWS, Google Cloud and Microsoft Azure as of November 2026. Restrictions and procedures change, so confirm the current wording before you act. For the broader picture of blacklist-related bounces, see our guide to email blocked by blacklists.

Start by working out which IP, and which list

"My server is blacklisted" can mean very different things, and the fix depends on the details. Answer three questions before doing anything else.

1. Which IP actually sends your mail? The IP hosting your website is not necessarily the one that delivers your email. Read the bounce message, which often quotes the rejected IP, and check the Received headers of a message you sent to confirm the real outbound address.
2. Who controls that IP? On shared hosting it is an address shared with other customers. On a dedicated server, VPS or cloud instance it is assigned to you, though the surrounding range still belongs to the provider. Your hosting plan or control panel will tell you whether your outgoing mail uses a shared address.
3. Which list is it on? Lists differ in meaning and in who can fix them. Run the IP through our blacklist checker to see every major list at once, and write down the list names and return codes.

Once you have those three answers, it usually becomes clear whether this is something you fix yourself, something your provider has to fix, or a sign that you should change how you send mail altogether.

Reading lookup results and return codes

Spamhaus ZEN (zen.spamhaus.org) is Spamhaus's combined IP list. A listed IP returns an address in the 127.0.0.x range, and the last number tells you which underlying list matched. For shared hosting and cloud IPs, these are the codes worth telling apart:

A PBL entry is not an accusation. It is a policy statement that mail from this address should be submitted, with authentication, to a server that relays it onward. Spamhaus actively encourages ISPs and other networks to list every range that should not send mail, and that explicitly includes web servers.

The codes 127.255.255.252, 127.255.255.254 and 127.255.255.255 are errors, not listings. Spamhaus's DNSBL usage FAQ also warns that a free public resolver such as Google Public DNS (8.8.8.8) will in most cases return "not listed", which is why different tools can disagree. When in doubt, check the result on Spamhaus's own reputation checker. For the full per-list procedures, see how Spamhaus removal works.

What you can fix yourself and what you can't

How much you can change depends on what you are paying for.

Ruling out your own account on shared hosting

• Compromised mailboxes. Look through sending logs and sent folders for bursts of mail you did not send. Change passwords immediately if you find any.
• A hacked website. Outdated CMS installs and plugins are a common way for attackers to upload mail-sending scripts.
• Abused forms. Contact forms whose auto-reply lets a visitor choose the recipient or body text can be turned into a spam cannon.
• List quality. Sending to purchased lists or to addresses that never opted in is a reliable way to damage a shared IP for everyone, including yourself.

If none of this turns anything up, the likely cause is someone else on the same address. Spamhaus's port 25 FAQ makes the point bluntly: on shared IP pools, most of the people affected by a listing are not the ones with the infected device. In that case your part is to collect the evidence and hand it to the provider.

How to report it to your hosting provider

Spamhaus states that SBL removal requests must be sent by the ISP in charge of the listed IP, and it tells general users to speak to their ISP for remediation. For a shared hosting customer, that ISP is your hosting company. A support ticket that only says "my email is not arriving" tends to bounce around. A ticket that includes the following usually moves faster:

1. The sending IP, as confirmed from the headers or the bounce.
2. The list and the return code, for example zen.spamhaus.org returning 127.0.0.2.
3. When you checked and with what, including what the official reputation checker showed if you used it.
4. The bounce text, specifically the line where the receiving server explains the rejection.
5. What you have already ruled out, such as password resets and a clean site scan.
6. What you are asking for: investigation, a removal request to the list operator if appropriate, or moving your account's outbound mail to a different IP.

A short example:

Our outbound IP 192.0.2.10 returns 127.0.0.2 (SBL) on zen.spamhaus.org.
We confirmed this on the official Spamhaus checker at 10:00 UTC on 2026-11-03.
We have reset all mailbox passwords and found no unexpected files on our site.
Please investigate, request removal if appropriate, or advise whether our mail
can be sent from a different IP.

Your provider may need time, and even once they act, the list operator makes the final call. If you have mail that cannot wait, look at the relay option described below as a parallel workaround. If you are stuck working out where the problem lies, you can also ask us for help.

Port 25 restrictions and reverse DNS on VPS and cloud

If you run your own mail server on a VPS or cloud instance, you may hit a problem before any blacklist comes into play: many providers restrict outbound TCP port 25, the port used for server-to-server mail delivery. The official documentation of AWS, Google Cloud and Microsoft Azure says the following.

• Amazon EC2 (AWS). By default, EC2 allows outbound port 25 traffic only to private IPv4 addresses; traffic to public IPv4 and IPv6 addresses is blocked. You can request that the restriction be removed. For email to third parties, AWS recommends provisioning Elastic IP addresses and assigning static reverse DNS records to them, noting this can help avoid mail being flagged as spam. A forward DNS (A) record resolving to the Elastic IP must exist before you create the reverse record.
• Google Cloud (Compute Engine). Egress to TCP port 25 on external IP addresses is blocked by default. The block is removed automatically when Google Cloud determines a project is low risk, and you can check a project's status via a banner on the VPC networks or firewall policies pages in the console. SMTP over TLS on ports 465 and 587 is excluded from the block. Google recommends using a trusted third-party email provider, which it says improves your IP reputation.
• Microsoft Azure (virtual machines). Outbound port 25 is blocked for every subscription type other than standard Enterprise Agreement and Microsoft Customer Agreement for enterprise (MCA-E). Enterprise Dev/Test subscriptions are blocked by default but can be exempted through the diagnostic in the portal. Authenticated SMTP relay services, typically on port 587, are not restricted for any subscription type, and Microsoft recommends them. Even where port 25 is open, Microsoft notes there is no guarantee external domains will accept the mail.

A blocked port 25 is a delivery problem, not a reputation problem, and opening the port does nothing for your IP's standing. If you do want a Spamhaus PBL exclusion for a cloud or VPS address, the IP must be static, actually run an outbound mail server, have proper forward and reverse DNS, and be assigned to you. Spamhaus also requires that outbound port 25 be closed for every other device behind it.

Switching to a dedicated IP or an authenticated SMTP relay

If a shared IP keeps getting dragged down by its neighbours, or your cloud provider will not open port 25, changing how you send is often more practical than chasing delistings.

An external, authenticated SMTP relay

Instead of your server delivering mail straight to the recipient, it hands each message to an authenticated sending server that delivers it on your behalf. This is exactly the model Spamhaus describes for PBL-listed ranges: mail is expected to be submitted with authentication to a relay, which can be run by the connecting ISP or by an external mail service. Spamhaus's port 25 FAQ adds that end users should be using ports 587 or 465 with SMTP AUTH. Azure and Google Cloud both recommend authenticated relay or third-party email services, and Microsoft notes such services are used in part to maintain the IP reputation that delivery depends on.

• Configure the relay's host name, port (587 is typical) and credentials as your provider documents them.
• Update your domain's SPF record to include the relay and set up DKIM signing for it. See how to set up SPF, DKIM and DMARC.
• Check the relay's sending limits before you move high-volume mail onto it.

A dedicated IP

A dedicated IP insulates you from other customers' behaviour, but it is not an automatic reputation upgrade. Spamhaus's sender guidelines list the factors that influence reputation, including the service provider, the IP neighbourhood, the infrastructure behind the address and the IP's history.

• New addresses get extra scrutiny. The same guidelines say HELO domains without sending history are subject to additional filtering, and that a changed IP or HELO hostname should be treated as new and warmed up gradually. Warm-up services that generate artificial traffic are prohibited.
• Set meaningful reverse DNS. Spamhaus warns that generic or auto-generated reverse DNS on dedicated IPs can hurt reputation.
• Check the new IP before you use it. An address can carry a listing from its previous user, so look it up before you start sending.

Preventing it from happening again

• Align hostname, HELO and reverse DNS. Spamhaus's CSS FAQ says the forward DNS of your IP should match the HELO value set on your server and that HELO should be a fully qualified domain name. It names values such as localhost.localdomain as common mistakes.
• Limit port 25 to mail servers. On a VPS that also runs other workloads, close outbound port 25 for anything that is not your mail server.
• Keep sites and accounts locked down. Update your CMS and plugins, stop reusing passwords and turn on two-factor authentication where you can.
• Review your control panel's outgoing mail settings. The CSS FAQ describes a Plesk option that puts each domain's own name in the SMTP greeting. It warns that when more than one domain on the server shares an IP, mail from some or all of those domains can be marked as spam by receivers that use the Spamhaus XBL, and that the option should be used with extreme care. Check the equivalent setting in your own panel and follow your provider's or panel vendor's guidance.
• Monitor regularly. A shared IP can change status because of someone else's actions. Check it periodically with our blacklist checker and tell your provider early when something changes.

Even after a delisting, receivers apply their own filtering, so delivery may not recover immediately. CSS listings normally expire about three days after the last detection, but the IP is listed again if the problem is still detected, and self-removals are limited.

FAQ

Official pages used

The facts in this article were checked against the official pages below at the time of publication. Policies and behavior change without notice, so check the official pages before relying on anything important.

• Spamhaus: Policy Blocklist (PBL)
• Spamhaus: Spamhaus Blocklist (SBL)
• Spamhaus FAQ: DNSBL Usage (return codes and public resolvers)
• Spamhaus FAQ: Combined Spam Sources (CSS)
• Spamhaus FAQ: Port 25 General Questions
• Spamhaus: Sender Guidelines
• AWS: Amazon EC2 service quotas (Restriction on email sent using port 25)
• AWS: Create a reverse DNS record for email on Amazon EC2
• Google Cloud: Sending email from an instance
• Google Cloud: VPC firewall rules (Blocked and limited traffic)
• Microsoft Learn: Troubleshoot outbound SMTP connectivity in Azure

Related guides

All guides →