The Sending Domain Warm-Up Ramp: From First Send to Full Volume

This is the procedure for taking a brand-new sending domain from its first message to full cold-outbound volume without landing in spam or getting the domain flagged. It is written for recruiting operations, revenue operations, and anyone answerable for how a sending domain was warmed. It reconciles the conflicting vendor schedules into one ramp curve and a set of graduation gates you can grade against, organized by scenario, so you can run it start to finish without improvising.

The reason this document exists: nearly every top-ranking answer is a vendor blog steering you toward its own warm-up tool, and the numbers openly conflict. One says two weeks, another sets a 30-day floor, a third says four to six. There is no way to reconcile them from inside any single vendor's page. So I anchor this on the one number that is not vendor opinion - Google's spam-rate threshold - and treat every week count as guidance you override when your metrics say otherwise.

What warm-up actually is, and why calendars lie

Warm-up is the process of building a sending reputation by starting at low volume with high-engagement mail and increasing gradually while providers score how recipients react. It is not a waiting period. Providers score engagement, not calendar age, so a domain does not become "ready" on day 21 - it becomes ready when its complaint, bounce, and placement metrics clear the gates.

That distinction is why the published timelines conflict without any of them being wrong. Two weeks, four to six weeks, and an eight-week recovery figure all describe the same mechanism running at different engagement rates. The calendar is a proxy for reputation, and a poor one.

There is exactly one number in this whole domain that behaves like a standard rather than an opinion. Google's own sender guidelines state that senders should keep their spam rate below 0.1% and should prevent it from ever reaching 0.3% or higher. Bulk senders above 0.3% are ineligible for mitigation and remain ineligible until the rate stays below 0.3% for 7 consecutive days. That is a documented threshold with a recovery clause. Build your graduation gate on it.

One more property shapes everything below. Reputation signals lag actual sending by 1 to 2 days and are smoothed over roughly 7 days. Warm-up is therefore a delayed-feedback control problem: by the time a dashboard shows damage, the damage is days old. The slow ramp cadence exists specifically to leave room for the signal to catch up before you increase again.

Which scenario are you in?

Warm-up length depends on what is new, not just on the domain. A full cycle is required whenever you introduce new infrastructure: a new dedicated IP, a new sending domain or subdomain, a new ESP, a resumption after a 90-plus day gap, or a large new list segment. Even experienced senders must complete a full cycle on any new infrastructure.

The re-warm triggers hide a split worth internalizing. Domain guidance cites a 90-day idle gap; dedicated-IP guidance cites 30 days. That is not a contradiction. IP reputation decays to neutral after 30 consecutive idle days, and Microsoft confirms the 30-day figure for IPs, while domain engagement history goes stale at about 90 days. Reputation is tracked separately per IP and per domain. Conflate them and you re-warm too late on IPs, which is the more fragile of the two.

Set the foundation before the first send

Before day one you need separate infrastructure and passing authentication, because an otherwise perfect ramp cannot rescue mail that fails SPF or DKIM. Cold outreach runs on a dedicated domain or subdomain, never your primary business domain. If the outreach domain gets blacklisted, you want it to be the throwaway, not the domain that carries invoices, support tickets, and internal comms.

Authentication is non-negotiable. As of February 1, 2024, senders of more than 5,000 messages per day to Gmail must set up SPF, DKIM, and DMARC, and the From domain must align with either the SPF or DKIM domain. A p=none DMARC policy is acceptable to start. Stage the enforcement: begin at p=none for 30 days, monitor the reports, and once SPF and DKIM alignment reaches 100%, escalate to p=quarantine, then to p=reject after another 30 days.

Name choice matters more than it looks. Prefixes like mail., outreach., team., or hello. all work; avoid noreply., bulk., or newsletter. because they pattern-match to spam filters.

Build in lead time for DNS. Initial setup can take a few hours, but DNS propagation may take up to 24 to 48 hours before authentication is fully active. Do not schedule a first send until you have confirmed dkim=pass in a real message header.

The reconciled ramp curve

Here is where the vendor numbers fight, so here is how I reconcile them. The published step sizes are not directly comparable, because some come from bulk-ESP marketing contexts and some from cold-inbox contexts. Postmark's 20 to 50% per day and MailerSend's 10 to 20% per day describe bulk sending through a shared ESP, where the ESP already carries reputation. For cold outreach at the inbox level, the conservative floor is the one to run.

For cold-outbound inbox-level warm-up, run 1.5x per step every 2 to 3 days. Customer.io names this explicitly and warns that doubling volume at each step is too aggressive. The 2-to-3-day hold is not padding; it is what gives the lagging, 7-day-smoothed signal time to catch up before the next increase. The faster daily-percentage schedules apply to bulk ESP contexts where the platform absorbs the risk you are personally carrying on a fresh domain.

Scaling is arithmetic across inboxes, not volume per inbox. The safe steady-state cap is 20 to 50 sends per inbox per day, fixed by behavioral modeling, not by the platform ceiling. So 1,000 sends a day requires roughly 40 inboxes across 15 to 20 domains, not a bigger per-inbox limit. Warm-up is a per-inbox unit that multiplies. If your volume target is large, provision the inboxes and domains first, then warm each inbox on the same curve.

Warm-up is a per-inbox unit that multiplies, so scale by adding inboxes, never by raising the daily cap.

Run the procedure

