Most mid-tier and lower-tier ESP plans send mail through shared infrastructure by default. Your emails leave from an IP address, or sometimes a shared subdomain, that other customers on the same plan tier are also sending from. Dedicated IPs exist, but they're usually an upsell, and plenty of senders never realize they're on shared infrastructure at all until something goes wrong that authentication and content checks can't explain.
This is the cause I check for last in the rule-out order I use, not because it's rare, but because it's the one hardest to fix from your side, and because it needs authentication and your own reputation to already be confirmed clean before it makes sense to suspect. If SPF is misaligned or your own sending has real complaint issues, that's the more likely explanation, and it's yours to fix directly. A shared pool problem only becomes the leading suspect once those are ruled out.
Mailbox providers score reputation at the IP level, not just the domain level. When you share an IP with other senders, Gmail, Outlook, and Yahoo are watching the combined sending behavior of everyone on that IP, not isolating your traffic from theirs. If another customer on the same pool sends to a purchased list, generates a spike in spam complaints, or hits spam traps, the reputation damage attaches to the IP itself, and every sender using that IP inherits some of it.
The part that makes this genuinely hard to diagnose from the outside is that your own sending can be completely clean, good engagement, correct authentication, an opted-in list, and you'll still see placement drop, because the signal mailbox providers are reading includes traffic you have no visibility into and no control over.
This is where most senders go wrong, in both directions. Some blame a shared pool for a problem that's actually theirs, because it's a convenient explanation that doesn't require examining their own list or content. Others never consider it as a possibility and spend weeks investigating their own setup for a problem that was never there to find.
The fix isn't always a platform migration. Some ESPs offer dedicated IP add-ons or smaller, better-managed pools without requiring a full move. That's usually the first thing to check, since it's faster and lower-risk than migrating entirely. If that isn't available, or the pool's reputation is chronically poor because the ESP isn't actively managing who's on it, moving to a different platform or a dedicated IP is worth the cost, but only once you're confident the pool is the actual cause and not a convenient place to point at a problem that's really yours.
Dedicated IPs aren't automatically the right answer either. At low or inconsistent sending volume, a dedicated IP can perform worse than a well-managed shared pool, because mailbox providers don't have enough consistent history on it to build real confidence either way. This is a volume and consistency decision, not a blanket upgrade.
Part of the deliverability diagnosis guideAsk your ESP directly whether your sending IP or subdomain is dedicated or shared. Many lower and mid-tier plans default to shared infrastructure without stating it prominently. If they can't answer that quickly and specifically, that tells you something on its own.
Not for every sender. A dedicated IP puts your reputation entirely in your own hands, which helps once you have enough consistent volume to build a strong history on it. At low or inconsistent volume, a dedicated IP can actually perform worse than a well-managed shared pool.
Sometimes. Some ESPs offer dedicated IP add-ons or better-managed pools without a full migration. If that isn't available or the pool's reputation stays poor, moving is worth considering, but only after confirming the pool is genuinely the cause.