IP warming: how to ramp a new sending IP without burning it

First, the scope line, because two similar-sounding projects get conflated constantly. This guide covers warming an IP address — the infrastructure identity your mail is sent from. Warming a domain, the brand identity in your From address, is a related but separate project with its own guide: how to warm up an email domain. If you've just moved to a new platform or bought a dedicated IP, you may be doing both at once; the last section covers that case. Everything in between is about the IP side.

Who actually needs to warm an IP

Fewer senders than the volume of warm-up content suggests.

If you send from a shared IP pool — the default on nearly every marketing platform — the pool is already warm. Hundreds of customers' traffic flows through those IPs continuously, the platform manages their reputation, and your arrival changes nothing measurable about the IP's history. You have no IP to warm. Your new-sender work is domain-side.

IP warming applies when an IP starts carrying your mail with no recent history of its own:

• You've added a dedicated IP at your ESP.
• You're standing up your own sending infrastructure.
• Your platform migration includes new dedicated IPs.
• A long-idle dedicated IP is returning to service — reputation decays with silence, and an IP cold for months needs re-warming.

Whether a dedicated IP is even the right call is its own decision — argued in full in dedicated IP vs shared IP — but if you have one, warming it isn't optional.

Why receivers throttle unknown IPs

From a mailbox provider's perspective, an IP with no history that suddenly transmits a large volume is indistinguishable from a compromised server — that is the exact signature of a botnet node or a snowshoe spammer cycling fresh addresses. So providers default to distrust: unknown IPs get conservative acceptance limits, and mail beyond those limits is deferred or filtered while IP reputation accumulates.

Warming is the process of building that reputation deliberately: starting at volumes a suspicious receiver will accept, letting positive signals register — delivered mail, opens, an absence of complaints and bounces — and raising volume as trust accrues. The mechanism is the same one described for domains, but the ledger is kept per-IP, and receivers' tolerance for volume anomalies on young IPs is, by common practitioner account, tighter than for young domains.

The ramp

No provider publishes an official warming schedule, so every plan you'll find — including this one — is practitioner convention, and we label it as such. The shape that matters is common to all of them: start small, grow multiplicatively, gate every increase on signals rather than the calendar.

A conservative default we'd stand behind:

1. Days 1–3: low hundreds per day, sent exclusively to your most engaged segment — recent openers and clickers. Their positive reactions are the down payment on the IP's reputation.
2. Then roughly double each step — 500, 1,000, 2,000, 5,000 — holding each level for two or three sending days, spread across the day rather than fired in one burst.
3. Distribute across providers as your list does. Reputation is kept per receiver; warming only Gmail leaves you cold at Microsoft and Yahoo.
4. Gate on metrics at every step. Bounce rate flat, complaint rate near zero, no growing deferral queue → proceed. Anything degrading → hold the level, or halve and rebuild.
5. Continue until you reach target volume. For senders heading to six-figure daily volumes, expect the whole ramp to span several weeks — comparable to the two-to-eight-week range we give for domains, scaled to how far you're climbing.

Send real mail throughout, not synthetic filler: transactional and triggered messages are ideal warming traffic because engagement with them is naturally high and volume is naturally steady.

Reading receiver feedback during the ramp

Warming is a dialogue, and receivers answer in SMTP responses. The one to know by heart is the temporary deferral — 421-class responses, often with text about unusual volume or rate limiting. Gmail's variants are listed among the error codes on our Gmail sender requirements page. A deferral during warm-up is not a failure; it's the receiver saying "not this much yet." Your platform retries automatically, and the correct response is to hold your current volume level longer, not to push harder into the limit.

Watch three dashboards while you ramp: your platform's deferral and bounce reporting per receiving domain, Google Postmaster Tools (register the sending domain before day one), and — for a dedicated IP — periodic checks against public blocklists with the blacklist checker, since young IPs inherit whatever their previous tenant did with them. Checking the IP's PTR record before first send belongs on the same pre-flight list; the reverse DNS checker covers it.

