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 pattern | What the provider sees | Result |
|---|---|---|
| Steady, high | A consistent sender with a stable complaint rate | Reputation accrues; you control it |
| Steady, low | Too little data to form a judgement | Treated as unknown, filtered conservatively |
| Spiky | Silence, then a burst from a quiet address | The classic spam signature; throttling or blocks |
| Low with a spike | Unknown sender suddenly at volume | Worst 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.
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 workWhen 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.
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.