Do you need email warmup? (yes — here's when and how)

You need email warmup when a sending identity is new to the receiving side — and "sending identity" is three separate things, rated separately, only some of which you control. The domain, the individual mailbox and, if you have one, the sending IP each carry their own history. Warmup is a ramp on volume from an identity with no history, and the decision to run one turns entirely on which of the three is new. A new domain always needs it. A new mailbox on an established domain needs a shorter one. A shared provider IP is not yours to warm at all.

The question is which identity is new, not whether warmup works

Most arguments about warmup are unproductive because both sides are describing different situations. Someone whose domain has sent business mail for six years, adding one new address, correctly reports that warmup did nothing. Someone who registered a domain last Tuesday and opened at 300 messages a day correctly reports that it was the difference between landing and being rejected. Both observations are true and neither generalises.

So ask a narrower question. Which identity in this send has no history at the receiver? Everything useful follows from the answer, and the answer is knowable in about a minute.

Three reputations, rated separately, and only some are yours to change

Google Postmaster Tools is the clearest evidence that these are distinct objects, because it publishes two of them side by side with separate definitions. IP reputation is "the quality rating for the IP addresses you use to send email". Domain reputation is "the quality rating for the domains you use to send email". Two ratings, computed independently, for the same stream of mail.

The third identity is the individual sending address and the envelope path attached to it. No provider publishes a per-address score, but the behaviour of a specific mailbox — how many it sends, to whom, at what hours, and how often anyone answers — is observable, and a mailbox that has never sent anything and then sends two hundred messages before lunch is a pattern shift regardless of how good its domain's history is.

Now the part that decides your work. Which of the three can you actually move?

• The domain: always yours. You registered it, you publish its DNS, and every send from it accrues to it.
• The mailbox: always yours. Its send pattern is a setting you control.
• The IP: usually not yours. Send through Google Workspace and the connecting IPs are Google's, shared with every other tenant. Microsoft 365, the same. A shared ESP pool, the same. There is nothing to warm because there is nothing you own.

That last point removes an entire category of advice from most people's plans. If you do not have a dedicated IP, "IP warmup" is not a task you can perform, and any tool that claims to be doing it for you on shared infrastructure is describing something else.

A decision run: seven situations and the answer for each

Work through these and stop at the first that matches.

• A domain registered in the last few months, no sending history. Ramp, and stretch it. Three weeks is the floor; four to five is safer, because the domain history and the address history are being built at the same time and neither is carrying the other.
• A new mailbox on a domain that already sends business mail. Ramp, shorter. One to two weeks. The domain is vouching for the address, so what you are establishing is a plausible pattern rather than a reputation from zero.
• Same domain, new sending platform. Ramp the volume, and fix authentication before you send anything at all. Changing platforms usually changes the Return-Path and the DKIM selector, which is an alignment change, not a reputation change — and a ramp spent on a misaligned setup is three weeks of proving it is broken.
• A domain that has sent transactional mail only, now starting cold outreach. Do not do this on that domain. Its history is with recipients who asked for the mail; cold outreach has a different complaint profile, and the domain carrying your invoices and password resets should not be the one absorbing it. Register a separate sending domain and ramp that.
• Resuming after a long pause. Ramp. A dormant identity is closer to a new one than to an active one, and resuming at the volume you stopped at is a spike.
• Taking a dedicated IP. A different and longer process — see below.
• A domain already filtered into spam. Not a warmup situation. A ramp shapes future volume and cannot retract complaints that have already been recorded. Fix authentication, verify the list, and then decide between a recovery period and a fresh sending domain. What warmup can and cannot repair is the argument in full.

Warming a domain, a mailbox and an IP are three different jobs

They are usually discussed as one thing. The timescales alone show they are not.

A mailbox ramp is short and shaped. Autocloz ramps a newly connected mailbox over a configurable duration defaulting to 21 days, replacing the configured daily limit with a smoothstep value each day so the first derivative of the volume curve looks like a person's rather than a spreadsheet's. It runs automatically on every connected mailbox through inbox warmup.

A domain ramp is about the organisational domain rather than any one address, and it is the one people skip because it has no obvious knob. It is also the one that matters most when the domain is new, because every address on it is starting from the same zero.

An IP warm-up is a different scale entirely, and Amazon SES documents it precisely enough to quote. AWS states that the time required "varies between email providers. For some email providers, you can establish a positive reputation in around two weeks, while for others it may take up to six weeks." Its own automatic warm-up for standard dedicated IPs "steadily increases over 45 days, independently from your sending volume". And crucially, after warm-up AWS says you "should send around 1,000 emails every day to each email provider that you want to maintain a positive reputation with".

Read that last requirement carefully, because it is the argument against dedicated IPs for most outbound teams. Maintaining a warm dedicated IP means roughly a thousand messages a day per provider, indefinitely. A team sending a few hundred a day in total cannot sustain that, and an under-used dedicated IP is worse than a shared one because it has no history to fall back on. Which of the two you should actually be on is a volume question before it is anything else.

What to send during the ramp, which is where most advice stops

A ramp is a schedule. It says how many, not what. The what is the part that decides whether the schedule was worth running, and two vendors document the same answer.

Amazon SES's warm-up guidance: "you should send emails to your most active users to ensure that your complaint rate remains low." Google's sender guidelines for new senders: "start with a low sending volume to engaged users, and slowly increase the volume over time," and avoid sudden volume spikes without historical sending volume.

Both say the same thing in different words. The ramp shapes volume; the recipients decide what the volume is worth. Fifty messages a day to people who will never reply builds a history of fifty ignored messages a day.

For a cold programme that is genuinely awkward, because you have no engaged users yet. The practical version:

1. Start with mail that has a real reason to be answered. Existing conversations, warm introductions, replies to inbound, anything with a relationship behind it.
2. Send from a human, to a human, as plain text. A ramp is not the moment to introduce a tracking pixel, a link-rewriting domain and a four-image template.
3. Then let the earliest campaign traffic be your best-fit segment. The tightest slice of your ideal customer profile goes first, not last. Most programmes do this backwards and spend the ramp on the leftovers.
4. Watch the negative signals, not the positive ones. Bounces and complaints move faster and mean more than opens.

Autocloz's own pool, for mailboxes opted into it, sends synthetic replies to a configurable fraction of warmup mail — half by default — after a randomised delay between five minutes and three hours, on the reasoning that a fixed delay is itself a bot tell. State the honest position on that plainly: no mailbox provider documents that it counts engagement from accounts inside a warmup pool, so treat the reciprocal half as unproven and the volume-shaping half as the part that carries the argument.

How to tell a ramp is working, and what does not tell you

Three measurements answer it. Two popular ones do not.

Does tell you:

• Postmaster Tools domain reputation. Google's bands are defined: High is "History of very low spam rates, and complies with Gmail's sender guidelines", Medium is "History of sending legitimate email, but occasionally sends spam", and the two below that describe regular spam. Movement between bands is real evidence. The catch is volume — Google states data "might be missing if the total number of messages for a given day is too low", so a small programme often sees nothing.
• Inbox-placement seed tests. Mailing seed mailboxes you own at each provider and recording the folder every probe reached. Autocloz records exactly three outcomes — inbox, spam or missing — because the probes are read over IMAP and Gmail's category tabs are not IMAP folders, so a message in Promotions reads as inbox. This is still the only direct measurement of placement available at low volume, but a run happens when you start one; nothing probes on a schedule for you.
• The delivery-error rate. Google's dashboard defines it as "the percent of all authenticated messages (SPF or DKIM) that were rejected or that temporarily failed". A rising number during a ramp means stop, not push harder.

Does not tell you:

• Acceptance rate. A 250 reply means the receiving server took the message. The folder decision happens afterwards, in a separate classifier, and nothing in the SMTP conversation reports it back. A dashboard showing 99% delivered sits comfortably above a campaign that produced nothing.
• Open rate. Machine prefetching means a recorded open is frequently a machine, not a reader, so an open rate during a ramp is measuring image-fetching infrastructure at least as much as it is measuring humans.

The mistakes that make a ramp pointless

Each of these is common enough to be worth naming, and each wastes the full three weeks before you find out.

• Ramping before authenticating. A ramp on a domain with no DKIM key published proves nothing except that the setup is broken, slowly. Publish and verify SPF, DKIM and DMARC first, then start the clock. Reading your own authentication records is a ten-minute job and it goes before day one.
• Treating the end of the ramp as a finish line. The ramp releases the ceiling; it does not remove the bounce monitoring, the placement checks or the pacing. Those stay on.
• Ramping while importing an unverified list. Hard bounces during a ramp are charged against an identity that has nothing else on its record yet, which is the worst possible time to generate them.
• Running the ramp on the domain you cannot afford to lose. Cold outreach belongs on a domain whose failure costs you a registration fee, not your password resets.
• Raising the daily limit and expecting more sends. During a ramp the daily limit is not the binding constraint; the ramp multiplier is. The warmup planner shows which constraint binds on which day before you change anything.

Autocloz's free plan covers 5 users and 10 mailboxes with the 21-day ramp, on-demand seed tests against mailboxes you register yourself, and SPF, DKIM and DMARC monitoring on each connected domain — start free and let the ramp run on a fresh domain while you build the list it will eventually mail.

What warmup cannot do, and what Autocloz does not do here

Warmup cannot be compressed. The elapsed time is the mechanism — a history is a sequence of days, and there is no configuration that turns 21 days into five. A tool offering a faster ramp is offering a steeper volume curve, which is the opposite of the thing being bought.

Warmup cannot warm an identity you do not own. On shared provider infrastructure there is no IP to warm, and no product can warm one for you.

Warmup does not transfer. Reputation is gathered per receiving provider, so a domain with a healthy history at Gmail has established nothing at Microsoft, and the two move independently. Never average them into one health score.

Warmup cannot be measured directly. Everything above is a proxy — a published band, a seeded probe, an error rate. Nobody outside Google, Microsoft and Yahoo can see the classifier, and a vendor quoting you a precise reputation number for a domain is quoting its own model, not the receiver's.

And Autocloz specifically: it does not sell a peer-to-peer bot warmup network as a standalone product, and it does not claim the reciprocal-mail mechanism is proven — the comparison against dedicated warmup tools is honest about which half of warmup has evidence behind it. It runs the ramp, the pool, the seed tests and the authentication monitoring; it cannot see inside a filter, cannot repair a domain that has already accumulated complaints, and cannot make a ramp substitute for a list you have not verified.