How Many Inboxes and Domains Do You Need for Cold Email?
When we plan cold email infrastructure, the monthly prospect target is only the starting point. A sequence sends more than one message, the team does not send every calendar day, inboxes need operating headroom, and new infrastructure may require a ramp period before it reaches the planned campaign volume. If we ignore any of those variables, we buy too little capacity or create an unnecessarily large setup.
This guide turns one business target—unique prospects per month—into a transparent inbox, domain and ramp plan. We will not offer a universal “safe sends per inbox” number. We will expose every assumption, calculate scenarios with the same formula, and connect the result to authentication, list quality and campaign readiness.
Start with prospects, not sends
A prospect is a unique contact entering a sequence. A send is one attempted campaign message. If 2,000 prospects enter a three-step sequence and every step is scheduled, the gross plan contains:
2,000 prospects × 3 steps = 6,000 monthly campaign sends
Real activity may be lower because replies, bounces, opt-outs or stop rules remove contacts from later steps. For infrastructure planning, using the full scheduled sequence creates a visible conservative assumption. We can later model an observed continuation rate, but we should not hide it inside the calculator.
This distinction prevents a common error: dividing 2,000 prospects by an inbox cap when the actual scheduled workload is 6,000 messages.
The capacity formula
We use seven inputs:
- monthly unique prospects;
- sequence step count;
- sending days per month;
- campaign-send cap per inbox per day;
- reserve capacity percentage;
- inboxes per domain;
- ramp weeks.
The core calculation is:
Total monthly sends = Monthly prospects × Sequence steps
Base daily demand = Total monthly sends / Sending days
Base inboxes = ceiling(Base daily demand / Daily cap)
Reserve inboxes = ceiling(Base inboxes × Reserve %)
Required active inboxes = Base inboxes + Reserve inboxes
Required domains = ceiling(Required active inboxes / Inboxes per domain)
We round inboxes and domains upward because a partial inbox cannot carry the remainder.
Why the daily cap remains an assumption
Mailbox performance depends on more than campaign count: sender history, authentication, recipient engagement, content, complaints, invalid recipients, provider policy and broader traffic all matter. A number that works for one setup is not a delivery guarantee for another.
We therefore let the operator enter a campaign-send cap and show its effect. We treat unusually concentrated settings as warnings, not scientific thresholds. The team can recalculate with 15, 25 or 35 campaign sends per day and see the infrastructure trade-off.
The cap should also reserve space for normal replies and other legitimate mailbox activity where applicable. Our calculator models campaign sends; it does not pretend to model every provider-side reputation signal.
Reserve capacity is an operating control
If the base formula says eight inboxes and the system has exactly eight, one paused inbox immediately creates a shortfall. Reserve capacity provides room for maintenance, investigation and uneven distribution.
With 20% reserve:
Base inboxes = 8
Reserve inboxes = ceiling(8 × 0.20) = 2
Active plan = 10 inboxes
Reserve is not permission to run every inbox at a higher cap. It is planned headroom. We show it separately so that operations can distinguish required base capacity from resilience capacity.
Inboxes per domain is a concentration assumption
The domain calculation is mechanical:
Required domains = ceiling(Active inboxes / Inboxes per domain)
If the plan uses ten active inboxes and three inboxes per domain:
ceiling(10 / 3) = 4 domains
The tool does not state that three inboxes per domain is universally correct. It is a user-controlled operating assumption. More concentration reduces domain count but increases the effect of a domain-level issue. Less concentration increases administrative overhead. The final decision should reflect provider terms, brand policy, compliance, reputation monitoring and the team's ability to operate the infrastructure.
Ramp time and steady-state capacity are different
Capacity answers “how many sends could the planned setup distribute under our assumptions?” Ramp answers “when do we intend to reach that operating level?”
For a three-week ramp, a simple visible schedule might be:
| Week | Planned share of campaign cap | |---:|---:| | 1 | 25% | | 2 | 50% | | 3 | 75% | | 4 onward | 100% |
This is an editable operations model, not a promise that a provider will approve the traffic or that inbox placement will be good. We monitor authentication, bounces, complaints, replies and provider feedback during the ramp. If quality signals deteriorate, the correct response is investigation and reduced activity, not automatic progression.
The planner's “full-capacity date” is therefore a plan date: start date plus ramp duration. We label it clearly.
Three scenarios using the same math
The following examples use:
- 3 sequence steps;
- 20 sending days;
- 25 campaign sends per inbox per day;
- 20% reserve;
- 3 inboxes per domain.
Scenario A: 500 prospects per month
Monthly sends = 500 × 3 = 1,500
Daily demand = 1,500 / 20 = 75
Base inboxes = 75 / 25 = 3
Reserve = ceiling(3 × 20%) = 1
Active inboxes = 4
Domains = ceiling(4 / 3) = 2
The plan needs three base inboxes and one reserve inbox under these assumptions. Two domains result from the selected concentration rule.
Scenario B: 2,000 prospects per month
Monthly sends = 2,000 × 3 = 6,000
Daily demand = 6,000 / 20 = 300
Base inboxes = 300 / 25 = 12
Reserve = ceiling(12 × 20%) = 3
Active inboxes = 15
Domains = ceiling(15 / 3) = 5
This shows why a prospect target cannot be treated as the send target. The sequence multiplier creates 6,000 scheduled campaign messages.
Scenario C: 5,000 prospects per month
Monthly sends = 5,000 × 3 = 15,000
Daily demand = 15,000 / 20 = 750
Base inboxes = 750 / 25 = 30
Reserve = ceiling(30 × 20%) = 6
Active inboxes = 36
Domains = ceiling(36 / 3) = 12
At this scale, operational complexity becomes part of the decision. We need ownership, monitoring, reply handling, suppression, replacement procedures and reporting—not only mailbox accounts.
Calculate a plan with the free tool
The Cold Email Volume Planner applies the same formula to our own inputs. It returns monthly sends, daily demand, base and reserve inboxes, domain count and a ramp schedule.
We should run at least three versions:
- conservative daily-cap assumption;
- expected operating assumption;
- stress scenario with one or more inboxes unavailable.
Comparing scenarios is more useful than treating one output as truth. If a small change in daily cap doubles domain cost, leadership can see the trade-off before implementation.
Authentication and sender requirements
Capacity planning cannot replace sender configuration. Before launch, we verify:
- SPF alignment and authorized sending sources;
- DKIM signing;
- DMARC policy and reporting;
- TLS availability;
- accurate sender identity;
- functional opt-out;
- bounce and complaint monitoring;
- suppression enforcement;
- provider-specific requirements applicable to the sending pattern.
Requirements change. Engineering and operations should link the live tool and production checklist to Google's current Email sender guidelines and Microsoft's current high-volume sender requirements rather than freezing volatile numeric claims in evergreen copy.
If we have not run live DNS checks, the plan must label authentication answers “self-reported.” We can use the email deliverability test for a dedicated check and the SPF, DKIM and DMARC guide for implementation context.
Authentication does not create relevance. A correctly authenticated campaign sent to poor, stale or unrelated data can still create negative outcomes. The list cleaning workflow and bulk verifier belong before launch.
Connect capacity to segmentation
One large monthly total can hide uneven workload. Suppose 2,000 prospects are split into:
- 500 enterprise accounts requiring deeper research;
- 900 mid-market contacts;
- 600 smaller accounts.
If each group has a different sequence length, calculate its sends separately:
Segment sends = Segment prospects × Segment steps
Total sends = sum of all segment sends
Do not average sequence length unless the weighted math is visible. The B2B segmentation guide shows how one list becomes campaign groups with one pain, proof and CTA. Capacity planning then uses the actual group sizes and steps.
Build an operating calendar
A useful capacity plan includes dates and owners:
- authentication setup complete;
- inbox access and recovery ownership recorded;
- ramp start;
- first monitoring review;
- list freeze;
- verification completed;
- test sends;
- pilot launch;
- pilot review;
- planned full-capacity date.
We also define stop conditions. Authentication failure, abnormal bounce behavior, missing suppression, broken unsubscribe flow or unexplained provider warnings pause progression. The calendar is not an obligation to increase volume regardless of evidence.
Common planning mistakes
Dividing prospects by inbox cap
This ignores follow-ups. Use prospects multiplied by scheduled sequence steps.
Counting calendar days as sending days
The team may operate only on selected business days. Use the actual campaign schedule.
Treating reserve as extra volume
Reserve protects the plan from disruption. It should remain visible and uncommitted in the base calculation.
Hiding concentration
An inbox count without an inboxes-per-domain assumption does not produce a reproducible domain plan.
Calling a cap “safe”
No single campaign-send number guarantees inbox placement. State the assumption and monitor the result.
Launching at the planned steady state
New or changed infrastructure may need a controlled ramp. Full-capacity date is not the same as account-creation date.
Ignoring reply operations
A larger setup creates more reply routing, ownership, suppression and monitoring work. Capacity includes people and process.
Capacity QA checklist
- [ ] Monthly unique prospects are separated from total sends.
- [ ] Sequence step count reflects the scheduled campaign.
- [ ] Sending days match the operating calendar.
- [ ] Daily cap is labeled an assumption.
- [ ] Base and reserve inboxes are shown separately.
- [ ] Inboxes-per-domain concentration is visible.
- [ ] Ramp and steady-state dates are separate.
- [ ] SPF, DKIM and DMARC are checked.
- [ ] Sender identity and opt-out are ready.
- [ ] List hygiene and verification are complete.
- [ ] Segment-specific sequence lengths are included.
- [ ] Reply, bounce and complaint ownership exists.
- [ ] Stop conditions are documented.
- [ ] A pilot precedes full volume.
Model the effect of reply and stop rules without hiding assumptions
The gross planning model assumes every prospect is scheduled for every step. In production, a positive reply, opt-out, permanent bounce or manual stop should remove the contact from later steps. Once we have trustworthy campaign history, we can create a second observed-demand model.
Suppose a three-step sequence has 2,000 new prospects. If 100% receive step one, 75% remain eligible for step two and 55% remain eligible for step three, observed demand would be:
Step 1 = 2,000 × 100% = 2,000 sends
Step 2 = 2,000 × 75% = 1,500 sends
Step 3 = 2,000 × 55% = 1,100 sends
Observed plan = 4,600 sends
Gross plan = 6,000 sends
We do not replace the gross model with these percentages until our own campaign data supports them. A continuation rate borrowed from another company is not an infrastructure fact. The planner can present the observed model as an optional scenario, with each rate visible and editable.
This gives leadership two useful boundaries:
- Gross scheduled demand: capacity if every step remains scheduled.
- Observed expected demand: capacity using our documented continuation behavior.
The gap is not “free volume.” It is uncertainty and potential reserve. A change in offer, segment or reply handling can change continuation rates.
Distribute load by segment and day
Monthly averages can hide peaks. A campaign that sends almost everything on Monday has a different operating shape from one distributed across five days. We create a daily allocation table before launch:
| Day | New prospects | Follow-ups | Planned sends | Available base capacity | Reserve used | |---|---:|---:|---:|---:|---:| | Monday | 120 | 80 | 200 | 225 | 0 | | Tuesday | 120 | 130 | 250 | 225 | 25 | | Wednesday | 100 | 140 | 240 | 225 | 15 | | Thursday | 80 | 130 | 210 | 225 | 0 | | Friday | 60 | 100 | 160 | 225 | 0 |
These numbers are illustrative. The table forces us to see follow-up collisions. If Tuesday repeatedly consumes reserve, we can stagger sequence entry, change allowed sending days or reduce the number of new prospects. We should not solve every peak by raising the per-inbox cap.
We also check time zones. “Twenty sending days” does not explain when recipients are eligible to receive a campaign step. A global audience may create several sending windows and different daily shapes. Capacity should follow the actual scheduler behavior.
Include people and process in the capacity plan
More inboxes create more operational work:
- access and recovery ownership;
- connection health;
- authentication and DNS inventory;
- reply classification;
- interested-reply routing;
- opt-out and suppression;
- bounce and complaint investigation;
- paused-inbox redistribution;
- provider notices;
- campaign reporting.
We assign a named owner to every domain and inbox group. We also define who can pause sending, who investigates and who approves reactivation. Without that operating model, reserve capacity can become uncontrolled extra volume and paused infrastructure can be reactivated without understanding the cause.
Reply capacity matters too. If the team can properly handle only 30 qualified conversations per week, the campaign plan should not optimize solely for maximum sends. The operational objective is a manageable flow of relevant conversations, not a large send counter.
Use sensitivity analysis before buying infrastructure
We compare the result under changed inputs:
| Question | Recalculate by changing | |---|---| | What if we use two steps instead of three? | Sequence steps | | What if we send on 18 days? | Sending days | | What if we keep more reserve? | Reserve percentage | | What if one domain group is paused? | Available inboxes or stress scenario | | What if enterprise receives a longer sequence? | Segment-level steps | | What if ramp lasts five weeks? | Ramp weeks |
The most important input is not always the one with the largest number. If daily cap changes from 25 to 30, inbox count may fall, but the risk posture also changes. If sequence steps fall from three to two, infrastructure demand falls and the message strategy changes. We document the business consequence beside the numerical result.
For budget planning, we keep unit costs outside the universal SEO formula unless current product pricing is sourced dynamically. The downloadable plan can include editable fields for domain, inbox, monitoring and operator cost. It should never hard-code a price that may become stale.
Weekly operating review
During ramp and steady state, we run a short review:
- Did all planned inboxes remain connected?
- Were SPF, DKIM and DMARC still aligned after any change?
- Did bounces or complaints require a pause?
- Were replies routed and handled on time?
- Did suppression update correctly?
- Which segments consumed more sends than forecast?
- Was reserve capacity used, and why?
- Are next week's new-prospect entries still appropriate?
We record decisions, not only metrics. “Domain group B paused because of authentication misalignment; 20% reserve absorbed the gap” is actionable. “Deliverability down” is not.
If a problem is isolated, we do not automatically shift the full workload to every remaining inbox. We recalculate available capacity and preserve the operating assumptions. The Campaign Readiness Checker can be rerun after a material infrastructure or campaign change.
Executive interpretation of the output
The calculator gives leadership a resource model:
- how much scheduled work the outreach target creates;
- which assumptions determine inbox and domain count;
- when the plan intends to reach steady state;
- how much capacity is held for resilience;
- which configuration and process gates still block launch.
It does not answer whether the target market is correct, whether the copy is relevant or whether recipients will respond. Those questions live in the connected hub: ICP definition, prospect list creation, segmentation and prospect prioritization.
This separation is deliberate. We can change capacity without changing the ICP, and we can improve targeting without buying another inbox. A strong operating decision identifies which layer actually constrains growth.
What to do after capacity planning
Infrastructure is only one layer. Continue through the hub:
- Clean the source with the B2B Lead List Cleaner.
- Build coherent groups with the lead segmentation guide.
- Test domain and sender setup with the deliverability tool.
- Run the Campaign Readiness Checker.
- Use the CSV launch guide for mapping, test send and controlled pilot.
Frequently asked questions
How many cold emails should one inbox send per day?
There is no universal number that guarantees delivery. Use a transparent operating assumption, account for all mailbox traffic, ramp changes and monitor provider and recipient signals.
How many inboxes should we place on one domain?
It is a concentration decision, not a universal constant. The planner exposes the assumption so we can compare cost, resilience and administrative load.
Do follow-ups count toward volume?
Yes. Scheduled follow-ups are sends and must be included in infrastructure demand.
Is reserve capacity mandatory?
The percentage is an operating choice. Without reserve, one unavailable inbox immediately reduces planned capacity.
Does the full-capacity date guarantee readiness?
No. It is the calculated end of the selected ramp. Actual progression depends on configuration and observed quality signals.
Does authentication guarantee inbox placement?
No. Authentication is necessary for identity and policy alignment but does not replace list quality, relevance, reputation or recipient response.