What warmup is for
Warmup is the process of building sending volume gradually on a new domain or IP so that receiving providers can form a reputation for it. A brand new sending identity has no history, and in email an absence of history is not neutral. It is suspicious.
The logic from the receiver's side is simple. A domain that has never sent anything suddenly emitting a hundred thousand messages looks exactly like a compromised or disposable domain. The only way to distinguish yourself is to arrive slowly, to recipients who visibly want the mail.
The caps we enforce, and why
I implemented daily warmup caps tied to a sending domain's age and plan, so a cold domain in its first three days sits on a low per-day ceiling and the ceiling lifts as the domain proves itself. It is enforced automatically rather than advised, because advice does not survive contact with a launch deadline.
George's position on this is that we prevent a day-one hundred-thousand-message send outright, using automatic volume caps and review holds on new domains and accounts. That is not a courtesy to the recipient. A single bad first send burns the domain, and on a shared pool it damages every other sender in it.
Nick has been blunt that this trips people up: far too many users hit the warmup process without understanding it, and the fix is clearer expectations rather than looser limits. He is right that the failure is usually communication, not policy.
A realistic 14-day ramp
Chong's planned schedule, engaged recipients firstEngaged first, always
The sequence matters more than the numbers. George's warmup plan is to send to the most engaged cohort first and increase in batches, because early positive signal is what the receiver is measuring. Opens, replies and a total absence of complaints from a small audience are worth far more than volume.
There is a real example of this in our own history: standing up a fresh send to a properly cleaned 10,000-person cohort drawn from 56,444 viable contacts, specifically to let SES reputation recover. The list was large. The send was small and clean on purpose.
We are also building this into the send path directly, with a warmup planner that splits large campaigns into daily batches automatically rather than relying on the sender to pace themselves.
When a dedicated IP is the wrong answer
Dedicated IPs are frequently requested and frequently wrong. Nick's guidance, which matches what we see, is to avoid a dedicated IP below roughly 200,000 messages a month. Below that volume the IP does not receive enough traffic to establish a stable reputation, so it stays permanently unproven and you get worse placement than you would have had in a well-run shared pool.
A new dedicated IP also requires its own careful warmup, exactly like a custom sending domain, so choosing one adds a second reputation to build rather than replacing the first. Get authentication right, warm the domain, keep bounces low, and revisit the IP question only if volume genuinely justifies it.
Before and during a ramp, verify placement with a test send rather than assuming the ramp is working, and watch blacklist status in case a listing is suppressing everything downstream.
Warmup applies to application mail as well, which surprises people: a new domain sending receipts is still a new domain. Transactional email covers that case, and if you are ramping programmatically the email API is where the daily caps are enforced.
Go deeper
References
The primary sources behind the rules on this page. Provider policy and the underlying standards, not vendor marketing.
Common questions
Two to four weeks for a domain going to normal production volume. A clean planned ramp might run 300 to 500 to 800 and upward to around 10,000 a day over 14 days.
Not below roughly 200,000 messages a month. Under that volume a dedicated IP gets too little traffic to build a stable reputation, and a shared pool is usually better.
Throttling, bulk-foldering, or blocking. New domains and accounts carry automatic volume caps and review holds specifically to prevent a day-one bulk send.