Whether you should move to a dedicated sending IP comes down to a single number: your sustained daily volume to each mailbox provider. Not your budget, not your brand, not whatever your ESP's sales team calls its "premium" tier. If you take one thing from this article, take this — a dedicated IP under-fed with thin, bursty traffic delivers worse than a well-run shared pool, because to Gmail and Microsoft it looks exactly like a snowshoe spammer renting a fresh IP to shed a bad reputation.
The "dedicated equals better" instinct is backwards for most senders. A dedicated IP means you own the reputation — all of it, good and bad — but reputation only exists when there's enough consistent signal to build it. Below the reputation floor, a dedicated IP's history is too sparse to read, so the filters default to suspicious. You inherit the full downside of ownership with none of the volume that makes ownership pay off.
The number that actually decides this
The working threshold, as of 2026, is roughly 50,000–100,000 messages per day sustained — call it 1.5M–3M a month — before a dedicated IP is viable across the major providers. That figure isn't arbitrary. Gmail and Microsoft build a per-IP reputation model from rolling windows of traffic. Feed them a steady, predictable stream and the signal stabilizes. Feed them 3,000 messages on Tuesday, nothing Wednesday, a 40k campaign Friday, and the model never converges — every send looks like a fresh pattern to evaluate from cold.
The per-provider corollary matters more than the aggregate. You need roughly 5,000+ messages per day, consistently, to each of your top mailbox providers for a dedicated IP to hold reputation there. A sender doing 80k/day total but scattered across two hundred niche domains still starves Gmail and Outlook of the density they need. Sum your steady-state daily volume to your top three destinations. If any one of them sits below ~5k/day, a dedicated IP starves on that provider even when your headline number looks healthy.
How shared and dedicated IPs actually differ
A shared pool is many senders behind one IP, or a rotating set of them. The reputation is collective — you inherit the pool's standing and contribute to it. That sounds risky until you understand that a reputable provider actively culls bad senders off the pool. Volume-spikers, list-buyers, and high-complaint accounts get quarantined or kicked. On a well-managed shared IP your neighbors are pre-filtered, and the aggregate volume keeps the IP warm around the clock — you get the benefit of density you couldn't generate alone. "Shared," from a serious operator, is not "dirty."
A dedicated IP is yours alone. One bad campaign torches only you — but there's no pool to dilute the damage either. You control the cadence, you own the wins, and you eat every mistake at full strength. The tradeoff comes down to four things: cold-start cost (high on dedicated), blast radius of a bad send (contained but concentrated on dedicated), control (total on dedicated), and the neighbor problem (gone on dedicated, managed for you on a good shared pool).
The piece almost everyone misses is that reputation is two layers, not one. There's IP reputation, and there's domain reputation — keyed to the domain in your DKIM d= signature. Gmail has leaned harder on domain reputation every year, and for established senders it is now the dominant signal. Crucially, domain reputation is portable across IPs. Your IP can change; your DKIM signing domain should not. That single fact drives the entire migration strategy below: the IP is just the vehicle, the signing domain is the asset you carry with you.
The thresholds, per provider
Each big provider warms differently, and the slowest one sets your timeline.
- Gmail wants consistent volume and reads per-domain reputation through Postmaster Tools. It tolerates a properly warmed ramp but punishes sudden jumps — a 10x day-over-day spike reliably trips its filters. Enroll the domain in Postmaster Tools *before* you send a single warmup message, so you have baseline data from day one.
- Microsoft / Outlook (Hotmail, Live, Office 365) is the most conservative and the slowest to trust a new IP. Expect aggressive greylisting and
4xxdeferrals for the first days or weeks on a cold IP. Enroll in SNDS (Smart Network Data Services) for per-IP data and JMRP (Junk Mail Reporting Program) for the complaint feedback loop. Budget a separate, slower ramp for Microsoft than for Gmail. - Yahoo / AOL (now Yahoo Mail) is intensely complaint-sensitive. Let the complaint rate drift here and you get throttled fast.
The decision rule doesn't change: sum steady-state daily volume to your top three providers, and if any single one sits below ~5k/day consistently, that provider won't accumulate enough signal to warm a dedicated IP. Low volume spread thin across a dedicated IP with irregular cadence is the textbook snowshoe pattern — a little weight on many footprints to avoid sinking into any one filter's reputation. Filters are built to catch precisely that.
Warming a new dedicated IP: the ramp
Warmup is not optional and it is not fast. Send only to your most engaged segment — people who opened or clicked in the last 30 days — because early engagement is what teaches the provider your mail is wanted. Keep the cadence daily and even. A weekend gap resets momentum; the ramp assumes a continuous send.
Day 1 ~50 most-engaged segment only
Day 2 ~100
Day 3 ~500
Day 4 ~1,000
Day 5 ~5,000
Day 6 ~10,000
Day 7 ~20,000
Week 2 ~40,000
Week 3+ double weekly until you reach steady-state target
Target reached: ~4-6 weeks for Gmail/Yahoo; longer for MicrosoftTreat these numbers as ceilings you only hit if the gates stay green. Gates that pause the ramp:
- Complaint rate climbs above 0.1% (1 in 1,000).
- Hard bounce rate spikes or crosses 2%.
- Gmail Postmaster domain or IP reputation drops to Low or Bad.
If any gate trips, hold at the current volume — do not advance — until it recovers, then resume. Run Microsoft on its own slower parallel track; don't let a healthy Gmail ramp drag your Outlook volume up faster than Microsoft will accept. Use seed-list / inbox-placement testing (GlockApps, Everest) as instrumentation to see folder placement across providers, not as a vanity score — the numbers that matter are your real complaint and bounce telemetry.
The migration mechanics: DNS, PTR, SPF, config
This is the part senders underestimate, and it's mostly DNS.
1. PTR / FCrDNS — do this first, it lags. The dedicated IP must have valid reverse DNS: a PTR record resolving to a hostname whose A record points *back* to the same IP. That round-trip is forward-confirmed reverse DNS (FCrDNS), and Gmail and Microsoft reject or heavily penalize mail from IPs without it. The PTR is delegated by whoever owns the IP block — your host or provider — so request it early; propagation can take a day or more.
# Verify the round-trip on the NEW dedicated IP before you send anything
dig -x 203.0.113.45 +short # -> mail-out1.evilmail.pro.
dig +short mail-out1.evilmail.pro # -> 203.0.113.45 (must match)2. SPF — add, don't replace. Include the new IP or sending host in your SPF TXT record and keep the old one live through the transition. Watch the 10-DNS-lookup limit (RFC 7208) — every include: and a/mx mechanism counts, and stacked includes blow past it fast, yielding a permerror that fails SPF outright.
; keep old IP alongside new during cutover
v=spf1 ip4:203.0.113.10 ip4:203.0.113.45 include:_spf.evilmail.pro -all3. DKIM — change nothing. This is the whole point. Keep the same selector and the same d= signing domain (2048-bit key) so your domain reputation carries straight across to the new IP. Rotating the signing domain mid-migration throws away the one asset that survives the IP change.
4. DMARC — leave it in place. At minimum v=DMARC1; p=none; rua=mailto:[email protected], so you keep receiving aggregate auth reports through the move.
5. MTA config — route by percentage. On Postfix, bind a dedicated transport to the new IP so you can shift a controllable slice of traffic out of it. Define a warmup transport in master.cf:
# master.cf — a transport that egresses via the new dedicated IP
warmip unix - - n - - smtp
-o smtp_bind_address=203.0.113.45
-o syslog_name=postfix-warmipThen route your engaged segment through it with sender-dependent transport maps in main.cf:
# main.cf
sender_dependent_default_transport_maps = hash:/etc/postfix/warmip_senders
# /etc/postfix/warmip_senders -> run postmap after editing
# [email protected] warmip:Everything not matched keeps flowing out the old shared path. That gives you a real dial: expand the set routed through warmip: as the ramp progresses.
Cutover without torching reputation
Never do a flag-day switch. Run the old shared path and the new dedicated IP in parallel and move traffic by percentage, keyed to the warmup: 5% → 25% → 50% → 100%, always starting with your best-engaged segment. The shared path stays live the entire time as your instant rollback — if the new IP's reputation dips, you shift traffic back with a config reload, not a DNS change you'd have to wait out.
Monitor from three independent vantage points, because no single one is complete:
- Google Postmaster Tools — domain and IP reputation, spam rate, SPF/DKIM/DMARC auth percentages, delivery errors.
- Microsoft SNDS + JMRP — per-IP volume and complaint data plus the Outlook complaint feed.
- Your own logs — parse the Postfix
maillogfor4xxdefer and5xxbounce rates by destination domain. This is your earliest warning; providers throttle before dashboards update.
Define abort criteria before you start, not mid-incident: complaint rate over 0.1% on the new IP, Postmaster reputation dropping to Low/Bad, or deferrals from any one provider climbing sharply. Hit any of those, and you roll the percentage back a step and hold.
Pre-flight checklist
Clear every line before you route real volume through the new IP:
- Steady daily volume verified per provider, each top destination ≥ ~5k/day.
- PTR / FCrDNS confirmed in both directions (
dig -xand forward match). - SPF updated, old IP retained, total DNS lookups under 10.
- DKIM selector and
d=domain unchanged; signature verifies. - DMARC published, at least
p=nonewith a workingrua. - Google Postmaster Tools, Microsoft SNDS, and JMRP all enrolled and returning data.
- Most-engaged segment (30-day openers/clickers) defined and queryable.
- Ramp schedule loaded; gates (complaint >0.1%, bounce >2%, rep Low/Bad) wired to alerts.
- Rollback transport (old shared path) still live and tested.
The operator's rule of thumb: if you're not certain you clear the volume floor, you don't — stay shared and put the money into list hygiene, engagement segmentation, and complaint reduction instead. Those improve deliverability on any IP. A dedicated IP only pays off once you're feeding it enough to keep it warm, and an under-fed one is a reputation liability you signed up for on purpose.