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.
How sender capacity grows, and why
Nitrosend now binds capacity to mature, clean delivery volume on the exact sender. Calendar age, payment, imports and validation cannot grant headroom; only committed Nitrosend dispatch units can become evidence after the feedback window.
The delivery authority prevents a day-one bulk send by reserving current commercial and sender headroom before any message becomes provider-eligible. 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.
The send path reports one canonical delivery decision. Pacing shapes admitted work inside current headroom and returns a retry time when work must wait.
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 reports and enforces the same sender-scoped delivery decision.
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 exact senders start with bounded capacity and earn more only from mature clean delivery evidence.