Email Warmup Ramps Toward Limits Nobody Publishes

Email warmup is the practice of raising a sending domain's volume gradually instead of starting at full rate, usually with automated exchanges between mailboxes to generate opens and replies along the way. It is a sending-layer process. It changes how you send. It changes nothing about who you send to, and that distinction decides most cold campaigns.

The disclosure first. We build Keaz Signals, which sells an ecommerce leads database with live buying signals and sends outreach through the customer's own Instantly workspace. We do not sell warmup, we do not manage anyone's DNS, and we have no warmup product for you to buy. That is why this post can describe the practice plainly.

Warmup exists because mailbox providers judge a domain by its history. A domain with no history that suddenly sends thousands of messages looks exactly like a domain bought in order to send thousands of messages. Warmup is an attempt to build that history before a campaign needs it — a separate job from publishing the three authentication records, which is done once and then holds.

Google publishes a direction, not a schedule. Its Email sender guidelines carry a section headed "Increase sending volume slowly to avoid delivery problems", and the advice inside it is to "Start with a low sending volume to engaged users, and slowly increase the volume over time." There is no daily number in it, and no duration.

What the page does give is a set of operating rules. Send at a consistent rate and avoid sending in bursts. Avoid sudden volume spikes without a history of sending large volumes — the example given is that "immediately doubling previously sent volumes suddenly could result in rate limiting or reputation drops." Increase a modified segment of traffic separately after any significant change to your sending infrastructure or headers.

It is also specific about where the ceilings sit: DKIM and SPF quotas are per domain, while the IP address quota is shared by everyone sending from that IP — so a neighbour on a shared IP can stop your sending without touching your domain. When you exceed a quota, Gmail typically rejects with SMTP error 4.7.28, and the documented recovery is to stop for at least ten minutes, resume on a single connection, and add connections back one at a time.

That is an operating procedure, not a calendar. Every warmup schedule you have seen with confident daily figures is somebody's interpolation between those sentences.

Microsoft is more explicit than Google: it will not tell you the numbers, and it says why. Its outbound spam documentation describes accounts being blocked once they exceed "an undisclosed limit", and footnotes the whole section:

We don't advertise the exact limits so spammers can't game the system, and so we can increase or decrease the limits as necessary. The limits are high enough to prevent an average business user from ever exceeding them, and low enough to help contain the damage caused by a spammer.

The same page states that using Microsoft 365 to send bulk email "isn't a supported use of the service, and is permitted only on a 'best-effort' basis", and that messages judged to be spam are delivered from a secondary, less reputable IP pool it calls the high-risk delivery pool. Its recommendation for anyone sending volume is structural: do not use addresses in your primary domain, and run bulk traffic from a dedicated subdomain with its own SPF, DKIM and DMARC records.

So two of the largest mailbox operators in the world agree on the shape of the advice — ramp, stay consistent, separate your bulk traffic — and neither will publish the threshold. A warmup tool cannot be calibrated against a number that does not exist publicly. It can only ramp and watch.

Google does publish one hard figure, and it is not about volume at all. Keep the spam rate reported in Postmaster Tools "below 0.10%" and "avoid ever reaching a spam rate of 0.30% or higher". That is a measure of how recipients react to you. It says nothing about how much you sent.

The guidelines add that a low spam rate makes a sender "more resilient to occasional spikes in user feedback", and that a high one leads to increased spam classification which takes time to unwind even after the rate improves. Reputation is slow in both directions, which is the real reason a ramp is worth doing carefully rather than quickly.

One more line on that page is worth sitting with if your reporting leans on opens: Google states that it does not track open rates, cannot verify open rates reported by third parties, and that low open rates "aren't necessarily an accurate indicator of deliverability or spam classification issues". The number that counts is the one in Postmaster Tools.

The mechanism is the point. Warmup adjusts the sending side of a ratio whose numerator is set entirely by recipients. You can ramp flawlessly and still be marked as spam by people who had no reason to hear from you.

Warmup does a real job, and it does it well. It stops a brand-new domain from being judged on a cold start. Consistent, gradually rising volume from an authenticated domain is precisely the pattern both guideline sets describe, and producing that pattern by hand is tedious and easy to get wrong. That is worth automating.

What a ramp cannot reach is the list. Nothing in a schedule makes a store a plausible buyer, or changes whether the message arriving on day thirty has a reason behind it. Adding mailboxes does not help either — more inboxes is not the same thing as more sending capacity.

And here is the uncomfortable part, which we would rather state than step around. Google's guidelines are written around subscription mail. They say plainly: "Don't send messages to people who didn't sign up to get messages from you," and "Don't purchase email addresses from other companies." Cold outreach to businesses sits outside the practice those sentences describe, whoever supplies the addresses, including us. That is a structural observation about what the guidelines cover, not a claim about anyone's compliance — and the spam-rate threshold judges the result either way.

We are not going to tell you how many days a warmup takes, or what inbox rate it buys. We did not measure either one, and neither figure would survive contact with your domain, your copy and your list.

A days-to-warm number would have to be calibrated against thresholds that Microsoft states it deliberately does not publish, and that Google expresses only as a direction. Any specific schedule is therefore a guess wearing the clothes of a standard. Google is blunt about how far anyone's promise reaches here: it does not accept allowlist requests from email providers, and states that it "can't guarantee messages sent by email providers will pass Gmail's spam filters". If Google will not guarantee it, nobody downstream of Google can.

The one thing we can say about our own sending is a count with a date on it: zero burned domains as of September 2026. That is our domains, our content and our list. It is not a benchmark, and we are not going to reverse-engineer it into a recipe for yours.

The ramp decides how fast the first campaign goes out. Which stores are on it decides whether it works. A perfectly warmed domain sending to a list with no current reason behind it produces exactly the complaints that undo the warmup.

A store that switched on Meta ads this week, launched a product or installed Klaviyo has a reason that did not exist a fortnight ago. Those are the events in our buying signal catalogue, and what our sales agent writes the first line from. The ecommerce leads database watches 4.1M Shopify and WooCommerce stores across Europe and North America as of September 2026; the first 1,000 leads are free.

The boundaries, so you can rule us out fast: no LinkedIn signals or sending, no CSV export, Shopify and WooCommerce only, those two regions only. Sending runs through your own Instantly workspace, which is where warmup belongs.

• Google, Email sender guidelines (Gmail Help) — sections on increasing sending volume, spam rate and open rates quoted. Retrieved 18 September 2026.
• Microsoft, Outbound spam protection for cloud mailboxes (Microsoft Learn) — undisclosed limits, high-risk delivery pool and bulk-mail recommendations quoted. Page states last updated 21 May 2026. Retrieved 18 September 2026.