Slow vs. Fast Email Warmup: How to Test a Ramp Without Guessing

Every few weeks someone asks the same question on r/Coldemailing: is a slow warmup still necessary for every new mailbox? The replies split clean down the middle. One camp swears by 14 to 30 days before a single cold send. The other says they've gone from zero to 40 a day inside a week on fresh Google Workspace mailboxes with no issues at all.

Both camps are telling the truth about their own setup. Ramp speed doesn't fail or succeed in isolation — it interacts with domain age, provider, list quality, copy, reply rate, and how many mailboxes share the domain. A ramp that works fine on a three-month-old domain sending to verified, highly-targeted lists will cook a week-old domain blasting a scraped list.

So stop collecting anecdotes from people whose setup you can't see. Run the test on your own infrastructure. It takes about three weeks, costs you one spare domain, and gives you a ramp number you can reuse for every mailbox you add after that.

{"h2":"What warmup actually buys you"}

Warmup is not magic reputation points. It does three concrete things:

{"ul":["Establishes a sending pattern. Providers model what normal looks like for a given sender. A mailbox that has sent 4 messages total and suddenly sends 60 is anomalous. A mailbox that has sent 40/day for two weeks and sends 60 is not.","Generates positive engagement signals. Opens, replies, moves out of spam, and messages marked not-spam on the receiving side. This is the part warmup pools are trying to fake, and the part that matters most on Gmail.","Buys you time to find configuration mistakes. A broken DKIM selector, an SPF record over the lookup limit, or a DMARC policy that's quarantining your own mail shows up during warmup at 5 emails a day instead of during week one of a campaign at 300."]}

What warmup does *not* do: fix a bad list, rescue spammy copy, or protect a domain you're also sending 500 cold emails a day from. Those failures are faster and louder than any ramp can absorb.

{"h2":"The two ramp profiles, side by side"}

{"table":{"headers":["","Conservative ramp","Aggressive ramp"],"rows":[["Day 1 cold volume","0 (warmup only, 2-5/day)","5-10/day"],["First cold send","Day 12-14","Day 3-5"],["Day 21 volume","~20/mailbox/day","~40/mailbox/day"],["Day 30 volume","30-40/mailbox/day","50+/mailbox/day"],["Cumulative cold sends, 30 days","~450-550","~1,000-1,200"],["Failure mode","Slow pipeline, wasted mailbox cost","Domain reputation damage, provider throttling"],["Recovery time if wrong","Days — just accelerate","3-6 weeks, often a new domain"]]}}

That last row is the whole argument. Being wrong slowly costs you roughly 600 sends per mailbox over a month — maybe 12-18 replies at a 2.5% rate. Being wrong fast takes every mailbox on that domain offline for three to six weeks, which on a three-mailbox domain is 3,000+ lost sends plus the cost and lead time of replacing the domain.

The asymmetry is about 5:1 against the aggressive ramp. That doesn't mean never ramp fast. It means never ramp fast on your whole fleet at once — test it on a slice you can afford to lose.

{"h2":"Designing the test"}

You need two cohorts that differ in exactly one thing: the ramp curve.

{"ul":["Minimum 2 mailboxes per cohort, 4 is better. Single-mailbox results are noise.","Separate domains per cohort. Reputation is shared at the domain level, so putting a fast and slow mailbox on the same domain contaminates both. Use two sibling domains registered and configured the same day.","Identical DNS. Same SPF, DKIM, DMARC policy, same MX provider, same custom tracking setup (or no tracking in both).","Identical list, split randomly. Not by industry, not by seniority, not alphabetically — random assignment. Same verification standard on both halves.","Identical sequence. Same copy, same number of follow-ups, same timing. If you're also testing subject lines, you've ruined the experiment.","A spare domain, never your best one. The fast cohort is the one you expect might fail. Treat it as disposable."]}

Run both for 21 days. Keep warmup traffic running in the background for both cohorts at the same rate — you're testing the cold ramp, not whether warmup exists. If you need the underlying day-by-day numbers for the conservative arm, use the 30-day warmup schedule as your control curve and build the fast arm as a compressed version of it.

{"h2":"What to measure (and what to ignore)"}

Reply rate is the metric you care about commercially, but it's a terrible test signal at this sample size. At 500 sends per cohort and a 3% baseline, you'd need thousands of sends to detect a one-point difference with any confidence. Only treat reply rate as a tripwire: if the fast cohort drops below half the slow cohort's rate, something is wrong.

