Dedicated IP versus shared IP warm-up: what actually differs

A dedicated sending IP and a shared one need genuinely different warm-up approaches, because they start from different places. A dedicated IP has no history at all until you build one. A shared IP inherits whatever reputation the pool already has — which can be a head start or a liability, and you usually don't get to choose which.

What a dedicated IP needs

A dedicated IP, like a new domain, starts with zero sending history. Every signal a provider might use — volume pattern, bounce rate, complaint rate, engagement — has to be built from your own sending alone, because nothing else is sharing that IP to contribute data one way or the other. This means a full ramp is necessary: low volume initially, gradual increase over two to four weeks, careful monitoring throughout, exactly as with a new domain.

What a shared IP inherits

A shared IP, typically offered by email service providers like SendGrid, Mailgun, or similar relays as a default option, carries the combined sending reputation of everyone currently using it. If the pool is well-managed — other senders on it have good practices, low complaint rates, clean lists — a new sender benefits immediately from that established trust without needing to build it from scratch. If the pool includes senders with poor practices, your mail can be filtered more aggressively regardless of how careful you personally are, because the IP's reputation is the aggregate, not yours individually.

The trade-off in plain terms

Dedicated IP:  full control over reputation, but you build every bit of it
               yourself, starting from zero, over weeks
Shared IP:     some reputation already exists, but it's not under your
               control and can be affected by other senders' behaviour

When a dedicated IP makes more sense

• Sending volume is high enough that a full warm-up investment pays off over time
• You want full visibility into exactly what's affecting your own reputation, without the noise of other senders
• Your sending platform and operational maturity can support a proper multi-week ramp

When a shared IP makes more sense

• Sending volume is moderate or low, where building and maintaining a dedicated IP's reputation isn't worth the ongoing effort
• You're sending through a reputable relay that actively manages pool quality and removes bad actors
• You need to start sending sooner than a full dedicated-IP ramp would allow, and can tolerate some variability tied to the pool

Checking a shared pool's standing before relying on it

If you're using a shared IP, check what you can about the pool's current standing — some relays expose a reputation or health indicator for the shared pool, and blocklist lookups for the IP itself are worth running periodically, since a listing affects everyone on that IP regardless of their individual sending practices. If placement seems unexpectedly poor despite your own clean practices, a shared pool's reputation is a real, separate cause worth ruling out before assuming the problem is something you did.

Switching between them

Moving from a shared IP to a dedicated one later is a legitimate path as volume grows, but it means restarting the warm-up process on the new, unhistoried dedicated IP — the reputation built on the shared pool doesn't transfer. Plan the switch with that in mind rather than expecting an instant, uninterrupted continuation of whatever placement you had before.

A middle option: semi-dedicated pools

Some relays offer a middle ground between a fully shared pool and a fully dedicated IP — a smaller pool shared among a limited, vetted set of senders rather than the relay's entire customer base. This can offer some of the stability benefit of a dedicated IP without the full cost and warm-up time, though it still carries some dependency on the other senders in that smaller pool, so the same due-diligence questions about who else is on it still apply.

Volume thresholds worth knowing

As a rough guide, dedicated IPs generally make more operational sense once consistent daily volume reaches a few tens of thousands of messages, since below that threshold the IP may not send often enough to build and maintain its own strong reputation independently — a dedicated IP that sends too infrequently can actually struggle more than a well-managed shared pool, because infrequent sending is itself a pattern some filters treat cautiously.

MailPilot warms domains and mailboxes over OAuth and SMTP/IMAP, including setups using dedicated or relay-provided IPs, checks SPF, DKIM, and DMARC, and tracks per-mailbox reputation daily so a problem tied to a shared pool's reputation is visible rather than mistaken for something specific to your own sending practices.