Skip to content
Writing
NewDeliverabilityDedicated IPEmail InfrastructureDevOps

Dedicated IP vs shared IP: do you need one?

A dedicated IP sounds like an upgrade. Below roughly 100,000 messages a month it is usually a downgrade, because reputation is built from volume and you will not have enough of it.

Tayyab MughalFounder & AI Chief5 min read

The shared IP vs dedicated IP question, answered honestly

Teams ask for a dedicated IP because it sounds like the grown-up option — your own address, your own reputation, nobody else able to damage it. The first two are true. The third is the problem.

Reputation at a mailbox provider is inferred from a pattern of behaviour over time, and a pattern needs volume to exist. A shared pool has that volume already, contributed by hundreds of senders and continuously maintained by the provider. A new dedicated IP has none, and to Gmail an address with no history sending a trickle of mail is indistinguishable from an address a spammer just bought.

So the honest framing is not "dedicated is better". It is: a dedicated IP transfers responsibility for reputation from your provider to you, and that is only an upgrade if you send enough to carry it.

The volume floor, and what happens below it

The usual guidance is a threshold somewhere around 100,000 messages per month, sustained. The precise number matters less than the shape of the reasoning behind it: reputation signals decay, so an IP needs a steady enough stream to keep refreshing them.

Below the floor, three things go wrong at once, and they compound.

Volume patternWhat the provider seesResult
Steady, highA consistent sender with a stable complaint rateReputation accrues; you control it
Steady, lowToo little data to form a judgementTreated as unknown, filtered conservatively
SpikySilence, then a burst from a quiet addressThe classic spam signature; throttling or blocks
Low with a spikeUnknown sender suddenly at volumeWorst case — this is what a compromised account looks like

What warming an IP actually involves

Warming is not a formality you complete before the real sending starts. It is a multi-week ramp in which you send deliberately small volumes to your most engaged recipients first, increasing gradually so each provider sees a consistent, low-complaint pattern before it sees scale.

The part people underestimate is that it is per-provider. Gmail, Microsoft, Yahoo and Apple each form their own view, and a ramp that satisfies one can still be too fast for another. And if you pause — a quiet fortnight, a seasonal lull — the reputation decays and you warm again.

TEXT
A conservative ramp. Adjust downward if complaints rise; never upward to catch up.

  Day  1–3    ~50–200/day     most engaged recipients only
  Day  4–7    double daily    watch complaint rate after every step
  Week 2      ~5,000/day      split evenly across providers
  Week 3      ~20,000/day     hold if any provider starts deferring
  Week 4      ~50,000/day     approaching steady state
  Week 5+     target volume   keep it steady — gaps undo the work

When a dedicated IP is genuinely right

Sustained volume above the floor, with a stable pattern rather than campaign spikes. At that point you have enough signal to own your reputation, and isolating yourself from other senders becomes a real benefit rather than a theoretical one.

Regulatory or contractual isolation requirements, where a customer needs to know their mail does not share infrastructure. This is a compliance answer, not a deliverability one, and it is worth being clear about which you are buying.

Genuinely distinct mail streams that need separate reputations — transactional receipts kept away from bulk notification traffic, so that a problem in one does not affect the other. This is worth doing with separate pools or subdomains even when you stay shared.

Staying on a shared pool well

Most senders get better results from a well-run shared pool than from a dedicated IP they cannot keep fed. That does not make the shared pool passive: your own hygiene still determines your outcome within it.

Authenticate properly and keep alignment clean, suppress hard bounces immediately and permanently, honour unsubscribes the moment they arrive, and separate transactional from promotional streams so a marketing complaint rate never touches your password resets. A pool provider watches complaint rates per sender and will throttle or remove a sender damaging the pool — which is the mechanism that keeps it worth being in.

Early Access

Building AI agents that send email?

Join the SadaSend early access waitlist to get scoped API keys, recipient allowlists, and Model Context Protocol (MCP) servers upon launch.

Use Case:
One email when it opens
Social Hashtags & Share
#EmailAPI#DeveloperTools#EmailDeliverability#DKIM#DMARC#DedicatedIP
Tayyab MughalFounder & AI Chief

Building SadaSend — transactional email with an MCP server that has a ceiling. Writes about deliverability, email infrastructure, and what happens when you hand an autonomous agent a sending credential.