The signals that move fast enough to be useful:

{"ul":"**Seed inbox placement**, run on day 5, day 12, and day 21 for both cohorts. This is your primary metric. A 15-point gap in primary-inbox placement is visible immediately and means something. Here's how to [run a placement test properly.","Bounce rate per cohort. Same list, so any divergence above ~1 point is the provider treating one sender differently, not list quality.","Provider deferrals and throttle responses. Gmail 421-4.7.0 and Microsoft 4.7.x / 5.7.x codes are the clearest early warning you'll get. Count them per 100 sends, not in absolute numbers.","Spam complaints and Google Postmaster spam rate, if you have enough volume to register. Anything above 0.1% in either cohort, stop that cohort.","Verified replies and site visits, not opens. Open rates on small cohorts are dominated by security scanners and image prefetch, and they'll show you a difference that isn't there."]}

Decision rule, written down before you start: if the fast cohort holds primary placement within 10 points of the slow cohort, keeps bounces under 2%, and shows no sustained deferrals through day 21, the fast ramp is safe for your setup. Adopt it. If any one of those fails, fall back to the conservative curve and retest in a quarter when the domain is older.

{"h2":"Why some people genuinely can ramp fast"}

When an aggressive ramp works, it's usually because of things that have nothing to do with the ramp:

{"ul":["The domain was registered and had DNS configured 6-8 weeks before the first send, so it isn't actually brand new when the ramp starts.","The list is tightly targeted and fully verified, so bounce rates stay near zero and reply rates run 5%+ — which is itself a strong positive signal.","Per-mailbox volume stays genuinely low (30-40/day across many mailboxes) rather than 100+ on a few. Horizontal scale hides a lot of ramp sins.","They're sending plain text with no links in email one, so there's nothing for a filter to score."]}

If three of those four are true for you, a compressed ramp is a reasonable bet. If none are, the people telling you to slow down are right, and your test will show it.

{"h2":"Re-test when something changes"}

A ramp number isn't permanent. Re-run the test when you switch providers (Microsoft 365 and Google Workspace behave differently enough that a Google-validated ramp will get you restricted on Microsoft), when you change list sources, when a new sender requirement lands, or when you add a materially different offer. Twice a year is a reasonable cadence for an agency; once per new client domain batch is better.

{"h2":"Running the test in Sendvanta"}

Most of the work in a ramp test is bookkeeping: holding two cohorts to different daily caps, keeping warmup traffic constant, running placement tests on schedule, and spotting the moment one cohort starts deferring. Sendvanta handles those pieces — per-mailbox daily caps and ramp curves you set yourself, warm-up that sends real labeled messages inside your own Google or Microsoft workspace, seed-mailbox placement tests you can repeat on a schedule, and deliverability health scoring across mailbox, domain, DKIM, and IP that slows or pauses a sender automatically when risk thresholds are crossed. Engagement is classified bot-aware, so your cohort comparison isn't being distorted by scanner opens.

You bring your own mailboxes and leads — nothing is proxied through shared IPs, so the test measures your infrastructure and not someone else's. The free plan covers 1,000 active leads, 3,000 emails a month, and up to 10 of your own SMTP mailboxes, which is enough to run a four-mailbox ramp test end to end. Paid plans start at $29/mo.

{"faq":[{"q":"How long does a ramp test take?","a":"Three weeks of sending, plus however long your domains have been registered beforehand. Placement checks on day 5, 12, and 21 give you three readings; the day-21 reading is the one you act on."},{"q":"Can I test fast and slow ramps on the same domain?","a":"No. Reputation is evaluated at the domain level, so the two cohorts would contaminate each other. Use two sibling domains registered and configured on the same day."},{"q":"Is a slow warmup still necessary for every new mailbox?","a":"Not for every mailbox, but it is the correct default until you've proven otherwise on your own setup. The cost of being wrong on an aggressive ramp is roughly five times the cost of being wrong on a conservative one."},{"q":"What result means I should abort the fast cohort early?","a":"Sustained 4.7.x deferrals from Microsoft, a Postmaster spam rate above 0.1%, or primary-inbox placement dropping more than 20 points below the control. Any of those, stop that cohort and don't wait for day 21."}]}