My ESP's Shared IP Is Blacklisted: What Can I Do?

If your ESP's shared IP is on a blocklist, the delisting is your ESP's job, not yours. They own the IP, they're the party list operators will deal with, and the major ESPs say in their documentation that they handle it. Your job is to send them the evidence, check honestly whether your own mail is part of the problem, and decide whether shared sending still fits your program.

For the general blocklist playbook, see We Got Blocklisted. For all the list-specific pages, see the blocklists overview.

Why you can't delist a shared IP yourself

Blocklist operators work with whoever controls the listed address. M3AAWG's guidance calls that party the "listee," the one with administrative control over the IP or domain, and notes that ESPs tend to troubleshoot listings on behalf of their customers. Some lists make it formal: Spamhaus handles SBL removals only with the network owner, so a request from one of many customers on a shared IP goes nowhere.

The ESPs agree. Two published examples:

• Twilio SendGrid says that on shared IP plans it handles deny list issues itself, and that for Spamhaus blocks it's already working with Spamhaus directly. It also says it can't move your account to a new IP pool because an IP in your current pool is listed, and that not every listing can be fixed, especially low-impact ones.
• Amazon SES says it monitors the lists that could affect delivery across the service or to major providers, names Spamhaus as one of them, and takes "immediate action" to get its shared IPs removed. It doesn't work listings on lists it considers low-impact, naming SORBS and UCEPROTECT.

On a dedicated IP, it flips. SendGrid asks dedicated IP customers to make the initial delisting request themselves, and Amazon SES says delisting a dedicated IP isn't its responsibility.

First, check whether the listing is hurting you

Shared IPs get listed and delisted all the time, often on lists nobody uses. Before you open a ticket, confirm there's a real problem:

1. Find the bounces. Look in your ESP's delivery logs for rejections that name a list, like blocked using zen.spamhaus.org. Amazon SES gives the typical form:

   554 5.7.1 Service unavailable; Client host [203.0.113.7] blocked
   using DNSBLName
   

2. Count them. One or two bounces at one small domain is noise. A pattern across many receiving domains is a real listing.

3. Check which list it is. A Spamhaus listing matters. A list that only shows up in a checker report usually doesn't. Which blocklists actually matter has the ranking.

If nothing is bouncing, a checker showing your shared IP on some list is not a reason to act.

What to send your ESP

Make it easy for support to route the ticket to their deliverability or compliance team:

• The listed IP and the list name, taken from the bounce
• Full bounce text for a few examples, with timestamps and time zone
• The receiving domains affected and roughly how many messages bounced
• When it started

That's the same evidence M3AAWG recommends including in any listing inquiry, and it saves a round of "can you send us the bounce?"

While you wait, don't resend the bounced mail through the same pool, and don't route around the problem through another account or provider. If you have a smaller, highly engaged segment, mail that first.

Check whether you're part of the cause

A shared pool is listed because of what the pool sent, and every customer on it is a suspect, including you. If your ESP's compliance team asks about your list sources after a pool listing, they're doing the root-cause work, not accusing you.

Look at your own program honestly:

• Recent imports. Trade-show lists, partner lists, old CRM exports, anything not collected through your own opt-in.
• Reactivation sends to people who haven't engaged in a long time. Old addresses are where recycled spam traps live. See why your ESP can't fix your spam trap problem.
• Complaint and bounce rates on your recent campaigns, compared with your normal.
• Signup forms without confirmation or bot protection.

If you keep landing on listed IPs across different pools, the common denominator is more likely your data than your neighbors.

When to escalate

ESP support queues are busy, and a listing that matters deserves follow-up. Reasonable triggers to push harder:

• Bounces naming a major list (Spamhaus especially) are continuing and growing, and support hasn't confirmed anyone is working it
• The listing is costing you a measurable share of a time-sensitive send, like password resets or order confirmations
• Your transactional and marketing mail share the same pool, so a marketing problem is breaking receipts

Escalation paths vary by ESP. If you have an account manager or a paid support tier, use it. Ask specifically whether your traffic can be moved to a different pool (SendGrid says it won't do this for a listing alone), or whether transactional mail can be separated from marketing.

Is a dedicated IP the answer?

Sometimes. A dedicated IP means only your mail affects its reputation. Amazon SES suggests one when a recipient's provider won't make an exception for a listed shared IP. But it also means you own the listings and the delisting requests, and an IP needs enough steady volume for receivers to form a reputation for it. A low-volume sender on a dedicated IP can end up worse off than on a well-managed shared pool. ESPs publish different volume guidelines, so ask yours.

Two cheaper fixes to consider first: separate transactional from marketing mail (different streams or subaccounts), and make sure you're authenticating with your own domain via DKIM, so your domain reputation travels with you. The email checker shows whether your DKIM and DMARC are in place.

How to confirm it's fixed

Ask your ESP to confirm when the listing is cleared, then check the list's own lookup page for the IP. Watch your bounce logs for the next few sends: rejections naming that list should stop. If they don't, reply on the same ticket with fresh bounce examples.

When to get help

If your mail keeps landing on listed shared IPs, or your ESP is pointing at your data and you can't find the problem, an independent review of your list sources and sending practices can settle it faster than another round of tickets. Get in touch.

FAQ

Can I request delisting for my ESP's shared IP myself?

Usually not. List operators deal with whoever controls the IP, and some, like the Spamhaus SBL, only accept requests from the network owner. Send the bounce to your ESP and let them file.

Will my ESP move me to a different IP pool?

Don't count on it. SendGrid says it won't move an account just because an IP in its shared pool is listed. Ask, but plan for the listing to be worked rather than avoided.

Is it my fault the shared IP got listed?

Not necessarily, but you can't rule it out. Check your recent imports, reactivation sends and complaint rates before assuming it's a neighbor.

Should I switch ESPs because of a shared IP listing?

Not over a single listing. Every shared pool gets listed sometimes. If listings keep affecting your delivery and your own data checks out, then it's fair to compare how providers manage their pools.