Contents
- Why this question matters as you scale
- What a shared IP pool is
- Why a shared pool is attractive at first
- The collective reputation problem
- The loss of control and harder diagnosis
- Why stricter receiver enforcement raises the risk
- When a shared pool is still the right choice
- The transition to dedicated IPs
Why this question matters as you scale
A shared IP pool is, for many senders, where sending begins, and for a smaller sender it is often the correct choice. But the shared pool has a defining characteristic, that the sending IPs and therefore the reputation are shared with other senders, and that characteristic, harmless or even helpful at low volume, turns into a liability as a sender scales. A growing operation that stays on a shared pool past the point where it should have moved finds its deliverability constrained by factors entirely outside its control.
This operational note analyzes why. The structure of this note: why the question matters as you scale, what a shared IP pool is, why a shared pool is attractive at first, the collective reputation problem that is the core of the issue, the loss of control and the harder diagnosis, why the major receivers' stricter enforcement raises the risk of shared pools, when a shared pool is still the right choice, and the transition to dedicated IPs.
The argument is not that shared IP pools are bad, they are a sensible starting point and remain right for genuinely low-volume senders. The argument is that the shared pool does not scale: the same shared-reputation characteristic that costs a low-volume sender little becomes, at higher volume, a constraint and a risk significant enough that a scaling operation should plan its move to dedicated IPs.
What a shared IP pool is
A shared IP pool is a set of sending IP addresses used by multiple senders at once, where each sender's mail goes out over IPs that other senders' mail also goes out over.
Shared IP pools are commonly offered by email service providers and sending platforms. Rather than allocating each customer their own dedicated sending IPs, the provider runs a pool of IPs and routes many customers' mail through it. From the individual sender's perspective, their mail is sent from IPs they share with others.
| Aspect | Shared IP pool | Dedicated IPs |
|---|---|---|
| IPs used by | Many senders | One sender |
| Reputation reflects | All senders' mail combined | Only that sender's mail |
| Warming by the sender | Not needed; pool is pre-warmed | Required for each IP |
| Control over reputation | None; collective | Full; the sender's own |
The contrast with dedicated IPs is the heart of the matter. On dedicated IPs, a sender's IPs are theirs alone, and the reputation those IPs carry reflects only their own mail. On a shared pool, the IPs and the reputation are collective. That difference is what this note is about.
Why a shared pool is attractive at first
A shared IP pool is genuinely attractive, especially to a smaller or newer sender, and it is worth being clear about why, because the reasons are real, not illusory.
No warming required. A new dedicated IP has no reputation and must be warmed, sending at a low volume that is increased gradually over weeks, before it can carry full volume. A shared pool's IPs are already warmed, already carrying an established sending history, so a sender joining a shared pool can start sending at volume immediately, skipping the weeks-long warming. For a sender who needs to start sending now, this is a substantial convenience.
Shared cost and management. The IPs in a shared pool, and the work of managing them, are spread across many senders. An individual sender does not bear the full cost of dedicated IPs or the work of managing them.
Reputation maintenance for low volume. This is the most important reason, and it connects to when a shared pool remains correct. A dedicated IP needs a sustained volume to build and maintain its reputation; the receivers need enough mail from an IP to form a solid judgment, and an IP's reputation can decay during quiet periods. A very low-volume sender does not generate enough mail to keep a dedicated IP's reputation healthy. On a shared pool, the pool's aggregate volume keeps the IPs warm and their reputation maintained, so a low-volume sender benefits from the collective volume.
So a shared pool is a sensible starting point. The reasons it is attractive are real. The difficulty is that those same reasons weaken as a sender scales, and the shared characteristic that helps at low volume hurts at high volume.
The collective reputation problem
The core of why shared pools fail at scale is the collective reputation problem, and it follows directly from how sending reputation works.
Sending IP reputation is built per IP, not per sender. The receiving providers form a reputation judgment about an IP based on the mail they see from it, the engagement, the complaint rates, the spam-trap hits. On a dedicated IP used by one sender, that reputation reflects only that sender's mail. On a shared pool, the IPs carry the mail of many senders, so the reputation the receivers form reflects all of them mixed together.
The consequence: the pool's reputation is collective, the combined product of all the mail all the senders send over the pool's IPs, and every sender on the pool is subject to that single shared reputation.
If one sender on a shared pool sends poorly, mails bad lists, generates high complaint rates, hits spam traps, the receivers see that bad mail coming from the pool's IPs and the pool's reputation degrades. Because the reputation is collective, that degradation applies to every sender on the pool, including the senders doing everything right. A careful sender on a shared pool can have excellent list quality, perfect authentication, and low complaints, and still suffer degraded deliverability because another sender on the same pool is sending badly and dragging the shared reputation down. The careful sender does not control the pool's reputation, cannot influence another sender's behavior, and has no way to insulate their own mail from the pool's worst contributors. The exposure to other senders' mistakes is inherent in sharing the IPs.
This is the fundamental problem. At low volume, a sender's exposure to this is a reasonable trade for the shared pool's benefits, the sender is small, the stakes are modest, and the convenience and the reputation-maintenance help are worth it. But as a sender scales, the stakes rise: more volume, more business depending on the mail getting through, and the prospect of that all being undermined by a stranger's bad sending becomes a serious, unacceptable risk. The collective reputation does not get better as the sender scales; the sender's exposure to it simply matters more.
The loss of control and harder diagnosis
Beyond the collective reputation itself, the shared pool imposes two related costs that grow with scale: a loss of control, and harder diagnosis.
The loss of control. On a shared pool, a sender does not control the most important factor in their deliverability, the reputation of the IPs they send from. They can control their own list quality, their own authentication, their own complaint rate, but they cannot control the other senders, and the other senders heavily influence the shared reputation. A scaling operation that takes its deliverability seriously wants control over it, wants its own good practices to fully translate into good deliverability, and the shared pool denies that. The sender does everything right and still cannot guarantee the outcome, because the outcome is partly in strangers' hands.
Harder diagnosis. When deliverability degrades on a shared pool, diagnosing the cause is harder, because the cause may not be the sender's own mail at all. On dedicated IPs, a deliverability problem is, by definition, something about the sender's own sending, and the diagnosis stays within what the sender controls and can see. On a shared pool, a deliverability problem might be the sender's own doing, or it might be another sender on the pool, or it might be the pool's reputation generally, and the sender cannot easily tell which, because they have no visibility into the other senders' mail. The sender can audit their own practices thoroughly, find nothing wrong, and still have degraded deliverability, with the real cause being a pool-mate they cannot see. This makes shared-pool deliverability problems frustrating and slow to resolve, and that difficulty, like the collective reputation, grows in cost as the operation scales and the deliverability matters more.
Why stricter receiver enforcement raises the risk
The shared pool's risks are not static; the major receivers' move toward stricter enforcement in recent years has made shared pools meaningfully riskier than they used to be.
The receivers, Gmail, Microsoft, Yahoo, have tightened their enforcement. Gmail and Yahoo's bulk sender requirements, Microsoft's bulk sender enforcement, the move to permanent rejections for non-compliant mail, the stricter complaint-rate thresholds with the working ceiling now treated as 0.10 percent, all of this means the receivers respond to a sending reputation problem faster and harder than they once did.
For a shared pool, this raises the stakes of the collective reputation. In a more tolerant era, a shared pool's reputation dipping because of a bad pool-mate meant a modest, gradual deliverability decline that the other senders could weather. In the stricter current environment, a reputation problem on the pool can produce a sharper consequence, more aggressive filtering, throttling, even rejections, and it can happen faster. The careful sender on the shared pool is now exposed not just to a gentle drag from a bad pool-mate but to the possibility of a more sudden, more severe deliverability hit driven by enforcement, all because of mail they did not send.
The stricter enforcement also means the threshold for a pool's reputation being judged poorly is, in effect, tighter, so a shared pool needs all of its senders to maintain better discipline to keep the collective reputation healthy, and the failure of any one of them has a bigger effect. The trend is unambiguous: as the receivers tighten, the collective-reputation risk of a shared pool grows, which strengthens the case for a scaling operation to move to dedicated IPs where it controls its own reputation and its own compliance.
When a shared pool is still the right choice
This analysis is not an argument that shared pools are always wrong. For a genuinely low-volume sender, a shared pool remains the right choice, and it is important to be clear about that.
The reason is the reputation-maintenance point. A dedicated IP needs a sustained volume to build and hold its reputation. A sender whose volume is low does not generate enough mail to keep a dedicated IP's reputation healthy, the receivers would not see enough mail from the IP to form a solid judgment, and the IP's reputation could decay in the quiet stretches. A low-volume sender on a dedicated IP can actually have worse deliverability than the same sender on a shared pool, because their dedicated IP is under-warmed and under-fed.
On a shared pool, the pool's aggregate volume keeps the IPs warm and their reputation maintained, and a low-volume sender benefits from that collective volume. For such a sender, the collective reputation is a help, not a liability, the pool's volume sustains a reputation the sender could not sustain alone, and the exposure to other senders is a modest risk against a real benefit.
So the shared pool is correct for the low-volume sender and becomes a liability for the scaled one. The question is where the line is, and the answer is volume-based: the shared pool is right while the sender's volume is too low to support its own dedicated IPs, and the move to dedicated IPs becomes right once the sender's volume is high enough to build and maintain reputation on its own IPs. An operation should not move to dedicated IPs too early, before it can feed them, nor stay on a shared pool too long, past the point where it could and should control its own reputation.
The transition to dedicated IPs
When a scaling operation reaches the point where dedicated IPs are right, the transition needs to be planned, because the move is not instantaneous and reverses one of the shared pool's conveniences.
The key planning point: moving to dedicated IPs means warming those IPs. The shared pool let the sender skip warming, because the pool's IPs were pre-warmed. New dedicated IPs have no reputation and must be warmed, sending at a low volume increased gradually over weeks. So the transition is a weeks-long process, not a switch flipped overnight.
The transition approach:
- Plan the timing. The warming takes weeks, so the move is planned ahead, not done under pressure.
- Warm the dedicated IPs gradually. Start the dedicated IPs at a low volume and ramp up over the warming period, building their reputation progressively.
- Run in parallel during the transition. A sender can keep sending over the shared pool while warming the dedicated IPs, shifting volume from the pool to the dedicated IPs as the warming progresses, so there is no gap.
- Complete the move once the dedicated IPs are warmed. When the dedicated IPs are warmed to full volume and carrying a healthy reputation, the operation's sending is fully on its own dedicated IPs.
After the transition, the operation has what the shared pool could not give it: a sending reputation that reflects only its own mail. A careful operation now gets the full benefit of its own good practices, is no longer exposed to other senders dragging a shared reputation down, has control over its own deliverability, and has straightforward diagnosis, because a deliverability problem is now, by definition, about its own sending. The convenience of the shared pool is given up, but for a scaled operation that convenience was no longer worth the loss of control.
An operation we worked with had grown steadily and was sending a substantial volume, but they were still on their provider's shared IP pool, where they had started years earlier when their volume was small. They were a careful sender: their list hygiene was good, their authentication, SPF, DKIM, DMARC, was all correct and aligned, their complaint rates on their own mail were low, and they had done everything a responsible sender should. Yet their deliverability had become erratic and, over a period, had degraded noticeably, more of their mail landing in spam, their inbox placement slipping. They were baffled, because they could not find anything wrong with their own sending, and they had audited it thoroughly. We looked at the situation, and the diagnosis pointed away from their own mail entirely. Their mail was going out over the shared pool, and the shared pool's reputation had degraded. The cause was not them, it was the pool: one or more other senders on the same shared pool were sending badly, generating the complaints and the spam-trap hits and the poor engagement that drag a pool's collective reputation down, and because the reputation was collective, our client, the careful sender, was subject to the same degraded pool reputation. They had no visibility into the other senders' mail, no control over it, and no way to insulate themselves from it. They were doing everything right and their deliverability was, in effect, being controlled by strangers on the same pool. This is exactly the collective reputation problem, and it had become acute as their volume grew, because at their now-substantial volume, the damage from the degraded pool reputation was significant. Crucially, by this point their volume was well past the level needed to support their own dedicated IPs, so the original reason they were on the shared pool, that their low volume needed the pool's aggregate volume to maintain reputation, no longer applied. The recommendation was clear: move to dedicated IPs. We helped them plan the transition, provisioning dedicated IPs, warming them gradually over several weeks while still sending over the shared pool, and shifting volume to the dedicated IPs as the warming progressed. Once the dedicated IPs were warmed and carrying their full volume, their sending reputation reflected only their own mail, which, given their good practices, was a strong reputation. Their deliverability recovered and, more importantly, became stable and within their control, because it was no longer hostage to strangers on a shared pool. The lesson is the core of this analysis. A shared pool is the right choice for a low-volume sender, but it does not scale, and a careful, scaled sender who stays on a shared pool past the point where they could move has handed control of their own deliverability to senders they cannot see or influence. The collective reputation that helped them when they were small was, once they had grown, a liability, and the move to dedicated IPs was how they took back control of their own deliverability.
A shared IP pool is a sensible starting point for a sender and remains the right choice for a genuinely low-volume sender, because the pool's aggregate volume maintains a reputation that a low-volume sender could not sustain on dedicated IPs of their own, and the pool spares the sender the weeks of IP warming. But the shared pool does not scale. Its defining characteristic, that the sending IPs and therefore the reputation are shared, means the reputation is collective: it reflects all the senders on the pool combined, and one bad sender drags down everyone, including the careful senders, who have no control over it and no visibility into it. As a sender scales, that exposure, harmless when small, becomes a serious liability, the operation's deliverability partly controlled by strangers, the diagnosis of problems made hard by the lack of visibility, and the major receivers' stricter enforcement sharpening the consequences. The right move for a scaled operation, once its volume can support and maintain its own dedicated IPs, is to transition to dedicated IPs, a planned, weeks-long move that includes warming the new IPs, after which the operation's reputation reflects only its own mail and its deliverability is genuinely under its own control. Operations that recognize when they have outgrown the shared pool, and plan the move to dedicated IPs, take ownership of their deliverability; operations that stay on a shared pool past that point, as the case shows, find a careful, well-run sending operation hostage to the worst senders on a pool they share.