How to warm up an email domain (the 21-day ramp that works)

Warming a domain means sending a small, growing volume of real mail from it for about three weeks before it carries cold campaigns, so that the first thing a receiver learns about the domain is not a spike. Authentication has to pass before day one or the ramp measures nothing. The curve should accelerate and then flatten rather than climb by a fixed amount each day. And the ramp is a schedule for the one variable you control — volume — not a treatment that fixes anything else. Everything below is the schedule, the arithmetic and the failure modes.

What is actually being warmed, and by what

"Domain warmup" is a slightly misleading name for three different jobs that happen at once.

The sending IP has a reputation. If you send through Gmail, Microsoft 365 or a shared relay, that IP is not yours, its reputation is not yours to build, and nothing you do during a ramp changes it. If you send from a dedicated IP you own, it is a separate warming job with its own timeline, and it is the one part of this that genuinely requires volume rather than time.

The domain has a reputation, and this is the one the ramp is for. It is scored at the organisational-domain level, which is why cold outreach belongs on a separate registered domain rather than on the one your invoices come from.

Each sending address carries its own history. This is the level Autocloz actually ramps: warmup_day is a per-mailbox counter on the mailbox record, and the daily ceiling it produces is per-mailbox. There is no domain-level ramp anywhere in the product. A domain warms as a side effect of the mailboxes on it warming, which is fine for the first mailbox and is exactly why the third and fourth need staggering rather than parallel starts.

Knowing which of the three you are working on stops most of the confusion. If the answer to "which reputation am I building?" is "the one belonging to my email provider", the ramp is doing nothing for you and the real work is elsewhere. The decision by scenario is laid out in whether you need warmup at all.

Eight things that must be true before day one

A ramp on a broken setup spends three weeks proving the setup is broken. Each of these is checkable in minutes.

1. SPF resolves, once, under ten lookups. A record over RFC 7208's ten-lookup budget returns permerror and authenticates nothing.
2. DKIM signs, with a selector you can find. Read the s= tag in the DKIM-Signature header of a test message rather than trusting the setup notes.
3. DMARC is published, with an rua= address somebody reads. A policy of p=none satisfies Google's and Microsoft's requirements; you can tighten it later.
4. Alignment passes on a real message. dmarc=pass in Authentication-Results, with your own domain in header.from.
5. MX records exist and an inbox is monitored. A domain that sends and cannot receive loses every bounce notification and every reply.
6. The tracking domain, if you use one, is yours and over HTTPS. A shared tracking host carries other senders' history into your mail.
7. The DNS has existed for more than a few hours. Records that appeared minutes before the first campaign are a shape. This costs nothing because you will spend those days on the rest of this list anyway.
8. The first list is verified. Warming on a scratch list to "save the good addresses" is exactly backwards, for reasons the arithmetic in the next section makes obvious.

The registration and DNS side of that list is covered end to end in setting up a cold email domain.

The ramp day by day, with the arithmetic

Autocloz shapes the curve with a smoothstep rather than a straight line. The ramp factor for a given day is t squared times (3 minus 2t), where t is the day number divided by the ramp length; the result multiplies the mailbox's configured daily limit, and the outcome is floored at one so day one never rounds to zero.

Worked at the shipped defaults — a 40-a-day mailbox on a 21-day ramp — the ceiling by day is:

• Days 1 and 2: 1
• Day 3: 2, day 4: 4, day 5: 6
• Day 6: 8, day 7: 10, day 8: 13
• Day 9: 16, day 10: 19, day 11: 21
• Day 12: 24, day 13: 27, day 14: 30
• Day 15: 32, day 16: 34, day 17: 36
• Day 18: 38, day 19: 39, day 20: 40
• Day 21 onward: 40, the configured limit

Two numbers are worth extracting from that. The curve crosses half its plateau between day 11 and day 12, by design — a smoothstep's midpoint is the middle of the ramp. And the whole 21 days totals 441 sends against 840 for a mailbox already at plateau, which is 52.5% of the throughput. Roughly two thirds of that shortfall falls in the first ten days, which is where the curve is deliberately shallow.

That 441 is the number to plan a fleet around. A mailbox you add today is worth about half a mailbox for three weeks, so adding capacity in response to a shortfall arrives three weeks after you needed it. The warmup planner runs the same curve in the browser if you want to model a different limit or ramp length before connecting anything.

