Shared vs dedicated sending IPs explained: how reputation works on each, the volume you need for a dedicated IP, costs, risks and a simple decision framework.
Pidgely teamPublished 5 min readMarkdown version
Choose a shared IP if you send low or irregular volume, and a dedicated IP if you send steady, substantial volume and want full control over your reputation. On a shared IP, your mail benefits from the established reputation of a pool but is also affected by other senders' behavior. On a dedicated IP, your reputation depends only on your own sending, which is ideal at scale and risky when volume is too small or too irregular for mailbox providers to form a stable opinion.
Every message arrives at a receiving server from an IP address, and providers like Gmail, Microsoft and Yahoo keep a history for each IP: volume, consistency, bounce rate, spam trap hits, user complaints and engagement. That history influences whether the next message is accepted, throttled, filtered or rejected.
IP reputation is one input among several. Providers also score the From domain, the DKIM signing domain, link domains and content. Over the past years, domain reputation has become more important (Google Postmaster Tools reports both), but IPs still matter: blocklists such as Spamhaus list IPs, and Microsoft's SNDS reports by IP.
A shared IP sends mail for multiple customers of the same provider. Well-run providers group senders into pools by type and quality, and police them closely.
The quality of a shared pool depends entirely on the provider's enforcement: vetting new accounts, automatically pausing accounts with high bounce or complaint rates, and separating transactional and marketing traffic into different pools.
A dedicated IP sends only your mail.
Providers do not publish thresholds, and you should be skeptical of anyone quoting exact numbers. What matters is that each major receiving provider sees a regular, daily flow from the IP. A practical way to think about it:
Moving to a dedicated IP does not reset a poor domain reputation. Receivers follow your From domain and DKIM domain across IPs. Conversely, a strong domain reputation helps a new dedicated IP warm faster. Whatever you choose, configure per-domain DKIM and an aligned return-path so reputation is attributed to your domain, not to your provider's.
| Situation | Recommendation |
|---|---|
| Early stage, low volume, mostly transactional | Shared pool from a strict provider |
| Irregular marketing bursts | Shared pool |
| Steady daily volume at major providers | Dedicated IP(s) |
| Separate high-volume marketing and transactional streams | Dedicated pool per stream |
| B2B customers requiring allowlisted IPs | Dedicated |
| Recovering from a reputation problem | Fix the cause first; a new IP will not help |
Many senders combine both: transactional mail on a dedicated IP (steady volume, high engagement) and marketing on a shared pool, or vice versa as volume grows. Another pattern is to start on a shared pool and move to dedicated IPs once daily volume justifies it, warming up by shifting a growing share of traffic.
Avoid using many IPs to spread volume thinly. Rotating across IPs to dilute complaints looks like snowshoe spam, which receivers actively detect.
Pidgely runs IP pools per stream on its own MTA, warms new IPs automatically, and pauses accounts that exceed bounce or complaint thresholds, which is what keeps a shared pool clean for everyone in it.
Only if you send enough consistent volume to build and keep a reputation. A dedicated IP isolates you from other senders, but at low or irregular volume it can perform worse than a well-managed shared pool.
There is no official threshold. As a rule of thumb, you need steady daily volume at the major providers, typically tens of thousands of messages per week or more, sent consistently rather than in occasional bursts.
Yes. Providers combine both. Domain reputation has grown in importance, especially at Gmail, but a blocklisted or poorly rated IP still causes rejections and throttling.
Yes. Move gradually: warm up the dedicated IP by routing a growing share of your most engaged traffic to it while the rest continues on the shared pool.
Pidgely team
Published
We build Pidgely, the email API that gets you to the inbox. We write about what we learn delivering email, citing the standards and mailbox provider guidelines behind every claim.
A practical IP warm-up guide: how to ramp volume on a new sending IP, which signals to watch at each mailbox provider, and the mistakes that reset reputation.
5 min read
Why separating transactional and marketing email protects deliverability, and how to split streams by subdomain, IP pool, suppression scope and sending policy.
5 min read
Should you run your own MTA or use an email API? A practical comparison of costs, deliverability work, control and vendor lock-in, plus how to stay portable.
6 min read