Dedicated vs Shared IP

Shared IP pools are the default for most SaaS ESPs (Mailchimp, ConvertKit, SendGrid, Mailgun, Postmark on entry tiers). The provider runs a pool of IPs (often hundreds) and routes outgoing mail across the pool from many customers at once. Each IP carries traffic from dozens or hundreds of senders. Reputation is collective. The pool's reputation is the average of its tenants' behaviour.

Dedicated IPs are single-tenant. One IP, one sender. The sender owns the reputation of that IP completely. Every send, every complaint, every bounce, every spam-trap hit accumulates against the same IP. Standard for self-hosted MTAs (PowerMTA, Postfix on dedicated infra) and an upgrade option at most ESPs once you cross volume thresholds.

The mechanical difference is whose behaviour shows up in your reputation profile. On shared, everyone in the pool affects you. On dedicated, only you do. That's the whole game.

Shared pools aren't universally bad. They have specific structural advantages.

• Volume too low to warm. Reaching production reputation on a dedicated IP needs consistent volume; typically 50K+ monthly, ideally 5K+ daily. A sender doing 5,000 monthly sends would never establish a stable reputation profile on a dedicated IP. Too sparse for receivers to track.
• Bursty sending patterns. Sending 200K once a quarter and nothing in between is a bad fit for dedicated, because long quiet periods cause reputation decay. The ESP's shared pool has continuous traffic that masks the burstiness.
• You don't control audience quality. Receipt-of-purchase confirmations to people who actually paid you go to engaged audiences. Cold prospect lists go to disengaged audiences. Shared pools absorb both because they're averaging across many senders. Dedicated IPs expose audience-quality risk fully.
• Operational simplicity over control. Shared IPs are managed by the ESP. You don't handle warming, monitoring, delisting. For senders without ops capacity, that's genuine value.

The problem with shared pools is that you inherit other senders' problems. Specifically:

• Pool reputation collapses aren't your fault and aren't yours to fix. Two of the pool's tenants run bad campaigns? The whole pool's reputation degrades. Your inbox placement drops. The ESP's recovery process is opaque. You wait for them to throttle the bad tenants and the pool to recover.
• Spamhaus listings on shared IPs aren't individually delistable. Your shared IP gets SBL listed because of a co-tenant? You cannot submit a delist request; Spamhaus would need the ESP to delist, and the ESP usually responds by migrating affected tenants off the IP rather than fighting the listing.
• You have no visibility into other tenants. Don't know what they're sending, how they're acquiring lists, what their complaint rate is. You're trusting the ESP's tenant-quality enforcement, which varies wildly across providers.
• Postmaster Tools data is meaningless. The reputation Gmail reports for your shared IP is the entire pool's reputation, not yours. Can't isolate your own contribution.

Dedicated becomes the right answer when your volume and consistency can sustain a stable reputation profile, and when you have ops capacity for warming, monitoring, and occasionally delisting.

• Volume above ~100K monthly. Enough sends per day for receivers to track reputation reliably.
• Consistent sending pattern. Daily or near-daily sends, not quarterly bursts.
• Control over audience quality. You've done list hygiene, you have engagement data, you know your bounce rate.
• Operational capability or managed service. Either an in-house ops team or a managed provider that handles warming and monitoring.
• Specific reputation requirements. Authoritative messages (transactional, financial), B2B outreach where receiver-side reputation tracking matters, or any sending where shared-pool noise would obscure your actual signal.

Dedicated IPs aren't a magic solution. They fail when the prerequisites aren't there:

• Volume too low to maintain reputation. A dedicated IP doing 2,000 sends/month gets warmed once and then drifts. Receivers struggle to keep a profile on sparse traffic.
• Audience quality issues you didn't see coming. On a shared pool they blend in. On a dedicated IP they're fully exposed and damage your IP specifically.
• Operational capacity isn't actually there. Dedicated IPs need warming, monitoring, incident response. A team without these capabilities ends up worse off than they would have been on shared.
• Bursty patterns. Dedicated IPs need consistent sending. Long quiet periods cause reputation decay. Sudden spikes after quiet periods look like spam-pattern behaviour.

For senders past 500K monthly, a single dedicated IP may not be enough. Two patterns emerge:

• Multi-IP pools for volume. A pool of 3-5 dedicated IPs distributes the same total volume across more capacity. Useful when single-IP rate-limiting from receivers becomes the bottleneck. Each IP is still dedicated to you. You control all of them.
• Multi-IP pools for segmentation. Different IPs for different message types: one for transactional (high engagement, low complaint), one for marketing (mixed), one for cold outreach (low engagement, higher bounce). Reputation isolation between segments prevents one bad campaign from damaging another.