Execute these eight steps in order. The one judgement call is when to start real cold sends: some sources run no campaigns at all during the first 14 days, others begin light outreach to your warmest engagers around week 3. I favor beginning light sends in week 3 only if every gate is clean, and holding to seed-only mail otherwise.

The first week is about existence, not volume. Each inbox sends a small number of messages per day, ideally to addresses that will open and reply, so providers see a domain that people actually engage with. Near-zero bounces here matter more than anywhere else in the process.

Most warm-up work is done by generalists rather than specialists, which is exactly why a written procedure like this one earns its keep. In Refolk's index of professional profiles, only 409 US and 65 UK professionals list email deliverability as a skill, and just 19 US professionals carry a dedicated deliverability job title. If you need to bring in real expertise for a large migration or a recovery, you can name the exact profile you want instead of hoping a generalist has done it before.

The graduation gates

A domain graduates when it clears every gate at once and holds them, not when the calendar hits a number. Check all four before each volume increase and before declaring full volume reached.

Read each gate for what it proves and how it lies. Spam complaint rate is calculated daily by Postmaster and moves in 2 to 3 days, so it is your fastest true signal; grade against it first. Bounce rate proves list quality more than reputation - Mailflow Authority sets the bounce ceiling below 3% and says a hard-bounce rate above 5% means stop and clean the list. Inbox placement, confirmed by seed tests, proves where mail actually lands; a "warm" domain shows placement above 90% with no spam-folder flags on seed tests and steady engagement.

Postmaster domain reputation is the summary signal, progressing None to Low to Medium to High, where High means a very low spam rate and rare filtering. But it lies in one specific way that costs teams dearly: it only appears once Postmaster has enough volume, roughly 100 or more daily messages to Gmail. Below that, new domains show "No data available," which is not the same as Low. It means the sample is too small to classify. And the whole rating lags actual sending by 1 to 2 days. So during your most fragile week, the summary signal is either blank or stale.

How this goes wrong

The failure modes below are where warm-up quietly breaks, and each has a false positive that looks like success. Treat this section as the part you re-read before every launch.

• Chasing the published cap. A brand-new Google Workspace mailbox can technically send up to 2,000 messages a day on a rolling 24-hour basis, but doing so lands it in spam and likely gets it flagged. The platform ceiling is not a target. Check: hold 20 to 50 per inbox regardless of the ceiling.
• Reading "No data" as good. New domains show "No data available" in Postmaster because the sample is too small, and operators read the absence of a Bad rating as a pass. Check: confirm roughly 100 or more daily Gmail sends before trusting the reputation field, and grade on spam rate meanwhile.
• Trusting the dashboard in real time. Reputation lags 1 to 2 days and is smoothed over about 7 days, so a Bad rating is already days old when it appears. Check: grade against spam complaint rate first, since it moves in 2 to 3 days.
• Warming on a broken foundation. A perfect ramp cannot rescue mail sent from a domain that fails SPF or DKIM. Check: verify dkim=pass in a real header before day one, not after the first bounce report.
• Bounces early kill you. Bounces during warm-up are far more damaging than on an established domain because there is no reputation buffer - one bad batch in week one can undo two weeks of ramping. Check: verify the list before you send, not during.
• Compressing the calendar under deadline pressure. The most common mistake is sending to the full list on day one because "we can't wait 4 weeks," which destroys brand-new dedicated IPs within 48 hours. Check: enforce the no-campaign window and let the ramp run.
• Gmail-only tunnel vision. Postmaster explains Gmail symptoms only; a clean Gmail curve does not prove Outlook acceptance. Check: run Microsoft SNDS in parallel from day one.
• Turning warm-up off after launch. Cold sends produce negative signals, and without a maintenance baseline the reputation drifts down. Check: keep 30 to 40% warm-up volume running permanently.

Where deliverability talent sits

If you cannot staff this internally, the market is thin and heavily US-concentrated, so hire deliberately rather than hoping a generalist has run a full cycle. Refolk's index makes the scarcity concrete.

The practical implication: the person running your ramp is probably a RevOps or marketing-ops generalist reading the same conflicting vendor pages this playbook reconciles. That is fine if they follow one gated procedure. It is dangerous if they blend three vendor schedules and pick the fastest number from each. When the stakes are a migration or a recovery, source a named specialist - someone who has actually managed ESP migrations and dedicated-IP warm-ups - rather than assigning it to whoever has spare capacity. Refolk lets you ask for that exact profile in plain English instead of scanning résumés for the word "deliverability."

Keep it current after graduation

Warm-up does not end at full volume; it becomes maintenance. Keep a permanent baseline of 30 to 40% of your daily volume, or roughly 10 to 15 warm engagement sends per inbox per day, running indefinitely. Cold sends generate negative signals, and the baseline is what keeps the domain's reputation from drifting down under that pressure.

Re-run this whole procedure whenever infrastructure changes: a new IP, a new domain or subdomain, a new ESP, a 90-plus day gap in domain sending, or a large new segment. Watch the IP clock separately - 30 idle days on a dedicated IP is enough to require a fresh cycle even when the domain is healthy. Review Postmaster and SNDS weekly, and re-check Google's thresholds directly rather than relying on this document, because the mitigation rules are set by the provider and can move. Confirm the current values at the provider's sender guidelines before you plan a large ramp.

Run the ramp on the metrics, not the calendar, and the domain graduates when it is genuinely ready. The week counts are a starting estimate; the gates are the standard.