One caveat specific to this arithmetic: if the mailbox is opted into the warmup pool, warmup traffic draws on a share of that same ramped ceiling — up to 30% by default — rather than being added on top of it. That is deliberate. Warmup mail is real mail and the receiving provider counts it identically, so a system where warmup and campaigns have separate counters is a system where a mailbox "warming at 12" while "campaigning at 30" is actually sending 42 on a day whose ceiling was 30.

The ramp counts days, not sends, and that changes how you run it

This is the mechanism most warmup advice never mentions, and it has real operational consequences.

In Autocloz, warmup_day advances when the mailbox rolls into a new workspace day. The roll is what zeroes the day's send and bounce counters, and it fires from either the campaign send path or the warmup dispatcher tick — deliberately from both, because a mailbox that only warms and runs no campaigns used to never roll at all and froze at day one forever. The first roll on a brand-new mailbox only initialises the window and does not advance the counter, so a mailbox onboarded today stays on day one for the rest of today.

The consequence: the ramp is a calendar, not an odometer. A mailbox disconnected for a week, or paused, or sitting behind an expired OAuth token, still arrives at day fourteen with a day-fourteen ceiling and no history whatsoever behind it. The number says 30 and the evidence says nothing.

So treat the ramp position as a permission, not a certificate. If a mailbox has been idle through part of its ramp, resume below its stated ceiling and climb back rather than picking up where the counter says. Nothing in the product can detect this for you, because from the mailbox's point of view a quiet day and a broken day look the same.

Who the first hundred messages should go to

The first ten days total about 79 sends on a 40-a-day mailbox. What you do with those 79 matters more than the number does, because every ratio you are judged on has a denominator that is nearly zero in week one.

At 8 sends on day six, a single spam complaint is a 12.5% rate for that day against a published ceiling of 0.30%. Two dead addresses out of 16 on day nine is a 12.5% bounce rate. There is no volume to average it against and no history to weigh it down. This is the arithmetic that makes week one the dangerous part rather than the safe part, and it inverts most people's instincts about what to send.

Send to recipients with a reason to answer. Colleagues, existing customers, people you have already spoken to, suppliers, your own other mailboxes. The goal in week one is evidence of two-sided conversation, not throughput. Ask questions that get replies. A thread with a reply in it is the strongest positive signal you can generate, and it costs one sentence.

Do not send to anything unverified during the ramp. Do not import a purchased list. Do not use the ramp to "test" a segment you are unsure about — a segment you are unsure about is exactly the thing whose bounces you cannot afford at these denominators.

Autocloz's free plan covers 5 users and 10 mailboxes with the 21-day ramp, the pool and the authentication monitoring included — start free if you want the ramp enforced by the sender rather than remembered by a person.

Three gates that should stop a ramp, and what each one means

The ramp is a plan. These are the conditions under which the plan should stop being followed.

Hold flat when a placement test shows a probe landing in spam at one provider while others are clean, or when bounces are elevated but not extreme. Freeze the daily number where it is for three to five days and let evidence accumulate at that level. Do not climb through a warning; the curve has no idea anything is wrong.

Pause and clean when bounces are high enough to be signal rather than noise. The threshold that matters is the one you can defend, and the sample size matters more than the percentage: Autocloz requires at least 100 sends in the rolling 24-hour window before any bounce threshold can fire, precisely so three bounces out of twelve cannot trip a gate while the number is still noise. During week one you will rarely reach that sample in a day, which means week-one bounce management is a human decision rather than an automatic one.

Start over on a new domain when authentication is provably correct, volume has been held down for two weeks, the list is verified, and placement is still poor. At that point the domain is carrying complaint history that will not decay on a useful timescale, and every further send adds to it. Registering a new domain is cheap; a recovery period is not.

The plateau is a weekly number, not a daily one

Day 21 says 40. What lands in a calendar week is smaller than 280, and the gap is not a deliverability problem — it is scheduling.

A default campaign sending window is Monday to Friday, 09:00 to 17:00. Five days out of seven turns a 40-a-day plateau into an average of 28.6 sends per calendar day, or 200 a week. If the mailbox is opted into the warmup pool, up to 30% of the daily ceiling is reserved for warmup traffic, so campaigns keep a floor of 28 on a working day — an upper bound on the reservation rather than a fixed subtraction, since the pool's own target is often lower than its share.

