The mailbox warmup myth — what actually moves the needle

Mailbox warmup does two different things, and only one of them is defensible. Shaping send volume so a new address grows into its limit is real, and it is what stops a fresh mailbox tripping a rate limit on day one. Trading reciprocal bot mail inside a warmup pool is the part sold hardest and evidenced least — no mailbox provider documents that it counts engagement from accounts with no relationship to your real recipients. What is documented is authentication, complaint rate and volume. Start there.

What a warmup network actually does, mechanically

Strip the marketing off a peer-to-peer warmup network and the mechanism is small enough to describe in a paragraph. You hand the tool credentials for your mailbox. It joins a pool of other subscribers' mailboxes. Every day it sends a handful of short messages from your address to pool members, and pool members send some to you. On receipt, the automation on the far side performs the actions a happy human would: it opens the message, moves it out of spam if it landed there, marks it as important, and often sends a short reply so the thread has two sides.

The theory is that a filter watching your domain sees a stream of well-received mail and updates its opinion of you. That is a coherent story. It is also a story that requires the filter to weight per-recipient engagement signals from accounts that will never buy anything from you, never share an organisation with your real prospects, and mail almost nobody outside the pool.

Why reciprocal bot mail is a weak signal

Consider the shape of the interaction graph a warmup pool produces. Several thousand mailboxes, spread across providers, exchange short messages with each other at a steady daily rate, achieve an implausibly uniform open and reply rate, and have almost no edges to the rest of the mail graph. Human mail does not look like that. A real inbox has bursty volume, wildly uneven engagement, threads of different lengths and a long tail of one-off correspondents.

Nobody outside Google, Microsoft and Yahoo can tell you what weight their classifiers put on that pattern, and anybody who quotes you a figure is guessing. But you can reason about the cost asymmetry. If the pattern is being scored positively, you gain something you cannot measure. If it is being scored as an anomaly, you have handed a third party credentials to your sending mailbox and taught it a pattern you cannot inspect. That trade is worse than it looks, and it is why standalone products in this category — the ones benchmarked on the Warmy alternatives page — end up compared on pool size, which is the one number that has no documented relationship to placement.

There is a second, quieter problem. Warmup traffic is still traffic. It consumes the same daily budget your campaigns want, which is a tradeoff worth making deliberately rather than discovering later.

What the receiving side actually publishes

Three sets of requirements are public, dated and enforceable, and they are the only part of this subject where you are not inferring.

Google's Email sender guidelines, in force since 1 February 2024. Google defines a bulk sender as one sending "close to 5,000 messages or more to personal Gmail accounts within a 24-hour period", counted across the same primary domain. Bulk senders must authenticate with both SPF and DKIM, publish a DMARC record on the sending domain — a policy of p=none satisfies the requirement — align the domain in the visible From header with either the SPF domain or the DKIM domain, and support one-click unsubscribe per RFC 8058 on marketing and subscribed mail. Below that volume Google asks for SPF or DKIM and does not require DMARC at all, which is the distinction most summaries of these rules get wrong. Google also states the complaint threshold as a number rather than an adjective: keep the spam rate reported in Postmaster Tools below 0.30%, and as a guideline below 0.10%. Its own FAQ adds that from November 2025 Gmail began ramping enforcement on non-compliant traffic, "including temporary and permanent rejections".

Microsoft's requirements for outlook.com, hotmail.com and live.com, announced 2 April 2025 for domains sending more than 5,000 messages a day. Read Microsoft's announcement carefully, because it says two different things and both are still live on the page. The original text promises non-compliant messages "will first be routed to Junk" with rejection to follow at an unannounced date; an update dated 29 April 2025 states the decision was changed to reject from the same 5 May 2025 start, with the bounce 550; 5.7.515 Access denied, sending domain [SendingDomain] does not meet the required authentication level. Plan for the rejection rather than the Junk folder.

Do not confuse that code with the other Microsoft rejection you will meet. 550 5.7.509: Access denied, sending domain contoso.com does not pass DMARC verification and has a DMARC policy of reject is Exchange Online enforcing a DMARC policy that you published, at any volume. 5.7.515 is the high-volume authentication rule. Same 5.7 prefix, different cause, different fix, and diagnosing one as the other will send you to the wrong DNS record.

Yahoo's sender requirements, published alongside Google's and requiring the same authentication and one-click unsubscribe.

Read that list again and notice what is absent. No provider asks how many bot replies your address received. Every one of them asks whether you authenticate, whether recipients complain, and whether people can unsubscribe without effort.

