Mailbox warm-up: what actually matters

Warm-up is not a countdown. It is the accumulation of a sending history, and a mailbox only accumulates history on days it actually sends. Most warm-up schedules get this backwards: they count calendar days since the mailbox was connected, so an account that sat idle for a fortnight arrives at "day 15" holding a full daily allowance and no history whatsoever. Below is what the mailbox providers put in writing, what they deliberately do not, and where the line between the two sits.

What is mailbox warm-up, actually?

It is the practice of starting a new sending identity at low volume and raising it gradually while you watch how receivers respond. M3AAWG splits the process into two named phases in its Sending Domains Best Common Practices:

Building domain reputation occurs in two primary phases: the warm-up phase, which brings the sending domain from unknown to noticed, followed by the ramp-up phase, which allows the sender to gradually reach their planned, long-term sending volumes.

M3AAWG Sending Domains Best Common Practices, October 2019

The load-bearing word there is "unknown". A brand-new sending identity is not neutral, and the same document is blunt about what unknown is worth:

Reputation usually starts as unknown, which makes it similar to bad in that it does not yet have any positive sending history. A domain with history is generally considered better than if it has none; from the history an ISP can deduce the quality of the behavior over time (good or bad), while no history would cause the filter to treat the incoming message with more scrutiny and caution.

M3AAWG Sending Domains Best Common Practices, October 2019

That is the entire case for warming up. You are not waiting out a timer. You are manufacturing the evidence a filter needs in order to stop applying "more scrutiny and caution". Microsoft says the same thing about IP addresses, in its own words:

IP addresses that have never been used to send email typically don’t have any reputation in our systems. As a result, email from new sources are more likely to experience delivery issues. Once the IP address has built a reputation for not sending spam, Microsoft 365 typically allows for a better email delivery experience.

Microsoft Learn, "Troubleshooting mail sent to Microsoft 365"

What is sender reputation actually built on?

Microsoft publishes the ingredient list outright: "Many factors influence Microsoft 365 filtering. For example, the sending IP, domain, email authentication, list accuracy, complaint rates, content, and more. One of the principal factors in driving down a sender’s reputation and their ability to deliver email is their junk email complaint rate."

Google puts a number on the complaint half: "Keep spam rates reported in Postmaster Tools below 0.10% and avoid ever reaching a spam rate of 0.30% or higher." Google defines reputation in Postmaster Tools as "a rating of the quality of domains and IP addresses used to send email, and is determined by the sending behavior of a domain or IP address." Yahoo asks senders to keep spam rate below 0.3% and notes that "Each IP and DKIM domain has a reputation, which can impact the delivery of your email."

Do the arithmetic at cold-outbound volume and the ceiling gets uncomfortable fast. On a mailbox sending forty messages a day, a single spam complaint on a single day is a 2.5% daily rate — more than eight times the 0.30% figure Google tells senders never to reach. That is an illustration of sensitivity rather than a Postmaster Tools reading: Google computes the rate over Gmail mail alone, as "the percent of your messages that are delivered to engaged recipient’s Inbox and then marked as spam by the recipient", so on a list spread across many domains the denominator is a fraction of forty and the measured figure comes out worse, not better. Small volume does not make the percentage forgiving. It makes it violently sensitive to one annoyed recipient.

If you send through Microsoft 365 or Gmail, what are you warming?

Not an IP address. When mail leaves a hosted tenant it leaves from the provider’s shared outbound pool, and that pool is published in DNS because SPF requires it to be. You can read the whole thing from a terminal.

$ dig +short TXT spf.protection.outlook.com
"v=spf1 ip4:40.92.0.0/15 ip4:40.107.0.0/16 ip4:52.100.0.0/15 ip4:52.102.0.0/16 ip4:52.103.0.0/17 ip4:104.47.0.0/17 ip6:2a01:111:f400::/48 ip6:2a01:111:f403::/49 ip6:2a01:111:f403:8000::/51 ip6:2a01:111:f403:c000::/51 ip6:2a01:111:f403:f000::/52 -all"

$ dig +short TXT _spf.google.com
"v=spf1 ip4:74.125.0.0/16 ip4:209.85.128.0/17 ip6:2001:4860:4864::/56 ip6:2404:6800:4864::/56 ip6:2607:f8b0:4864::/56 ip6:2800:3f0:4864::/56 ip6:2a00:1450:4864::/56 ip6:2c0f:fb50:4864::/56 ~all"

The six IPv4 ranges in Microsoft’s record cover 458,752 addresses; Google’s two cover 98,304. That is what each provider is authorised to send from rather than what is in rotation on a given day — SPF describes the boundary, not the occupancy — and it carries every tenant’s outbound mail. You cannot warm those. One tenant’s traffic is also a small enough share of the total that you are unlikely to move them far in either direction, though that is an inference from the scale rather than something either provider publishes.