The eight-hour window has a second effect that only bites at higher limits. A per-mailbox hourly limit defaults to 10 and is not rescaled when someone raises the daily number, so hourly limit multiplied by open window hours is a ceiling of its own. At 40 a day that ceiling is 80 and never binds. At 200 a day it binds hard, and the daily number stops being the thing controlling anything. The full compounding case is worked through in what a warmup network does and does not do.

The planning consequence is simple: quote your capacity as a weekly number derived from the window you actually send in, not as the daily limit you typed into a form. A team that plans on 40 a day and delivers 200 a week will conclude something is broken, and nothing is.

A three-week calendar you can actually run

The curve is automatic. What you do around it is not.

Week one, days 1 to 7 (about 32 sends total). All of it to people who will reply. Verify every address by hand if the list is short enough — at these volumes it is. Read the raw source of at least one delivered message and confirm dmarc=pass with your domain in header.from. Do not start a campaign.

Week two, days 8 to 14 (about 150 sends). Keep warmup traffic running and begin mixing in a small slice of genuinely cold sends near the end of the week, to your best-fit segment rather than your largest one. Run one placement test — the seed test and the ramp share the same mailbox, so the result describes the thing you are about to scale. Read every bounce individually; there will be few enough to do that.

Week three, days 15 to 21 (about 259 sends). Climb to the plateau while watching two things: whether bounces are appearing at all, and whether placement moved between the week-two test and a week-three repeat. If either is worse, hold flat rather than climbing. Finishing at day 21 with a lower number than the curve allows is a fine outcome; finishing on schedule with a domain nobody trusts is not.

Adding the second, fifth and tenth mailbox

The first mailbox on a fresh domain is warming both the address and the domain. The fifth is warming an address on a domain that already has evidence behind it, which is a genuinely easier job — but it is still a new address, and several new addresses appearing on one domain in the same week is its own pattern regardless of how each individual ramp looks.

Stagger by a few days each. Three mailboxes started on Monday, Thursday and the following Monday produce three overlapping curves whose sum grows smoothly; three started on the same Monday produce a step. The sum is what the receiving side sees at the domain level, and the domain level is where the reputation you care about lives.

Keep the count per domain modest. The reason is containment rather than volume: mailboxes on one domain share a reputation, so a single bad list poisons all of them at once, and a domain carrying a dozen simultaneously ramping addresses looks like a platform rather than a team. The fleet arithmetic — how many mailboxes across how many domains a target volume needs — is worked through in scaling outbound without wrecking deliverability.

Day 22 is not a finish line

The most common way to waste a ramp is to treat day 21 as the end of a process rather than the start of a plateau. Three specific mistakes follow from that.

Jumping the plateau. Finishing at 40 and setting 150 on day 22 discards the entire ramp: the shape the receiver learned was a mailbox growing into 40, and the next thing it sees is a mailbox that is not that. If you need more volume, add mailboxes and ramp each one.

Stopping the warmup traffic. A mailbox whose only outbound is cold mail nobody answers is a mailbox whose engagement evidence decays toward zero. Reputation follows recent behaviour, and recent behaviour is a window that keeps moving.

Stopping the monitoring. The ramp ends; authentication drift does not. A vendor's SPF include chain grows and pushes you over ten lookups. A DKIM key rotates and the old selector goes empty. A DMARC record gets edited by someone fixing something else. Autocloz re-checks monitored domains on a background sweep rather than only when someone clicks refresh, which is the difference between finding this in an hour and finding it in a quarter.

What a ramp cannot do, and what Autocloz does not do here

A ramp shapes volume. That is the whole mechanism, and the honest framing of it is that it removes one specific way to fail rather than adding a way to succeed.

It cannot repair a domain that has already accumulated complaints and hard bounces, because it has no mechanism to retract either. It cannot compensate for a list you did not verify, since every invalid address becomes a hard bounce and that is one of the few signals every provider treats the same way. It cannot make an unwanted message welcome; complaint rate measures how recipients feel about being contacted, and no curve changes that.

Autocloz does not sell a peer-to-peer bot warmup network of the kind standalone deliverability services are built around, because no mailbox provider documents counting engagement from accounts inside such a pool and the credential exposure is real — the honest comparison against those products is on the MailReach alternatives page. It does not sell contact data, so the list you warm with is one you bring. Its placement seed tests classify a probe as inbox, spam or missing and nothing else, they are triggered by an operator rather than by a schedule, and they observe monitored mailboxes rather than your actual recipients. And no ramp of any shape settles where a message lands; it removes the failure modes that are documented, measurable and yours to control, and leaves the rest to targeting and to the receiver.