Email warming explained: IP warming vs domain warming (and when you need which)
Warming an IP versus warming a domain are different problems with different timelines. Here's what each is, when you need it, and how to do it without burning your sender reputation.
"Warming" is one of those deliverability terms everyone nods at and few people can actually explain. It doesn't help that there are two different warming processes — IP warming and domain warming — and vendors casually mix them up. This post draws the line clearly and explains when each matters.
What reputation actually is
Mailbox providers score mail on two axes:
- The sending IP's reputation. Has this IP sent mail before? Was it wanted? Was it complained about?
- The sending domain's reputation. Does this domain have valid SPF, DKIM, and DMARC? Is it on any blocklists? Do recipients engage with its mail?
These are scored separately. You can send from a warm domain through a cold IP, or vice versa, and the receiver evaluates each independently. When both are cold, the cumulative effect is worse than either alone.
IP warming
The problem: you've just been assigned a new sending IP (dedicated or newly-rotated pool). That IP has no history with Gmail, Yahoo, Outlook, or the other major consumer mailboxes. Suddenly sending 100,000 messages/day through it looks identical to a spammer setting up a new sending operation.
The signal mailbox providers watch: volume consistency. A mature sender sends a roughly consistent volume day-over-day, with a gradual growth curve. A cold IP jumping from 0 to 100k overnight gets throttled or quarantined.
The warming schedule for a typical dedicated IP looks like:
| Day | Volume | Notes |
|---|---|---|
| 1 | 50 | Send to engaged users only — high-engagement first. |
| 2 | 100 | Double. |
| 3 | 500 | |
| 4 | 1,000 | |
| 5–7 | 2,500 → 5,000 → 10,000 | Doubling each day. |
| Week 2 | 25,000 → 50,000 → 75,000 | Still doubling-ish. |
| Week 3 | 100,000 → 150,000 → target | Plateau when at target daily volume. |
The exact numbers differ per mailbox provider — Google is more forgiving than Microsoft, Outlook.com is the strictest. But the shape (exponential ramp over 2–4 weeks) holds across the board.
Who needs IP warming:
- Moving from shared IPs to dedicated
- First dedicated IP ever
- Adding a dedicated IP to an existing pool
- ESP re-homed your shared pool onto new IPs (rare but happens)
Who doesn't need it:
- Staying on shared IPs (the pool is already warm)
- Sending small volumes (< 5k/day) where cold IP penalties are minor
Domain warming
The problem: you just set up a new sending domain (or subdomain). Even on a perfectly warm IP, the domain itself has no history. Recipients clicking "Spam" on your first emails tank your domain score before you have volume to absorb the hit.
The signal mailbox providers watch: engagement. Opens, clicks, replies, move-to-folder actions. Complaints, deletes-without-reading, spam-reports.
The warming schedule is about engagement quality, not volume:
- Week 1: send only to your most engaged users — the people who will definitely open and click. 80%+ engagement rate is the goal.
- Weeks 2–3: widen to moderately-engaged users. Engagement rate will drop but should stay above 40%.
- Week 4+: add lower-engagement segments; monitor complaints carefully.
Domain warming is less about ramping volume and more about ensuring your early mail produces positive engagement signals. If your first 1,000 messages are to a purchased list, your domain is damaged from day one — and that damage is harder to repair than a slow IP ramp.
When you need both
Launching a new product with a new domain on new dedicated IPs: you need both, simultaneously, and the schedules interact. The conservative approach: warm IP and domain together on the slower of the two schedules (domain warming is usually slower because engagement quality is hard to guarantee).
The automated way
If you're thinking "this is a lot to track manually" — yes. Most serious sending operations automate it:
- Dedicated-IP warming is handled by your ESP. Postscale's warming API lets you declare a target volume and ramp curve, and the system enforces per-IP send limits automatically. Attempted over-sends queue until the day's cap opens up.
- Domain-level warming is mostly your problem — it requires curating your send list by engagement, which the ESP doesn't know.
Common mistakes
1. Skipping warming because "our IPs are shared and already warm." True for IPs, but your domain is still new. Engagement-first sending matters even on warm IPs.
2. Ramping too fast after a warming pause. If you stop sending for two weeks, you partially cool down. Re-warm if you do this for the second time with a new IP.
3. Sending to non-engaged users early. One complaint during warming does more damage than 1,000 complaints at target volume. Your early reputation is fragile.
4. Mixing transactional and marketing on the same IP during warming. Transactional mail is usually well-engaged (password resets, receipts). Marketing is more variable. If you warm with a mix, the marketing drags the score down. Separate IPs or at minimum separate subdomains.
5. Assuming "warm" is permanent. Reputation decays if you stop sending. A once-warm IP that's been idle for 60 days is effectively re-cold.
Further reading
- DNScale: DNS for email — mail server setup basics — the DNS foundation underneath warming
- SPF, DKIM, and DMARC: the 2026 setup guide — authentication is a prerequisite for warming to work at all
- Postscale's IP warming API — programmatic control over per-IP daily caps
Warming isn't optional when you're scaling above ~5,000 daily sends. Skipping it is a six-week deliverability slog you'd rather not discover mid-launch.