Dedicated IP vs Shared IP for Transactional Email — What Actually Affects Deliverability in 2026
Every new sender asks the same question at some point: "Should I get a dedicated IP?" It sounds like an upgrade — your own sending address, nobody else's reputation attached to it. But for most teams it is money spent on a problem they do not have yet. Inbox placement in 2026 is driven far more by what you send than by the IP you send from.
What an IP reputation actually is
Mailbox providers (Gmail, Outlook, Yahoo) keep a reputation score for every sending IP they see. That score is built from signals:
- Complaint rate — how often recipients hit "report spam."
- Bounce rate — how often you send to dead or nonexistent addresses.
- Engagement — opens, replies, and "this is not spam" clicks.
- Volume consistency — sudden spikes look like a compromised sender.
A bad reputation means the mailbox filters your mail before a human ever sees it. An IP with no reputation yet is treated as untrusted, not as good — which is why warmup exists.
The shared IP pool
Most email APIs (including MailAnvil, which relays through AWS SES) send from a shared pool of IPs. Your mail goes out on IPs shared with thousands of other senders, and the pool's aggregate reputation is what matters.
Upside:
- No warmup. The pool is already trusted at scale.
- Reputation smoothing. One sender's small mistake is diluted across the pool.
- Free. Included in every plan, no setup.
Downside:
- No isolation. A high-volume spammer on the pool can drag everyone's numbers slightly — which is why serious providers police their pools aggressively and kick abusers fast.
- No IP-level diagnostics. If you have a deliverability problem, you can't inspect "your" IP, because there isn't one.
For any sender under roughly 100,000 emails a month, a shared pool is not just acceptable — it is the correct choice. Your reputation is still tracked at the domain level (via DKIM/SPF alignment), and that is the reputation you control.
The dedicated IP
A dedicated IP is yours alone. Its reputation is built — or destroyed — entirely by your sending.
When it is worth it:
- Consistent volume above ~100k/month. Below that, you don't send enough for the IP to build a stable reputation, and low-volume dedicated IPs often deliver worse than a shared pool.
- Reputation isolation. You run a marketplace or platform where a subset of senders is risky, and you don't want them contaminating your core transactional mail.
- Compliance requirements. Some enterprise customers contractually require a dedicated sending IP.
- You need raw IP-level logs for your own deliverability engineering.
The cost you don't see: warmup. A fresh dedicated IP starts untrusted. You must ramp volume slowly over 2–4 weeks, starting with your most-engaged recipients (password resets, receipts, invoices — mail people expect), and hold low-engagement bulk for last. Ramp too fast and the IP gets a throttling reputation before it ever gets a chance.
What actually moves deliverability (and it is not the IP)
Before spending on a dedicated IP, fix these — they matter more, in order:
- Authentication. SPF, DKIM, and DMARC properly aligned on your sending domain. A dedicated IP with broken DKIM is still going to spam.
- List hygiene. Bounces are a reputation tax. Suppress hard bounces immediately and never send to addresses you bought or scraped.
- Content and intent. Transactional mail (receipts, OTPs, password resets) gets delivered because people want it. Marketing mail is judged harder.
- Volume discipline. Ramp gradually after any change — new domain, new IP, new template.
- Engagement. Reply-to addresses that work, one-click unsubscribe on bulk mail, and plain-text fallbacks.
These five are the deliverability engine. IP choice is a dial you tune after the engine runs.
The decision, in one table
| Your situation | Choice |
|---|---|
| Under ~100k emails/month | Shared pool |
| Over ~100k/month, consistent volume | Consider dedicated IP |
| Marketplace / platform with mixed senders | Dedicated IP per segment |
| Deliverability incident on shared pool | Diagnose domain/auth first, IP last |
| Just launched, need reliability today | Shared pool, zero warmup |
For Indonesian senders specifically
Indonesian startups tend to send bursts — OTP spikes at checkout hours, invoice runs at month-end. A dedicated IP is a poor fit for bursty, inconsistent volume; it never warms evenly. A shared pool absorbs the spikes. Focus on domain warmup and list hygiene instead, and revisit the dedicated IP question only when you cross six figures monthly and hold it.
Bottom line
Dedicated IP is not a deliverability cheat code. It is an operational tool for high, stable volume. Most teams should ship on a shared pool, invest the saved effort in authentication and engagement, and treat the dedicated IP as a scaling decision — not a launch decision.
MailAnvil handles the pool, the warmup guidance, and the DKIM/SPF/DMARC setup — including auto-configuring Cloudflare DNS — so your first job is sending mail people want, not babysitting an IP.