What you can move is the reputation attached to your domain, your DKIM signing domain, and the behaviour of your individual account. Microsoft notes the two are linked in the other direction as well: "New IPs for domains with existing SPF records typically experience the added benefit of inheriting some of the domain’s sending reputation." So for a hosted mailbox, warm-up means domain and account warm-up. M3AAWG describes how that reputation forms in a single sentence: "Reputation is quickly built from sending activity performed on a subdomain." Sending activity. Not elapsed time.

Why is a ramp measured in calendar days wrong?

Because the input to reputation is messages, and calendar days do not produce messages. The failure mode is specific and common. You connect the mailbox on a Monday, then clean the list, argue about the ICP, get legal to read the footer, and two weeks disappear. On day fifteen the schedule says forty a day, so forty go out — and the first message the filter has ever seen from that account arrives as one of forty. That is exactly what Google tells senders to avoid: "Avoid introducing sudden volume spikes if you do not have a history of sending large volumes." A history of sending, not a history of existing.

Microsoft’s own estimate of how long a ramp takes is explicitly conditional on sending, not on waiting: "A new IP can expect to be fully ramped within a couple of weeks or less depending on volume, list accuracy, and junk email complaint rates." Volume is the first variable in that sentence. A fortnight of sending and a fortnight of silence are not the same fortnight.

Why does steady daily volume beat bursts?

Google says it in two separate documents, in plain imperative English. The sender guidelines attach the advice to a qualifier — the bullets sit under "If you send large amounts of email, we recommend you:" — and then read: "Send email at a consistent rate. Avoid sending email in bursts." And: "Start with a low sending volume to engaged users, and slowly increase the volume over time." The Top 10 Gmail sender issues page carries no such qualifier. It has a section headed "Ramp up slowly" — "Increasing your sending volume too quickly can result in delivery issues." — and another headed "Maintain consistent sending volumes", which gives the intraday version: "Pace your email traffic to send at consistent volumes throughout the day and over several days to avoid random spikes in email sending volume."

M3AAWG ties consistency to the reputation itself. Reputation forms per sending segment, and each segment "can create and grow its own reputation, which requires sufficient and relatively consistent traffic volume. Lapses in sending or major fluctuations in traffic volume can impact both forming and sustaining sending reputation." Consistency is not politeness; the shape of the volume curve is itself an input. Why an abrupt step is read badly is not something any provider spells out — the usual explanation, that it looks like a compromised account, is reasonable but unpublished. What is published is the instruction, from Google and M3AAWG independently, to avoid the step. Microsoft is not a third voice here: it describes a new IP becoming "fully ramped", but publishes no guidance on how to pace one.

Microsoft documents a throttle of that shape, though it attributes the trigger only to "suspicious activity" and never names volume as the cause: the NDR "451 4.7.550 Access denied, please try again later", issued "because suspicious activity was detected from the source IP address. Mail from the source has been temporarily restricted while it’s being evaluated." That code is IP-scoped and unlikely to be yours on a hosted tenant, but the shape — throttle first, evaluate second — is what you are trying not to trigger.

One thing a ramp is definitely not: your provider’s published limit. Exchange Online allows 10,000 recipients per day and 30 messages per minute on the common Microsoft 365 plans, both per mailbox, with a separate tenant-wide cap on external recipients per day — the Tenant External Recipient Rate Limit — that scales with the tenant’s licence count. Google Workspace allows 2,000 messages a day for standard accounts. Those are abuse ceilings, not recommendations, and Microsoft says as much in the footnote to its own table: "Exchange Online isn’t suited to accommodate bulk-mailing scenarios." Treating the cap as a target is how a warm-up schedule turns into an incident.

Does domain age matter, and can anything speed it up?

Partly, and no. The well-documented part is short and absolute. Spamhaus operates a Zero Reputation Domain list whose entire premise is that a freshly registered domain is suspicious on sight: "This lists newly registered domains for 24 hours," on the reasoning that "New domains typically don’t send email in the first 24 hours." There is no appeal — "we do not accept requests for removal from this blocklist" — and "The domain will be automatically removed from the blocklist after 24 hours." The only exit is the clock. Note the scope: this bites only where the receiving mail system subscribes to that feed. It is not a rule of the internet.

Check your own domain’s registration date with RDAP, the machine-readable successor to whois. For .com the authoritative server is Verisign’s.

$ curl -s https://rdap.verisign.com/com/v1/domain/MICROSOFT.COM \
    | python3 -c "import sys,json;[print(e['eventAction'],e['eventDate']) for e in json.load(sys.stdin)['events']]"