Check your authentication before you spend a day warming

Warmup does not repair a broken setup. It spends three weeks proving the setup is broken while you wait. Four commands and one header, in order:

1. Read your DMARC record. dig TXT _dmarc.yourdomain.com +short should return a single record beginning v=DMARC1;. Two records is a configuration error and receivers may treat the policy as absent.
2. Read your SPF record. dig TXT yourdomain.com +short and find the string starting v=spf1. Count the mechanisms that trigger a DNS lookup — include, a, mx, ptr, exists and redirect. RFC 7208 section 4.6.4 caps these at ten during evaluation, and exceeding the cap produces a permerror, which most receivers treat as a failure rather than as a warning. Three chained include: statements from three vendors is how most domains quietly cross it.
3. Read your DKIM selector. dig TXT selector._domainkey.yourdomain.com +short, substituting the selector your sending platform issued. An empty answer means the key was generated but never published.
4. Send one message to a mailbox you control and read the headers. The Authentication-Results header, specified in RFC 8601 — which defines the spf and dkim methods, while dmarc is registered separately by RFC 7489 — is the receiving server telling you what it concluded. You want spf=pass, dkim=pass and dmarc=pass, and you want the domain in header.from to be your own. A dmarc=fail on a message that shows spf=pass is the classic alignment failure: something passed, but not for the domain your recipient sees.

The SPF and DMARC record checker runs the first three of those without a terminal, and reading your own authentication records walks through what each field means.

The ramp is a curve, and the curve has a formula

Autocloz shapes volume with a smoothstep sigmoid rather than a straight line. The ramp value for a given day is t squared times (3 minus 2t), where t is the day number divided by the ramp length, and the result multiplies the mailbox's configured daily limit. Ramp length defaults to 21 days. The value is floored at one, so day one never rounds down to zero sends.

The reason for a curve rather than a line is worth stating precisely, because it is usually stated vaguely. A linear ramp adds the same increment every single day. That constant first derivative is the giveaway: no human mailbox has ever grown that way. A real one starts with a handful of messages, accelerates as the person's work picks up, and flattens when they hit the ceiling of what one person can write. The smoothstep curve has exactly those three phases. This is behavioural inference, not published policy, and it should be labelled as such — but it costs nothing over a linear ramp and it is the shape Autocloz applies to every new mailbox automatically.

Why a 200-a-day sender only clears 57

This is the part that gets misdiagnosed as a warmup failure, and it is arithmetic rather than reputation. Take a mailbox configured for 200 sends a day, on day 8 of a 21-day ramp, with Autocloz's shipped defaults. Four throttles compound, each individually correct and each individually invisible:

• The ramp. t is 8 divided by 21, which is 0.3810. The smoothstep value is 0.3248. Multiplied by 200 that gives an effective daily ceiling of 65, not 200.
• The warmup pool reservation. Warmup traffic on an opted-in mailbox is bounded by a share of that same ceiling, defaulting to 0.3. That reserves up to 19 sends, leaving campaigns a floor of 46. It is an upper bound rather than a fixed subtraction — on an early ramp day the pool's own target is usually lower, so campaigns often get more than the floor.
• The hourly limit. It defaults to 10 per mailbox and is never rescaled when someone raises the daily limit. Against an eight-hour sending window that is its own ceiling of 80 a day — not binding on day 8, but it becomes the binding constraint at the plateau.
• The sending window. The default is Monday to Friday, 09:00 to 17:00. Five days out of seven cuts the weekly average by five sevenths, so 46 available sends on a working day averages 32.9 across a calendar week.

Run the same arithmetic at day 21, when the ramp is finished and people expect the full 200. The ramp clears at 200, the pool reserves 60, leaving 140 — but the hourly limit of 10 across eight window hours caps the day at 80 regardless, and five sevenths of 80 is 57 a calendar day. The configured number was 200. The delivered number is 57, and the daily limit was never the thing holding it back.

The lesson generalises past this product. Before you raise a daily limit or blame a warmup ramp, find out which constraint is actually binding. Autocloz names it explicitly rather than making you infer it, using stable keys — warmup_pool_share, warmup_ramp, hourly_limit, min_gap_sec, daily_limit — so that the answer to "why did it only send 57?" is a field rather than a theory. If you want to model the tradeoff between fleet size, ramp length and time to volume before connecting anything, the free email warmup planner runs the same curve in the browser.

Acceptance is not placement, and only one of them is your question