Multi-IP pools need the same warming + monitoring discipline as single dedicated IPs, multiplied by IP count. They're not a way to amortise reputation risk across IPs (each IP's reputation is still independent). They're a way to scale capacity and isolate workloads.

Simple framework that captures the trade-offs:

if monthly_volume < 50,000:
    use shared (dedicated wastes the IP)
elif monthly_volume >= 100,000 AND consistent_pattern:
    use dedicated (control wins, volume is enough)
elif monthly_volume in [50,000..100,000]:
    if engagement_quality is high AND you have ops capacity:
        use dedicated (you can use the control)
    else:
        use shared (shared pool absorbs your imperfections)
elif bursty_pattern OR audience_quality_issues:
    stay on shared (don't expose your problems)
else:
    use dedicated (you've earned it)

Notice that the framework defaults to shared in ambiguous cases. Dedicated IPs amplify both your strengths and your weaknesses. Senders who pick dedicated for prestige rather than fit usually end up with worse deliverability than they would have had on shared. Vanity costs money.

The traditional rule of thumb that dedicated IPs become economically justified at 50,000 monthly messages is outdated for 2026 conditions. The threshold has moved down because receiver-side weighting on IP-level reputation has increased relative to other signals, and because the cost of shared-IP reputation contamination has increased as receivers apply stricter classification.

The 2026 threshold for most operations is closer to 20,000-30,000 monthly messages for senders who have control over content quality and list quality. Below that volume, shared IP infrastructure typically produces acceptable placement when the shared pool is well-managed. Above 20,000 monthly the sender starts generating enough volume that their own behavior dominates the IP reputation signal, which makes dedicated infrastructure pay back through control over reputation outcome.

Several specific situations move the threshold lower than the general guideline: senders in heavily-regulated industries (financial services, healthcare-adjacent) need dedicated IP at any volume because shared infrastructure with non-regulated senders produces unacceptable mixing of reputation signal. Senders running cold outreach or B2B prospecting need dedicated IP at any volume because the complaint rates and engagement patterns differ enough from typical opt-in marketing that shared infrastructure absorbs negative signal from one and damages the other. Senders sending transactional mail with high reputation requirements (password resets, two-factor codes, payment confirmations) benefit from dedicated IP even at low volumes because shared infrastructure variation produces unpredictable placement that affects critical customer interactions.

The cost differential in 2026 makes dedicated IP economically accessible at lower volumes than it was in 2020-2022. Dedicated IP allocations run 5-30 USD monthly per IP in 2026 depending on provider and jurisdiction; the equivalent volume on shared infrastructure that produced acceptable reputation can cost similar amounts. The decision is less about cost and more about operational control over the reputation outcome.

For operators of shared IP pools (hosting providers, ESPs, marketing platforms), the pool management approach determines whether the shared infrastructure produces good or bad outcomes for the customers using it. The management practices below capture what we have observed work across the providers that operate shared pools competently.

Customer screening: the pool admits customers who pass a baseline screening for content type, sending pattern, and operational practices. The screening is not legal-process compliance (which is separate); it is reputation-protection compliance to ensure new customers do not damage existing customer reputation. Pools that admit any paying customer accumulate reputation problems faster than pools that screen.

Pool segmentation: the customer base is segmented into pools by sending category and reputation tier. Transactional senders run in transactional pools with strict per-IP reputation requirements. Marketing senders run in marketing pools with somewhat looser requirements but still enforced. Cold outreach senders run in their own pools isolated from opt-in marketing. New customers without established reputation start in onboarding pools and migrate to production pools after establishing acceptable patterns.

Active monitoring with per-customer attribution: the pool operator monitors per-IP reputation in aggregate and attributes specific reputation events to specific customers contributing to them. When an IPs reputation degrades, the operator can identify which customer behavior produced the degradation and intervene. Without attribution the operator can only suspend the IP entirely, which is unfair to other customers sharing it.

Capacity management: pools have target volume bands that match their warmed capacity. Adding customers beyond the warmed capacity produces volume spikes that degrade reputation across the pool. Pools that add customers without managing aggregate volume against capacity produce predictable reputation degradation patterns.

For senders evaluating shared IP providers, the questions to ask: how do you screen customers admitted to your pools, how do you segment pools by sending category, how do you attribute reputation events to specific customers, how do you manage aggregate pool volume against warmed capacity. Providers that have good answers to these questions operate pools that produce acceptable outcomes; providers that do not are running pools that accumulate problems faster than they can manage them.

Operators commonly need to migrate between shared and dedicated infrastructure as their operations scale or as their requirements change. The migration patterns below capture what we have observed work cleanly versus what produces predictable problems.

Shared-to-dedicated migration: the cleanest pattern runs the new dedicated IP in parallel with the existing shared infrastructure for 30-45 days. The dedicated IP receives a progressively larger share of traffic during the warmup period: 5% in the first week, 15% in the second, 30% in the third, 50% in the fourth, 100% by the end of the warmup window. The parallel period lets the dedicated IP accumulate reputation gradually while the shared infrastructure absorbs the remaining volume. Cutover to 100% dedicated happens only after the dedicated IP shows clean reputation at full warmed volume.

The flat-cutover pattern (switching all traffic from shared to dedicated on a specific day without parallel period) produces predictable problems: the dedicated IP receives full production volume without warmed reputation, the receiver-side classification treats the unfamiliar IP with appropriate caution, placement drops substantially during the 30-45 days the IP takes to warm. The traffic during warmup goes to spam folder at high rates and the resulting low engagement reinforces the unfamiliarity, producing slower warmup than properly-paced gradual transition.

Dedicated-to-shared migration: less common but operationally simpler when needed. The sender stops sending from the dedicated IP and migrates to the shared pool. The reputation of the dedicated IP becomes irrelevant to the senders future operations (it can be returned to the IP allocation pool or held in reserve). The shared pool already has warmed reputation; the new customer just starts using it. Some pool operators require an onboarding period in their starter pools before access to their main production pools; this is normal and reasonable.

Dedicated-to-dedicated migration: when an operator needs to change dedicated IP allocation (move to different provider, different jurisdiction, different specific IP). Same parallel-period pattern as shared-to-dedicated. The senders existing dedicated IP and the new dedicated IP run in parallel for 30-45 days while traffic shifts progressively. The senders domain reputation transfers cleanly because it lives at the domain level; the IP-level reputation needs warmup on the new IP regardless of how strong it was on the old one.

Cross-pool migration within shared infrastructure: when changing which shared pool a customer uses, similar parallel-period pattern applies but at compressed timeline because both pools already have warmed reputation. The gradual transition is more about validating that the new pool produces acceptable outcomes for this specific customer than about warming reputation.

Operators evaluating whether to invest in dedicated IP infrastructure benefit from a structured cost-benefit framework rather than rules-of-thumb. The framework below captures the variables that actually determine the answer for a specific operation.

Cost side: direct IP allocation cost (5-30 USD monthly per IP depending on provider and jurisdiction), warmup cost during the 30-45 day initial period when traffic to the new IP produces lower placement than mature alternatives would, operational overhead of managing dedicated infrastructure (monitoring, reputation maintenance, occasional incident response), opportunity cost of capital tied up in dedicated infrastructure.

Benefit side: placement improvement compared to shared alternatives (typically 5-15 percentage points for properly-warmed dedicated IP versus shared with mixed reputation), reputation isolation from other senders that share the alternative pool (eliminates risk of other-customer-driven reputation degradation), control over reputation outcome (the operator can directly manage the variables that drive reputation rather than depending on pool-operator management), faster recovery from incidents (dedicated infrastructure can be recovered through senders own actions rather than waiting for pool-operator response).

Quantification framework: for an operation sending V monthly messages with average revenue R per inbox arrival and placement P on shared infrastructure, the revenue impact of dedicated IP that produces placement P+delta is V x delta x R per month. The cost is roughly 30 USD per dedicated IP per month plus 30-45 days of warmup-period revenue impact. For most operations sending above 50,000 monthly, the benefit calculation produces positive ROI within 1-3 months of dedicated IP deployment. For operations sending below 20,000 monthly, the benefit calculation typically produces negative ROI unless specific high-value-per-message use cases (transactional with high revenue per recipient, regulated industries with reputation requirements that shared infrastructure cannot meet).

The framework should be reviewed periodically as operational conditions change. An operation that starts on shared infrastructure at low volume often crosses the dedicated-IP threshold as it grows; an operation that starts on dedicated infrastructure may find shared alternatives have improved enough to justify migration as the alternative pools mature. The 2026 landscape rewards periodic re-evaluation against current options rather than locking in either choice indefinitely.