Warmup & Migration
A new sending configuration starts without a proven pattern. Warmup builds one. Migration protects the continuity you can keep. Move faster than recipient and provider signals allow, and you can spend weeks recovering.
Facts checked August 2026
Use this when: You are changing email service providers, adding a dedicated IP, moving to a new IP pool, or launching a new or dormant sending domain.
Treat the schedule as a starting assumption
Most email service providers (ESPs) provide a warmup schedule. Use it for planning, but do not mistake it for a control system.
Mailbox providers publish consistent principles, not one universal day-by-day ramp: authenticate your mail, start at low volume, send to consented recipients with recent activity, increase steadily, and slow down when delivery signals weaken. More specific schedules are vendor defaults or practitioner conventions. That is why they disagree.
A calendar can propose the next volume tier. The evidence decides whether you take it.
Know what you are warming
Reputation is not one portable score. Mailbox providers evaluate the sending domain, IP address, authentication, URLs, sending pattern, and recipient response together.
Keeping the same authenticated sending domain preserves an important continuity signal during an ESP change, but it does not transfer reputation cleanly to a new IP, pool, or provider. A new dedicated IP starts with little or no history. A shared IP arrives with the pool's existing reputation, which you do not control alone.
Plan in weeks, not days. A new dedicated IP commonly needs roughly two to six weeks, depending on the receivers and traffic. If both the IP and sending domain are new or dormant, budget more time. Telemetry, not elapsed time, is the exit criterion.
Run an evidence schedule
I learned the cost of rushing this while warming dedicated IPs for a national retail brand. We increased volume too quickly. Reputation fell, the ramp stalled, and recovery ran backward: cut volume, restart the schedule, and spend weeks re-earning the sending history we had tried to skip.
We eventually reached the target reputation tier. More important, the failure changed the operating rule I use now: advance only when the telemetry remains stable, and step back when it does not.
Start with consented recipients showing recent, durable activity: clicks, purchases, logins, replies, or another first-party signal. Treat opens as supporting evidence, not the gate. Expand one audience tier at a time. Pause when spam reports rise, authentication weakens, or rate-limit and reputation deferrals repeat.
The ramp is not a dated volume plan. It is an evidence schedule with promotion, pause, and rollback gates.
Review receiver telemetry before campaign performance
During the ramp, review receiver and delivery telemetry every day:
Gmail Postmaster Tools: user-reported spam rate, compliance, authentication, and delivery errors; use domain and IP reputation while available.
ESP delivery logs: bounces, blocks, deferrals, and throughput.
Campaign data: clicks, conversions, unsubscribes, and other first-party engagement signals.
Read trends, not same-day cause and effect. Postmaster data typically lags by at least 24 hours and may be unavailable at low volume.
Campaign metrics describe one send. Receiver telemetry tells you whether the infrastructure can support the next tier.
Do not manufacture engagement
Do not use commercial warmup services that manufacture opens, replies, or not-spam actions. That is filter manipulation, not evidence that real recipients want your mail.
Synthetic activity cannot substitute for consented recipients and real behavior. Abusive patterns can still lead to filtering or blocklist listings when you begin sending to the actual audience.
Two artifacts come out of this playbook: a volume-tiered warmup schedule with pause gates attached, and a cutover runbook for moving ESPs or IPs without dropping the trust you already hold.
| Phase | Typical window | Daily volume shape | Audience | | --- | --- | --- | --- | | Establish | Week 1 | Hundreds to low thousands | 30-day actives only | | Build | Week 2 | To roughly 5,000 | 30-day actives | | Stabilize | Week 3 | To 15,000-20,000 | Add 60-day actives | | Scale | Week 4 and on | Toward target | Add 90-day actives last | Ranges, not rules: high-volume programs run the same shape at a larger multiple, and the gates apply identically. Above roughly 100,000 sends a day you should be on dedicated IPs and warming them deliberately; below it, a reputable shared pool is the better start, and the ramp discipline still applies to the domain.