The 250 reply code at the end of a successful SMTP transaction, specified in RFC 5321, means the receiving server has taken responsibility for the message. It does not mean a person will see it. The folder decision happens after acceptance, in a separate classifier, and nothing in the SMTP conversation reports it back to you.

This is why a dashboard showing 99.4% delivered can sit above a campaign that produced no replies at all. Both facts are true. The messages were accepted, and they were filed in spam.

Two instruments close the gap, and they answer different questions. Google Postmaster Tools reports domain reputation, authentication pass rates and the user-reported spam rate against that 0.30% threshold — but Google publishes no minimum volume for it, stating only that data "might be missing if the total number of messages for a given day is too low", withheld to protect user privacy. Most cold programmes never reach whatever that volume is, so the dashboard sits empty exactly when you most want it. Inbox-placement seed tests fill part of that gap by mailing monitored mailboxes across providers and reporting where each probe landed. Be precise about what they can tell you: Autocloz classifies a probe as inbox, spam or missing, and that is the whole vocabulary. There is no Promotions verdict, and there could not be one — the probes are read over IMAP, and Gmail's category tabs are not IMAP folders, so a message sitting in Promotions reads as inbox. Seed tests are also run on demand rather than on a schedule; nothing fires them weekly on your behalf. What they do prove is the thing no dashboard will tell a low-volume sender: whether mail from this domain reaches the folder at all. For the separate question of whether an open even means what you think it means, see why an open rate is a weaker signal than it looks.

Autocloz's free plan covers 5 users and 10 mailboxes with the warmup ramp, the seed tests and SPF, DKIM and DMARC monitoring included — start free if you want to watch the placement number rather than the acceptance number.

How to diagnose a warmup that is not working

Symptom first, then the check that discriminates between causes. Each of these is a different failure wearing the same costume.

• Bounce rate climbs above a few per cent in the first week. This is a list problem, not a reputation problem. Separate the classes before reacting: a hard bounce is a permanent rejection at the recipient address, a soft bounce is a temporary condition like a full mailbox, and treating them identically will make you delete valid contacts. The distinction between soft and hard bounces determines which list you clean. Autocloz pauses a campaign whose bounce rate crosses a configured threshold — set per campaign, else a workspace default, else a 15% safety floor for manual campaigns with nothing configured — and no threshold fires below a 100-send sample, so three bounces out of twelve cannot trip it while the number is still noise.
• Everything is accepted, nothing replies. Run a seed test before touching the copy. If probes are landing in spam, the copy is not the variable.
• Authentication-Results says dmarc=fail while spf=pass. Alignment, not authentication. The domain that passed SPF is not the domain in the visible From header, which usually means the Return-Path belongs to your sending platform rather than to you.
• SPF evaluation returns permerror. You are over the ten-lookup limit. Flattening the record is a workaround, not a fix, because a flattened record goes stale silently when a vendor changes its IP ranges.
• Placement is fine on Gmail and poor on Outlook. These are separate reputation systems with separate thresholds. Do not average them into one health score, and check the DMARC policy specifically, because Microsoft's enforcement is the stricter of the two.
• Volume is far below the configured limit. Almost always the four compounding throttles rather than a deliverability event. Check the binding constraint before changing anything.

If the ramp itself is what you want to run properly rather than diagnose, the 21-day domain ramp covers the schedule and the setup that has to be true before day one.

What warmup cannot fix, and what Autocloz does not do

Being specific about the limits is more useful than another paragraph of reassurance.

Warmup cannot repair a domain that has already accumulated complaints and hard bounces. It shapes future volume; it has no mechanism to retract a spam report that a recipient has already filed. Once a domain is genuinely burned, the honest comparison is the cost of a recovery period against the cost of a new sending domain, and the second is often cheaper.

Warmup cannot compensate for a list you did not verify. Every invalid address is a hard bounce, and hard bounce rate is one of the few signals every provider agrees on.

Warmup cannot make an irrelevant message welcome. Complaint rate is a measure of how recipients feel about being contacted, and no ramp shape changes that.

And Autocloz specifically: it does not sell a peer-to-peer bot warmup network, because the mechanism is undocumented and the credential exposure is real. It does not sell contact data or bundle a lead database, so the list you warm up with is one you bring. It cannot see inside Gmail's or Microsoft's classifiers any more than anyone else can — the seed tests measure the outcome, not the reasoning. And no configuration of any of this makes placement certain; what it does is remove the failure modes that are documented, measurable and yours to control.