Key takeaways
- A dedicated IP needs consistent, near-daily volume. Roughly 100,000 messages a month is the practical floor; around 300,000 is where it reliably outperforms a good shared pool.
- Below that floor, a quality shared pool usually delivers better, because you inherit established reputation instead of building one from nothing.
- The decisive variable in a shared pool is not its size — it is who else is allowed on it.
- "Dedicated IP" ranges from an address label on shared infrastructure to genuinely separate mail servers. Ask which one you are buying.
- Some requirements — customer IP allowlisting, isolation guarantees in a security review — need dedicated infrastructure at any volume.
The dedicated-versus-shared question is usually framed as a question about control, which makes dedicated sound obviously preferable. It is not. A dedicated IP hands you sole responsibility for a reputation you then have to build from zero and sustain forever, and if your volume cannot sustain it, you have traded a pool with an established history for an address that looks perpetually unfamiliar to receivers.
The genuinely useful framing is different. Shared infrastructure means your reputation is partly a function of other people’s behaviour. Dedicated infrastructure means it is entirely a function of yours. Which is better depends on your volume, your consistency, and — the part most comparisons omit — on who those other people actually are.
What each one actually is
On a shared pool, your messages leave from IP addresses used by many senders at once. The reputation attached to those addresses is the aggregate of everyone’s sending. You inherit it on your first message, which is why a new account on an established pool can send successfully on day one without any warmup.
On a dedicated IP, your messages leave from an address nobody else uses. The reputation attached to it is built entirely from your own sending — which also means it starts at nothing, and receivers treat an unknown address conservatively until it has a history.
| Shared pool | Dedicated IP | |
|---|---|---|
| Reputation source | Everyone on the pool | You alone |
| Time to trusted | Immediate — you inherit it | 4–8 weeks of warmup |
| Volume floor | None | ~100k/month, sending near-daily |
| Effect of your own mistake | Diluted across the pool | Concentrated entirely on you |
| Effect of someone else’s mistake | You absorb part of it | None — there is no one else |
| Can you name your IPs to a customer | No — the range is shared and may change | Yes |
| Goes cold if you pause | No | Yes — dormancy erodes reputation within weeks |
| Operational burden | None | Warmup, monitoring, consistency management |
The volume floor and why it exists
Reputation is inferred from a pattern of behaviour over time. An IP that sends 50,000 messages one Monday and nothing until the following month has not given receivers a pattern — it has given them two anomalies. Sparse, bursty sending from a dedicated address reads as suspicious in a way the same volume on a busy shared pool never would.
That is why the guidance is expressed as a floor rather than a preference. Industry consensus puts the practical minimum around 100,000 messages a month with consistent near-daily sending, and around 300,000 a month for reputation that maintains itself comfortably. Below that, most senders get better results from a well-run shared pool.
| Monthly volume | Recommendation | Reasoning |
|---|---|---|
| Under 100k | Shared pool | Not enough consistent signal to build or hold a dedicated reputation |
| 100k–300k | Depends on consistency | Viable if you send most days; erratic patterns still favour shared |
| 300k–1M | Dedicated usually wins | Enough steady volume to build and sustain reputation |
| Over 1M | Multiple dedicated IPs, split by stream | Separate transactional from marketing at the IP layer as well as the domain layer |
Transactional senders have a structural advantage here. Transactional volume tracks product usage, so it is naturally smooth and naturally daily — exactly the profile a dedicated IP wants. A marketing-heavy sender at the same monthly total has a much harder time keeping an IP warm, because their volume arrives in campaign-shaped bursts.
The variable nobody puts on the comparison page
Every shared-versus-dedicated comparison treats "shared pool" as a single, uniform thing. It is not. A pool carrying transactional mail from vetted, paying customers behaves nothing like a pool carrying free-tier signups, marketing campaigns, and whatever a self-serve account decided to send at 2am.
This is the question that actually determines whether shared infrastructure is safe for you, and it is almost never answered on a pricing page. Ask it directly.
- Do free-tier accounts send from the same IPs as paid production traffic? An account that costs nothing to create and nothing to abandon has no incentive to protect a reputation you depend on.
- Is marketing or bulk campaign traffic permitted on the pool? Campaign mail generates complaint volumes transactional mail never does, and complaints are the most heavily weighted negative signal there is.
- Is cold outbound permitted anywhere on the infrastructure? Cold sending is the single fastest way to accumulate spam-trap hits and blocklistings.
- How quickly is an abusive tenant detected and isolated? Specific answers — thresholds, automated cut-offs, notification policy — are a good sign. Vague ones are not.
- Are transactional and marketing traffic separated at the IP layer? If the provider runs both, the pools should be distinct.
This is the constraint SuperSend TX is built on. The production pool carries transactional mail from paying customers only — no free tier on production infrastructure, no marketing campaigns, no cold outbound. It is a deliberate limit on who we will sell to, and it is the mechanism that produces pool quality rather than a claim about it.
What "dedicated" means at different providers
The word is sold at very different depths, and the differences are material. Three levels are common.
| Level | What you get | What you do not get |
|---|---|---|
| Dedicated IP add-on | One IP address assigned to your account, on the provider’s existing infrastructure | Server isolation, control over warmup, usually any help with the ramp |
| Dedicated IP pool | Several addresses reserved for you, often with stream separation | Server-level isolation; you still share the underlying platform |
| Dedicated infrastructure | Mail servers provisioned for you, with IPs used only by your traffic | Nothing, if the provider also operates and warms it |
The gap between the first and third rows is where most disappointment lives. A dedicated IP add-on that arrives cold, with no warmup plan and no operational support, is not a deliverability upgrade — it is a project you have just been handed, and it will perform worse than the shared pool you left for the first month or two.
The questions that separate them: are the IPs used only by my traffic? Are they named in the dashboard so I can give them to a customer? Who runs the warmup ramp? What happens if the reputation degrades — do I get told, and does someone help?
When dedicated is required regardless of volume
The volume analysis assumes the decision is about deliverability. Sometimes it is not, and then the floor stops being the deciding factor.
- Customer IP allowlisting. The moment you sell to a company with a security review, someone will ask which IP addresses your mail arrives from so their gateway can allowlist them. "A shared range that may change" is not an answer that passes.
- Reputation isolation as a contractual matter. Some buyers require that their mail not share infrastructure with unrelated senders, and want it in writing.
- Regulated environments. Healthcare, finance, and government procurement frequently require documented isolation of the sending path.
- Critical mail with a low tolerance for correlated failure. If a delivery incident caused by an unrelated tenant would be a serious business event, paying to remove that failure mode is rational even below the volume floor.
- Very high volume with distinct streams. Above roughly a million messages a month, splitting transactional and marketing onto separate dedicated IPs is standard practice.
Making the decision
- 1
Establish your real monthly volume and its shape
Not the projection — the last three months. Then look at how many days a week you actually send meaningful volume.
- 2
If under 100k and evenly spread, stay shared — but audit the pool
Ask who else sends from it, whether free accounts share it, and whether marketing or cold traffic is permitted. That audit matters more than the shared/dedicated choice itself.
- 3
If over 300k with near-daily sending, plan the move
You have the volume to build and hold reputation. Budget four to eight weeks for the ramp and read the warmup guide before you start.
- 4
If a customer or auditor needs nameable IPs, move regardless
The requirement is not about deliverability and the volume floor does not apply to it. What matters is that the IPs are genuinely yours and someone competent is operating them.
- 5
Separate the streams before you separate the IPs
Sending transactional and marketing from distinct subdomains is cheaper, faster, and delivers more benefit than a dedicated IP. Do it first. Here is how.
- 6
Never move both streams at once
Migrate transactional first, stabilise, then marketing. If something degrades you want to know which change caused it.
How SuperSend TX handles both
Because we own and operate our sending infrastructure rather than reselling someone else’s, the shared and dedicated options are both things we control end to end.
The Pool carries production transactional mail from paying customers only. There is no free tier on it, marketing campaigns are not permitted, and cold outbound is not permitted anywhere on the infrastructure — our cold-email product runs on entirely separate systems and never touches this network. That constraint is the product.
Dedicated provisions mail servers and IP addresses for your workspace alone. We build them, run the full warmup ramp so you never receive a cold IP, monitor reputation continuously, and operate the stack. Your IPs are listed in the dashboard so you can hand them to a customer’s security team. Because the API contract is identical across Sandbox, Pool, and Dedicated, moving between tiers changes your bill and nothing in your application.
| Pool | Dedicated | |
|---|---|---|
| Who else sends from it | Paying transactional customers only | Nobody |
| Marketing or cold traffic | Not permitted | Not applicable |
| Warmup | Already warm — inherit it | We run the full ramp for you |
| IPs nameable for allowlists | No | Yes, listed in the dashboard |
| Operations and monitoring | Ours | Ours |
| API contract | POST /emails | POST /emails — unchanged |
Dedicated servers and IPs, built and warmed by us
Not an IP label on shared infrastructure. Your own mail servers and addresses, provisioned, warmed through the full ramp, monitored, and operated — with the same API you already use.
Related reading