Your ESP's Shared IP Is Dirty. Here’s How to Prove It.

You just hit ‘send’ on the quarterly newsletter. The content is perfect, the segmentation is tight, and your DMARC policy is locked down. Then the first bounce notifications trickle in, and the trickle becomes a flood: `550 5.7.1 Service unavailable; Client host [x.x.x.x] blocked`. You check the IP. It’s not yours—not exclusively. It belongs to your Email Service Provider.

This is the moment every deliverability manager dreads. You’ve done everything right on your end, from SPF alignment (RFC 7208) to DKIM signing (RFC 6376), but your mail is being rejected because of someone else's bad behavior. You're living in a bad neighborhood, and the mail-receiving world is judging you for it.

Shared IP pools are a fact of life in the ESP world. But you are not powerless. What you do next separates a minor hiccup from a catastrophic campaign failure. It requires a methodical approach, hard evidence, and a clear-headed demand for action from your provider.

The Economics of Shared IPs and the Risk You Inherit

Let’s be clear: ESPs don’t use shared IPs to make your life difficult. They do it for economic and operational efficiency. IPv4 addresses are a finite, expensive resource. Pooling allows an ESP to serve thousands of customers with a much smaller block of IPs than if every customer got a dedicated one. For senders with low or inconsistent volume, this is actually a good thing—it allows them to ride on the established, warm reputation of a pool without having to build it from scratch.

The model works on the principle of reputation aggregation. The combined volume of legitimate mail from dozens or hundreds of tenants creates a strong, positive signal. But every model has failure modes. The risk is baked into the name: 'shared'. You share the infrastructure, you share the bandwidth, and you absolutely share the reputation. Your perfectly legitimate mail, sent from an IP also used to blast out questionably acquired marketing lists, looks guilty by association.

This is the operational stake. When a receiving mail server at Google or Microsoft sees an incoming connection from an IP address, the very first check it performs is against its internal blocklists and major public RBLs (Real-time Blackhole Lists). This check happens before it even looks at your `Authentication-Results` header. Before it validates your SPF or DKIM. If the IP itself is toxic, your message is dead on arrival. The gate is closed before you can even state your business.

Connecting the Dots: From Bounce Codes to Blocklist Evidence

Decipher the Rejection Message

Your first piece of evidence is the bounce log itself. Too many analysts treat these as binary failure notices. They are not. They are diagnostic breadcrumbs left by the remote MTA. You need to read the `5xx` SMTP response code and the accompanying text. It’s not just noise; it’s a clue from the scene of the crime.

550 5.7.1 Service unavailable; client [192.0.2.100] blocked using zen.spamhaus.org

This example tells you everything you need to start: the verdict (`550 5.7.1`), the IP address in question (`192.0.2.100`), and the specific RBL that triggered the block (`zen.spamhaus.org`). Your job is to pull a representative sample of these bounces, noting the timestamps and the rejecting MTAs. Are all the bounces coming from Microsoft-hosted domains? Or is it widespread?

Validate Against Primary RBLs

With the IP address identified, your next step is triage against the major, credible RBLs. Not all lists are created equal; some are fringe and not respected by major mailbox providers. Focus on the ones that matter: Spamhaus (SBL, XBL, PBL), Spamcop, and Proofpoint/Cloudmark (CSI). Your goal is to confirm the listing from the bounce message and check for others. Use the public lookup tools provided by these organizations.

A listing on Spamhaus is serious. A listing on three different RBLs is an emergency. Capture screenshots of these listings. Pay attention to the 'first seen' and 'last seen' timestamps. Is this a fresh problem that started this morning, or has this IP been chronically listed for weeks? That context is critical when you talk to your ESP.

Profiling Your Noisy Neighbors with ASN and Geodata

Confirming an RBL listing is step one. Step two is figuring out *why* it might have been listed. While you can't see your neighbors' mail, you can profile the network space they occupy. This adds powerful circumstantial evidence to your case.

The ASN Tells a Story

Every IP address belongs to an Autonomous System (AS), a network operated by a single entity. The AS is identified by its Autonomous System Number (ASN). Running a `whois` lookup on the shared IP will tell you the ASN and the organization that owns it. Why does this matter? Sometimes, a premium ESP will lease additional IP space from a lower-tier provider to handle demand. You might be paying for a top-shelf service but sending from an IP block owned by a budget hosting company notorious for harboring spammers.