Keeping a warm IP warm

Warming isn't a one-time task with an end date; it's the start of a volume contract. IP reputation is sustained by consistent sending, and two patterns break it:

Gaps. A dedicated IP that goes quiet for weeks cools. Return sends after a long gap behave like warm-up sends and deserve a mini-ramp, not a full-volume campaign.

Spikes. A stable 10,000-a-day IP that fires 300,000 on Black Friday presents the volume anomaly receivers filter defensively. Seasonal senders should ramp into peaks over preceding weeks — which requires having list and content reasons to send, another argument for planning warming into the calendar rather than around it.

The steady-state rule: an IP is happiest carrying roughly the volume it carried yesterday, plus or minus the kind of growth that looks like a business rather than a breach.

Warming an IP and a domain at once

A platform migration to a dedicated IP means two cold identities — new IP, and often a new or newly-signing domain — and receivers evaluate both. The good news: one careful ramp warms both simultaneously, since the same engaged-first, volume-gated sends build both ledgers. The differences worth respecting: confirm authentication before the first warming send (the email authentication checker verifies SPF, DKIM and DMARC in one pass, and the domain-side details live in the domain warm-up guide), and be stingier with early volume than either schedule alone suggests, because you have no warm identity for receivers to fall back on.

Related guides

• How to warm up an email domain — the brand-identity side of the same discipline
• Dedicated IP vs shared IP — whether you should own this problem at all
• IP reputation — the ledger warming builds
• Blacklist checker — check a new IP's inherited history before first send
• Reverse DNS checker — the PTR pre-flight for self-managed infrastructure
• Gmail sender requirements — the deferral codes you'll meet during the ramp

About this guide

Written by InboxRatio Editorial. Warming schedules are practitioner convention — no mailbox provider publishes one — and this guide labels its ramp accordingly as a conservative default. Provider behaviors cited (deferral codes, reputation tracking) come from the providers' published documentation.

Methodology

InboxRatio's platform benchmark sends from identically prepared infrastructure precisely because unequal warm-up would corrupt placement comparisons; warming discipline is part of every test cycle's controls. The protocol is documented in how we test, and our source rules in sources.

Last updated

3 September 2026. Ramp guidance and provider behavior reviewed quarterly.

Frequently asked questions

What is IP warming? Gradually increasing sending volume from an IP address with no recent history, so mailbox providers can build a positive reputation for it instead of throttling it as a suspected compromised server. It applies to dedicated IPs; shared pools arrive pre-warmed.

How long does IP warming take? Weeks, scaled to target volume — a ramp to a few thousand daily messages can complete in a couple of weeks, while six-figure daily volumes commonly take a month or more. The finish line is stable acceptance and clean metrics at target volume, not a calendar date.

Do I need to warm an IP on a shared pool? No. Shared pool IPs carry continuous traffic from many senders and are managed by the platform. Your warming obligation on a shared pool is domain-side only — see the domain warm-up guide.

What happens if I skip IP warming? Expect deferrals and rejections at major providers, heavy spam foldering of what does get through, and a first impression on the IP's permanent record that takes longer to repair than warming would have taken. If it already happened: drop to small engaged-only sends and rebuild the ramp.

Can I automate IP warming? Many ESPs automate the throttling — capping your dedicated IP's daily volume on a rising schedule and overflowing the remainder to shared IPs. That automation is worth using; it doesn't replace watching your per-provider deferrals and complaint metrics during the ramp.

Does IP warming guarantee inbox placement? No. Warming removes the unknown-sender penalty from the IP. Placement afterward rides on authentication, list quality, engagement and content — the same inputs as always.

Before the first warming send, clear the pre-flight in one sitting: authentication verified, PTR resolving, blocklist history clean — the email authentication checker handles the first item in under a minute.