Every cold email team knows they're supposed to "warm up" a new domain before sending at volume. Almost none of them can tell you what that means in numbers. Cold email infrastructure that survives contact with spam filters isn't built on a vague waiting period — it's built on a scheduled ramp with a volume ceiling attached to every week.
Cold Email Infrastructure Doesn't Forgive a Rushed Ramp
New domains and mailboxes have no sending history. Mailbox providers read that absence as risk, not neutrality — a domain that suddenly starts pushing volume with no track record looks exactly like a spam operation standing up new infrastructure, because that's often exactly what it is. The fix isn't complicated in theory: start low, build a sending history, then scale. The failure mode is almost always the same — teams treat "warm up for a few weeks" as a soft suggestion, hit week two, get impatient, and push volume before the domain has earned any reputation at all.
lemlist published a clear set of rules for this on July 22, 2026, in a post by writer Ivona Mikulčić titled "How to set up your sending infrastructure for cold email (without burning your domain)." The core recommendations: send from separate or lookalike domains rather than your primary company domain, age new domains and mailboxes for at least 4 weeks before sending at full volume, cap volume around 40 emails per day per mailbox once ramped, split your sending infrastructure across more than one email service provider, follow a 4-phase ramp-up schedule, and keep roughly 10% of your total infrastructure in reserve rather than actively sending (lemlist's infrastructure guidance).
Those are the right rules. What's missing from most teams' execution is the schedule that turns them into something you can actually run week over week, with a number attached to each stage instead of a feeling. This connects directly to two things we've already argued: that sender score is an ongoing signal, not a setup checkbox, and that the shared vs. dedicated infrastructure decision you make at the start shapes how much ramp discipline you'll need later. A ramp schedule is where those ideas become an operating calendar.
The Four-Phase Ramp Schedule, With Numbers Attached
lemlist's guidance names a 4-phase ramp-up without publishing the exact daily numbers for each phase. Below is Something Inc.'s own operational framework for translating that 4-phase structure and the 4-week minimum aging window into a week-by-week volume ceiling — built from lemlist's published recommendations, not a separate external study. Treat these as starting ceilings to tune against your own bounce and complaint data, not fixed law.
| PHASE | WEEKS | VOLUME CEILING PER MAILBOX / DAY | WHAT CHANGES |
|---|---|---|---|
| Phase 1 — Foundation | Week 1-2 | 5-10 emails/day | Domain and mailbox exist only to build initial sending history. No cold outreach yet — internal or warmup-pool traffic only. |
| Phase 2 — Early Ramp | Week 3-4 | 10-20 emails/day | Still inside lemlist's 4-week minimum aging window. Volume increases gradually; real cold sends can begin cautiously in week 4 at the low end. |
| Phase 3 — Scaling | Week 5-6 | 20-35 emails/day | Past the 4-week aging threshold. Volume climbs toward the steady-state ceiling as bounce and complaint rates are monitored send over send. |
| Phase 4 — Steady State | Week 7+ | ~40 emails/day (cap) | Mailbox holds at lemlist's recommended ceiling of roughly 40 emails per day. No further ramping unless reputation signals justify it. |
Something Inc.'s ramp schedule: per-mailbox daily volume ceiling by phase (built from lemlist's published guidance)
Two details matter more than the raw numbers. First, the 4-week mark isn't a green light for full volume — it's the earliest point lemlist's guidance treats a domain as safe to begin scaling, not the point where you jump straight to 40 a day. Second, the ceiling doesn't move with success. A mailbox that's replying well at 40 a day doesn't get pushed to 60 because open rates look good — the cap holds because it's protecting sender reputation, not chasing a short-term reply spike. If you want the deeper case for why that discipline matters even after a domain is fully ramped, our research on point-in-time verification covers a related mistake: treating a one-time check as a permanent guarantee instead of a constraint you re-test on a schedule.
Why Splitting Across Two ESPs Isn't Optional
lemlist's guidance is specific here: don't concentrate all of your sending infrastructure on a single email service provider. Split mailboxes across more than one — some on Google Workspace, some on Microsoft 365, for instance — rather than running every domain and every mailbox through one provider's infrastructure.
The logic is straightforward once you see it. Every ESP runs its own reputation systems, its own spam filtering heuristics, and its own thresholds for what counts as suspicious sending behavior. If every mailbox you own sits inside one provider, a single reputation event — one flagged domain, one aggressive filter update, one provider-side policy change — can degrade deliverability across your entire sending capacity at once. Split across two providers and a problem on one side leaves the other side untouched. That's not redundancy for its own sake, it's the same logic behind not putting all your sending volume on one domain in the first place — the shared-vs-dedicated infrastructure decision above covers the same principle at the ownership level: concentration risk shows up whether you're talking about domains, mailboxes, or providers.
The 10% Reserve Isn't Waste, It's Risk Management
lemlist's guidance also recommends holding roughly 10% of your total sending infrastructure in reserve — mailboxes and domains that exist, are warmed, and are not actively sending cold outreach at any given moment. On a spreadsheet that looks like idle capacity. In practice it's the difference between losing a week of pipeline and losing nothing when a domain gets burned.
Domains and mailboxes get flagged. It happens to well-run programs, not just careless ones — a complaint threshold gets crossed, a filter update misreads a legitimate campaign, a domain's reputation dips for reasons outside your control. When that happens to infrastructure running at 100% utilization, the team's options are limited: pause outreach, or push through on a damaged domain and make the problem worse. A team holding 10% in reserve swaps the burned domain out, keeps sending, and starts re-warming the damaged one on its own timeline instead of under pressure. This is the same instinct behind auditing your warmup pool rather than trusting its reported placement numbers at face value — infrastructure health needs a buffer built in, not a best-case assumption.
Run the Ramp as a Workflow, Not a Reminder
None of this holds if it lives in someone's memory instead of a system. The plays below map lemlist's 4-phase structure onto concrete actions your team can run without a manual tracking spreadsheet.
The teams that get burned aren't usually the ones ignoring domain warming entirely — they're the ones who know the concept and skip the schedule. A 4-week aging window, a roughly 40-email ceiling, infrastructure split across two ESPs, and a 10% reserve are four specific numbers, not four vague principles. Treat cold email infrastructure the same way you'd treat any other production system: with a rollout plan, a ceiling, and a rollback path. One financing marketplace client applied this level of infrastructure discipline to their outbound program and saw cold email reply rates increase 9.4% — see the FMS Investor case study for the full breakdown.
Do this next: audit every domain and mailbox currently in your sending stack against the phase table above — flag anything sending above its earned ceiling. Confirm your mailboxes actually split across two ESPs instead of one. Stand up a 10% reserve this week if you don't have one. If your team doesn't have the bandwidth to run this ramp and monitor it send over send, Something Inc.'s cold email service builds and manages the infrastructure schedule directly, including the reserve capacity most teams skip. And if your existing domains are already sending at volume with a shaky history, start with what Gmail's tightened spam-complaint threshold means for how much margin for error you actually have left.
See where you are cited today
A free snapshot audit of your rankings and AI citations before we ever talk.
Josh leads work at the intersection of SEO and generative engines at Something Inc., helping B2B brands get ranked and cited across every major AI engine.