Key takeaways
- Warmup exists because reputation is inferred from a pattern over time. A cold IP sending at full volume is an anomaly, not a sender.
- Plan four to eight weeks. Smaller targets ramp faster; anything above roughly 100,000 a day needs the longer end.
- Start with your most engaged recipients. Positive engagement early is what makes the ramp work.
- Never increase by more than roughly double in a day, and hold volume if bounces exceed 2% or complaints exceed 0.1%.
- Microsoft is the strictest during warmup and Gmail the most tolerant. Pace to the strictest receiver, not the average.
A brand-new IP address has no sending history, which means every receiving mail server that meets it has no basis for judgment. Their default posture toward an unknown sender that suddenly starts pushing volume is defensive: rate-limit the connection, greylist the message, route it to spam, or refuse it outright. None of that is a punishment — it is the correct response to a pattern that is indistinguishable from a compromised host.
Warmup is the process of replacing "unknown" with "known and well-behaved" by sending a deliberately small volume of high-quality mail and growing it in steps the receiver can follow. The mechanism is not volume for its own sake; it is accumulating positive evidence — delivered messages, opened messages, almost no bounces, almost no complaints — faster than volume grows.
Get it wrong and the cost is asymmetric. A few days of over-aggressive sending can produce reputation damage that takes months to undo, and there is no support ticket that reverses it.
When you need to warm up — and when you do not
| Situation | Warmup needed? | Why |
|---|---|---|
| New dedicated IP | Yes, full ramp | No history at all |
| Migrating to a new provider on new IPs | Yes, full ramp | IP reputation does not transfer between providers |
| IP dormant for 30+ days | Yes, abbreviated ramp | Reputation fades with inactivity |
| New sending subdomain on warm IPs | Yes, but domain warmup only | Domain reputation is separate from IP reputation |
| Joining an established shared pool | Minimal | You inherit the pool’s IP reputation; only your domain is new |
| Total volume under ~10k/month | Minimal | Below the volume where IP reputation carries much weight |
A realistic warmup schedule
Published schedules vary because the right curve depends on your target volume. What does not vary is the shape: start very small, grow by roughly 50–100% per step, hold at each step long enough for receivers to register the pattern, and prioritise the recipients most likely to engage positively.
The table below targets roughly 100,000 messages a day over six weeks. For a lower target, compress by starting closer to your ceiling; for 500,000 a day or more, extend by doubling the days spent at each tier.
| Week | Daily volume | Recipients | Watch for |
|---|---|---|---|
| Week 1 | 50 → 500 | Most engaged only — recent openers and active users | Any bounce at all; investigate before continuing |
| Week 2 | 1,000 → 5,000 | Add 30-day engaged | Bounce rate; first sign of provider throttling |
| Week 3 | 10,000 → 20,000 | Add 60-day engaged | Postmaster Tools domain reputation begins to populate |
| Week 4 | 40,000 → 75,000 | Broaden gradually | Complaint rate; Microsoft deferrals |
| Week 5 | 100,000+ | Approach full audience | Sustained 4xx deferrals mean you are ahead of your reputation |
| Week 6 | Full volume | Everything | Settle into a steady daily pattern and keep it |
The rules that keep a ramp on track
- Authenticate before the first message. SPF, DKIM, and DMARC must be published, passing, and aligned on day one. Warming an IP that fails authentication accumulates negative evidence, not positive. Setup guide.
- Lead with your most engaged recipients. Opens, clicks, and replies from active users are the positive signal that makes the ramp work. Starting with a cold or dormant segment inverts the whole exercise.
- Never more than roughly double in a day. Larger jumps read as a volume spike from an unproven sender, which is exactly the pattern receivers throttle.
- Hold when metrics degrade. Bounce rate above 2% or complaint rate above 0.1% means stop increasing and fix the input. Pushing through does not work.
- Send transactional mail first if you have it. It has the highest engagement and the lowest complaint rate of anything you send, which makes it the ideal warmup traffic.
- Pace to the strictest receiver. Microsoft throttles hardest during warmup, Gmail is the most forgiving, Yahoo sits between. A ramp tuned to Gmail will stall at Outlook.com.
- Keep the pattern after you finish. Reputation is maintained by consistency. An IP that reaches full volume and then goes quiet for a month is back to being unknown.
How providers differ during warmup
| Provider | Tolerance | Behaviour under strain | Visibility |
|---|---|---|---|
| Gmail | Most tolerant | Spam-folders before it throttles; weights domain reputation heavily | Postmaster Tools — the best data available |
| Yahoo | Moderate | Deferrals and rate limiting; enforces its own complaint threshold | Sender Hub |
| Microsoft | Strictest | Aggressive 4xx deferrals on unknown IPs; weights IP reputation heavily | SNDS and JMRP |
| Corporate gateways | Varies enormously | Silent quarantine with no bounce and no signal | Essentially none |
Microsoft deserves particular attention because it is where most warmups actually stall. Persistent 4xx deferrals from Outlook.com during a ramp are not a bug and not a reason to retry harder — they are a rate limit telling you the IP has not earned that volume yet. The correct response is to slow down, not to push. Registering for SNDS before you start gives you per-IP visibility into how Microsoft sees you, which is otherwise entirely opaque.
Corporate mail gateways are the hardest case because they frequently quarantine silently: no bounce, no deferral, no signal of any kind. If a meaningful share of your recipients are behind corporate filters, seed addresses in those environments are the only way to know what is happening.
What to watch while warming
Bounce rate
< 2%
hold the ramp above this
Complaint rate
< 0.1%
stop and investigate above this
Deferral rate
Trending down
rising means you are too fast
Delivery rate
> 95%
per provider, not blended
Break every one of those down by receiving provider. A blended number will look healthy while Outlook.com quietly defers a third of your mail, because Gmail volume swamps the average. Per-provider visibility is the difference between noticing a stall in week two and discovering it in week five.
- SPF, DKIM, and DMARC published, passing, and aligned before the first send
- Google Postmaster Tools registered for every sending domain
- Microsoft SNDS registered for the IPs being warmed
- Delivery, bounce, and deferral rates segmented by receiving provider
- A written ramp plan with a defined hold condition
- Suppression enforced so bad addresses never enter the warmup traffic
How warmups fail
| Mistake | What happens | Fix |
|---|---|---|
| Starting with a cold or purchased list | Bounces and complaints in week one; the IP is damaged before it has a reputation | Warm on engaged recipients only, never on an imported list |
| Jumping volume to hit a deadline | Throttling, deferrals, and a stall that costs more time than the ramp would have | Plan the ramp backwards from the launch date |
| Pausing mid-ramp | Progress decays; the ramp effectively restarts | Maintain near-daily sending throughout |
| Ignoring Microsoft deferrals | Retry storms make the rate limiting worse | Treat sustained 4xx as a signal to slow down |
| Warming IPs and a new domain simultaneously | Both identities are unknown at once, doubling the difficulty | Stagger them — establish one, then the other |
| Skipping authentication until "later" | The ramp accumulates authentication failures as its history | Publish and verify DNS before message one |
Warmup as a managed service
Everything above is a real project. It needs a plan, daily attention for over a month, per-provider monitoring, and the discipline to hold volume when a launch date says otherwise. It is also work that has nothing to do with your product, and it is where most self-managed dedicated IPs go wrong — not because the team was careless, but because the ramp collided with a deadline.
This is why SuperSend TX does not hand over cold IPs. When you move to Dedicated, we provision the mail servers and addresses, run the full warmup ramp before you depend on them, monitor reputation per provider throughout, and operate the stack afterwards. You get infrastructure that is already warm, not a project.
On the Pool the question does not arise: the network is already warm and carries only paying transactional customers, so a new account inherits established reputation from the first message while its domain reputation builds naturally underneath.
Never receive a cold IP
On Dedicated we provision your mail servers and addresses and run the full warmup ramp before you depend on them — so cutover day is a configuration change, not a six-week experiment.
Related reading