You need roughly one warmed inbox for every 30 to 50 cold emails you want to send per day. Divide your daily send target by 35, add a 20 percent buffer for mailboxes sitting in warmup or recovery, then spread the result across domains at a maximum of three mailboxes per domain. A 10,000 sends per month program needs about 16 inboxes across 6 domains.
Most teams ask this question backwards. They pick a sequencer, buy a list, then discover halfway through the first campaign that two mailboxes physically cannot carry the volume the pipeline model assumed. Mailbox capacity is not really a deliverability topic, it is a capacity planning topic, and it is the number that decides whether an outbound program can hit its target at all. We build this layer for clients as owned infrastructure rather than a rented campaign, and the sizing math below is what we run before a single domain gets bought. If the authentication and DNS side is not locked down yet, start with the cold email domain setup checklist, then come back and size the fleet.
The Formula: Target Volume Divided By Per Inbox Capacity
The calculation has three inputs and one output. Input one is your monthly send target, meaning total emails leaving the system including follow up steps, not unique prospects. Input two is working days per month, which is 21 or 22 for a program that sends Monday through Friday. Input three is safe sends per inbox per day, which for a fully warmed and aged mailbox sits between 30 and 50. We plan at 35.
Inboxes = (monthly sends / 22 working days) / 35 sends per inbox per day, multiplied by 1.2
The 1.2 multiplier is not padding, it is a replacement reserve. In any running program some share of the fleet is unavailable at any moment: new mailboxes still in warmup, mailboxes pulled from rotation after a bounce spike, mailboxes retired because their domain picked up a filtering problem. Twenty percent is the number that keeps daily throughput flat instead of sawtoothing every time you rotate stock.
Then convert inboxes to domains. Divide the inbox count by three and round up. That is your domain count. Domains are the cheapest line item in this equation and the one teams under buy most often, which is why the domain column below looks higher than people expect.
Two clarifications on that table. The cost column shows a range because the low end assumes a dedicated cold email infrastructure provider at roughly $3.50 per mailbox per month and the high end assumes real Google Workspace or Microsoft 365 seats at about $7. The prospect column assumes a three step sequence, so total sends divided by three gives you the number of humans you actually reached. That distinction matters more than any other number on the page, and it is the one most teams get wrong when they set a volume target.
Why 30 To 50 Is The Real Ceiling, Not 2,000
Google documents a hard limit of 2,000 messages per day per Workspace user, 3,000 external recipients per day, and a maximum of 500 external recipients on any single message. Those are abuse thresholds. They tell you when Google suspends the account for 24 hours. They tell you nothing about the point at which Gmail starts routing your mail to spam, which happens far earlier.
The enforcement layer sits well below the documented limits. Google's bulk sender guidelines require SPF, DKIM, and DMARC alignment, RFC 8058 one click unsubscribe, and a user reported spam rate that stays under 0.30 percent, with 0.10 percent as the working target, for any domain sending 5,000 or more messages a day to Gmail. Microsoft matched it. Since 5 May 2025, domains sending more than 5,000 messages a day to Outlook.com, Hotmail.com, and Live.com must pass SPF, DKIM, and DMARC or get rejected outright at the SMTP layer with a 5.7.515 access denied error. Neither policy targets cold email specifically, but both define the environment you are sending into.
The practical read is simple. A mailbox that sends 40 emails a day, receives replies, and has a human behind it looks like a working business mailbox. A mailbox that sends 400 near identical emails a day looks like a list blast, and the filters deciding your fate were trained on exactly that pattern. You do not get more volume by pushing one mailbox harder. You get more volume by running more mailboxes that each behave normally. The full picture of what governs inbox placement is in our B2B email deliverability guide, but for sizing purposes 30 to 50 is the planning constant.
Inboxes Per Domain: Three Is The Hard Ceiling
Reputation is scored at the domain level far more than the mailbox level, so the domain is your unit of risk. Two to three mailboxes per domain is the settled ratio, and three is the ceiling. A domain carrying eight mailboxes all sending cold at once is a pattern receiving servers see constantly from spam operations and almost never from real businesses.
The real argument is blast radius. When a domain gets flagged, everything on it goes down together. At three inboxes per domain you lose three units of daily capacity, roughly 105 sends a day, and the rest of the fleet keeps running. At ten inboxes per domain you lose a third of a mid sized program in one afternoon and you have no rotation left to absorb it. Extra domains cost $10 to $15 a year each. Concentration risk costs you a quarter.
Two structural rules go with the ratio. Never send cold from your primary corporate domain, because a filtering problem there takes down billing, support, and every transactional email your company sends. And buy secondary domains a human would plausibly believe belong to you, close variants of your brand rather than random keyword strings, because recipients read the sending domain before they read the subject line.
What A Mailbox Actually Costs
There are two ways to buy sending capacity and they price very differently. Real provider seats are the conservative option: Google Workspace Business Starter runs $8.40 per user per month on flexible billing or $7 on an annual commitment, and Microsoft 365 Business Basic moved from $6 to $7 per user per month on 1 July 2026. Dedicated cold email infrastructure providers sell purpose built mailboxes in the $2.50 to $4 per mailbox per month range, usually with DNS automation and warmup bundled in.
The line item people forget is warmup. Standalone warmup tools run $15 to $29 per inbox per month, which at a 32 inbox fleet is $480 to $928 a month, several times the cost of the mailboxes themselves. That single number explains why bundled infrastructure providers have taken so much share from the buy Workspace seats and bolt on a warmup tool approach. If you are choosing between them, our breakdown of the best email warmup tools for deliverability covers what is worth paying for and what is now table stakes.
Budget the whole stack, not just the mailboxes. A 32 inbox program carries mailboxes, 11 domains at $10 to $15 a year, a sequencer with inbox rotation, a verification tool billed per contact, and inbox placement monitoring at $50 to $150 a month. The mailboxes are usually the smallest number on that list, which is precisely why buying too few of them to save money is such a poor trade.
You Cannot Buy Capacity On Day One
Mailbox capacity is not available at the moment of purchase. A new mailbox needs two to four weeks of warmup before it can carry light cold volume, and closer to six to eight weeks before it safely runs at 35 to 50 a day. A new domain generally wants two to three weeks of age before anything cold leaves it at all.
A workable ramp looks like this. Week one, 5 to 10 sends a day. Week two, 15 to 25. Week three, 30 to 50. From week four the mailbox holds its target and warmup keeps running underneath at a maintenance level rather than being switched off. That last part is not optional. Warmup is engagement supply, and cutting it the moment real campaigns start is one of the most common reasons a fleet that worked in month one collapses in month two.
The planning consequence is that infrastructure carries a six to eight week lead time on pipeline. If Q4 needs 20,000 sends a month, you buy and start warming that fleet in the back half of Q3. Teams that build a rolling cohort, adding a small batch of new inboxes every month instead of one giant fleet at once, end up with a smoother capacity curve and a natural replacement pipeline for retired mailboxes.
When To Add Domains Versus When To Add Inboxes
Add inboxes when existing domains sit under the three mailbox ceiling, bounce rates are under 2 percent, and Postmaster Tools shows domain reputation at high or medium with spam complaints well under 0.10 percent. This is the cheap and fast move, because nothing new has to age.
Add domains when every existing domain is already at three mailboxes, when you are raising target volume by more than about 40 percent, or when you want to isolate a new segment or offer so its performance cannot contaminate the rest of the fleet. Domains are the expensive move in time rather than money, because of the aging requirement.
Add neither when reply rates are falling while deliverability metrics stay clean. That is a targeting or messaging problem, and adding capacity to it just burns your addressable market faster at the same conversion rate. Sizing infrastructure to fix a relevance problem is the most expensive mistake in outbound, because you pay for it twice, once in tooling and once in prospects you can never approach again. The authentication and compliance side of this is covered in our guide to the 2026 deliverability rules for SPF, DKIM, and DMARC.
Size To Pipeline, Not To Send Volume
Run the calculation backwards from the meetings target and the fleet usually gets smaller, not bigger. Average cold email reply rates sit near 3 to 4 percent in 2026, and only 10 to 30 percent of those replies are genuinely positive rather than out of office notes or polite declines. A program touching 3,300 prospects a month at a 3.5 percent reply rate produces roughly 115 replies, of which maybe 25 to 30 are worth a calendar invite. That is what 10,000 monthly sends buys at market average performance.
The leverage is not in the denominator. Doubling the fleet to 32 inboxes doubles the cost, doubles the operational surface, and doubles the rate at which you exhaust a finite addressable market. Doubling the positive reply rate by only contacting accounts showing a real buying signal produces the same pipeline from the same 16 inboxes. That is the architecture we build for clients, and it is why a signal triggered system can produce 40 or more qualified demos in about six weeks without an enormous mailbox fleet behind it. Signal selection beats raw volume, and it is cheaper. The mechanics of choosing and wiring those triggers are in our guide to B2B buying signals.
Size the fleet to the volume your ICP can absorb at a sane touch frequency, not to the largest number the budget allows, then spend the difference on data quality and trigger logic. For teams assembling the wider system around the mailboxes, the B2B outbound tool stack breakdown maps what sits on top of the sending layer.
Build This With DevCommX
DevCommX builds autonomous, signal based AI SDR systems that your team owns outright, including the mailbox fleet, the domain architecture, the enrichment logic, and the triggers that decide who gets contacted and when. Clients keep the infrastructure and the data when the engagement ends, which is the entire point. Because the system fires on real buying signals instead of a static list, setup to 40 or more qualified demos in roughly six weeks is a normal outcome rather than an exceptional one. Book a GTM strategy call to map this to your pipeline.
Further Reading
- Google: Email sender guidelines
- Google Workspace: Gmail sending limits
- RFC 8058: One click list unsubscribe in the List-Unsubscribe header
FAQ
How many inboxes do I need to send 1,000 cold emails per day?
About 35 warmed inboxes across 12 domains. The math is 1,000 daily sends divided by 35 safe sends per inbox, which gives 29 inboxes, multiplied by 1.2 to cover mailboxes in warmup or recovery, which gives 35. At a maximum of three mailboxes per domain, that fleet needs 12 domains behind it.
How many cold emails can one inbox safely send per day in 2026?
Thirty to fifty per day for a fully warmed, aged mailbox, and only 10 to 20 per day during the first few weeks. Google's documented ceiling of 2,000 messages per Workspace user per day is an abuse threshold, not deliverability guidance. Filters degrade your inbox placement long before you ever reach the provider limit.
How many inboxes should I put on one domain?
Two to three, with three as the hard ceiling. Reputation is scored largely at the domain level, so more mailboxes on one domain means a larger blast radius when that domain gets flagged. At three inboxes you lose roughly 105 sends a day and keep operating. At ten you lose a third of a mid sized program at once.
How much does cold email infrastructure cost per mailbox?
Dedicated cold email infrastructure providers charge roughly $2.50 to $4 per mailbox per month. Real Google Workspace or Microsoft 365 seats cost $7 to $8.40 per user per month. Add $10 to $15 per domain per year, plus $15 to $29 per inbox per month if you buy warmup as a separate tool rather than bundled.
Should I add more domains or more inboxes to scale?
Add inboxes when existing domains sit under the three mailbox ceiling and reputation metrics are clean, because nothing new has to age. Add domains when every domain is already at three mailboxes, when you are raising volume by more than 40 percent, or when you want to isolate a new segment from the rest of the fleet.
How long before new inboxes can send at full volume?
Two to four weeks of warmup before light cold sending, and six to eight weeks before a mailbox holds 35 to 50 a day safely. New domains want two to three weeks of age first. That means infrastructure carries a six to eight week lead time on pipeline, so you buy and warm the fleet a quarter ahead of the target.
Planning your next GTM move? Get a quick audit of your sales, outbound, and RevOps systems.
Book Your Free GTM Audit
Replace manual prospecting with intelligent automation.
Let your sales team focus on closing.























.webp)



























































.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)