If the ASN owner is not your ESP, that's a significant finding. It indicates a more complex supply chain and potentially a much larger pool of unknown, untrusted senders sharing the broader network infrastructure. In your report to the ESP, noting a mismatch between their brand and the ASN owner of the IP they assigned you can add a lot of weight to your request.

Geolocation and Inferred Activity

IP geolocation is not always precise, but it can provide directional clues. If your company operates exclusively in North America and sends to North American customers, but the RBL listing details mention spam campaigns targeting Brazil originating from that IP, you have a strong indicator of a noisy neighbor problem. Services like MaxMind can provide geolocation data.

Some RBLs will even provide general information about the type of abuse detected, such as 'phishing' or 'malware-related'. If the abuse type is wildly out of sync with your own sending practices, that's another piece of evidence. You are building a profile of activity that simply cannot be attributed to your own legitimate mail streams.

From Diagnosis to Demand: Presenting Your Case to the ESP

Armed with data, it's time to contact your ESP. This is not a complaint; it's an incident report. Your tone should be professional, precise, and backed by the evidence you've just gathered. The goal is a swift migration to a clean IP address.

Structure your support ticket or email for clarity. Lead with the business impact. Follow with a chronological summary of your findings. A good structure looks like this:

Start with a clear summary: 'We are experiencing critical delivery failures due to the reputation of shared IP `x.x.x.x`. We request an immediate migration to a new, clean IP.' Collate your evidence into a dossier. Include timestamped bounce logs, direct links and screenshots to the active RBL listings, your ASN and `whois` research, and a concise statement of business impact—'This issue is currently blocking all communications with clients hosted by Microsoft 365, putting our Q4 sales outreach at risk.'

Avoid accusatory language. Frame it as a mutual problem. 'It appears the IP pool our account is assigned to is suffering from a reputation issue that we need your help to resolve.' This makes them a partner in the solution, not a defendant. Any reputable ESP has an abuse desk and a deliverability team that deals with this daily. Your detailed, evidence-based report makes their job easier and makes your request impossible to ignore.

Your New IP Isn't Clean Until You Prove It: A Pre-Migration Audit

Eventually, your ESP will relent and assign you a new IP address. Do not trust it blindly. You must run a pre-flight check before migrating any significant mail volume. Moving from one bad IP to another is a painful and unnecessary exercise.

First, run the new IP through the same RBL checklist: Spamhaus, Spamcop, etc. You're looking for a completely clean slate. Any recent listings are a non-starter; reject the IP and ask for another.

Second, check the IP's historical reputation using tools like Cisco Talos Intelligence or SenderScore.org. An IP with zero history isn't necessarily a good thing; it's 'cold' and needs to be warmed up carefully. An IP with a long but poor historical score is a ticking time bomb. You're looking for an established IP with a consistently good score.

Third, check the reverse DNS (PTR) record. Use `dig -x <IP_ADDRESS>` or an online tool. The PTR record should resolve, and it should point to a hostname that makes sense, typically one containing the ESP's domain name (e.g., `mta-pool-123.esp-domain.com`). A missing, generic, or suspicious PTR record can be a negative signal for some receiving MTAs.

Only after this audit is complete should you begin the warm-up process. Start by sending small volumes of mail to your most engaged segments—the users who are most likely to open and click. This builds positive reputation on the new IP, signaling to mailbox providers that it is a source of legitimate, wanted mail. Never migrate your entire volume to a new IP in one go.

The takeaway

Shared IP reputation problems are a frustrating reality of outsourced email infrastructure. The feeling of being punished for someone else's actions is infuriating. But letting that frustration lead to angry, evidence-free support tickets gets you nowhere. The playbook is diagnosis, documentation, and data-driven escalation.

Your ability to protect your brand's deliverability depends on your ability to act as your own first responder. You must have the skills to parse the technical signals, draw the right conclusions, and advocate for your infrastructure needs. Continuous monitoring is the only way to stay ahead. Tools that can parse and analyze headers like `Authentication-Results` and MTA responses across your entire mail flow, like MailSleuth.AI, can help you spot deliverability fires before they burn down your campaigns.