registration 1991-05-02T04:00:00Z
expiration 2027-05-03T04:00:00Z
last changed 2026-01-29T18:46:57Z
last update of RDAP database 2026-09-02T00:54:09Z

Past the first twenty-four hours, be careful what you claim. Whether a filter still discounts a three-month-old domain against a ten-year-old one is asserted constantly and published by no major mailbox provider. Treat it as a reasonable prior, not a documented rule. What is documented is that sending history matters, and history takes time only because it takes sending. Buy a domain today and park it for six months and you have a six-month-old domain with the reputation of a brand-new one.

Do automated warm-up pools work?

The mechanic is straightforward. You hand a warm-up service access to your mailbox and it enrols you in a network of other participating accounts. It sends mail from you to them; they mark it not-spam, drag it out of the junk folder, and reply. The intent is to manufacture the engagement signals a filter reads.

Two structural problems are worth naming, without passing judgement on any particular vendor. The first is that the engagement is not from your recipients. Google’s instruction is to start "with a low sending volume to engaged users" — engaged with your mail, on the domains you will actually be mailing. Reciprocal traffic inside a pool is engagement with the pool, and whether a filter treats the two as equivalent is not verifiable from outside it.

The second is access. To open, file and reply to messages on your behalf, a pool needs read and write access to the mailbox — IMAP credentials, or OAuth scopes that can read and modify mail. On Google that means a restricted scope; delegated Mail.Send on Microsoft Graph cannot do it either. That is a real security decision, and a sharper one if the mailbox belongs to a client. It also cuts the other way as a design constraint: Decknative requests only gmail.send and delegated Mail.Send, which means it structurally cannot operate a warm-up pool, because it cannot read a message or move one between folders.

On detection, be honest about the evidence. The claim that providers identify and discount pool traffic is repeated in every article on the subject and documented in none of them. Reputation models at Gmail, Outlook and Yahoo are proprietary and unpublished; nobody outside those teams can demonstrate either that pool traffic is caught or that it is not. What you can read is the contract. The Google Cloud Acceptable Use Policy, which is the AUP published under the Google Workspace terms, prohibits using the services "to test or reverse-engineer the Services in order to find limitations or vulnerabilities, or to evade filtering capabilities, except as expressly permitted in the Agreement." Whether coordinated inbox activity designed to move a spam filter falls inside that sentence is a judgement call — but it is a call worth making deliberately, before you connect a mailbox you cannot afford to lose.

What should a warm-up schedule actually do?

1. 01Count send-days, not calendar days. Increment the ramp only on a day the mailbox actually delivered at least one message. This is a one-line change in most schedulers and it removes the entire class of bug described above. Decknative counts a mailbox’s ramp this way for exactly that reason.
2. 02Start low and step up rather than jump. M3AAWG’s directional guidance is "Start low and slow; increase sending volume slowly (consider 6 weeks of warm-up as an average)." That average is drawn from bulk sending programmes at far higher volumes than a single mailbox will ever reach, so treat it as a sense of pace, not a schedule to copy.
3. 03Send on every working day of the ramp. A gap is a fluctuation, and M3AAWG names lapses in sending as something that harms both forming and sustaining reputation.
4. 04Spread the day’s sends across the window instead of firing them at 09:00. Google asks for consistent volumes throughout the day, and a burst on the hour is the least human-looking pattern available.
5. 05Get SPF, DKIM and DMARC alignment right before the first message, not during the ramp. Postmaster Tools reports reputation for domains sending DKIM-authenticated mail, falling back to SPF-authenticated mail where DKIM is absent — so unauthenticated mail earns you no attribution in the one dashboard Google does give you.
6. 06Watch the constraint that actually binds at low volume, which is complaints, not volume. One complaint against forty sends is a 2.5% day. Prune the list before you raise the cap.
7. 07Treat bounces and replies as your only real feedback. At forty a day the reputation dashboards stay empty, so hard-bounce rate and reply content are the instruments you have. List accuracy appears in Microsoft’s factor list for a reason.

Which parts of warm-up advice are folklore?

Reputation systems are proprietary, unpublished and actively defended against reverse engineering, so a large share of public warm-up advice is inference presented as fact. Sorting it is the most useful thing you can do with an afternoon.

The honest summary is narrow, which is what makes it worth trusting. Providers document that history matters, that unknown senders get more scrutiny, that consistency helps, that spikes hurt, and that complaints are the fastest way down. They publish no ramp numbers, presumably because they do not want senders optimising against a curve. Past that boundary everything is a guess, and the useful guesses follow from the documented parts: send a little, send it every day you said you would, and count the days you actually sent.