How to scale cold email outreach (without wrecking deliverability)

Scaling cold email is a fleet-sizing problem with an arithmetic answer, not a matter of pushing existing mailboxes harder. The formula is short: a mailbox's usable daily volume is the smaller of its configured daily limit and its hourly limit times the number of open sending-window hours, less whatever warmup reserves — and your fleet size is your target divided by that. Everything else in scaling outbound is a consequence of that division and of the fact that a new mailbox cannot carry its share for about three weeks.

Scaling outbound is a fleet-sizing problem, and the arithmetic decides it

Start with one mailbox at steady state and work out what it can actually carry. Four numbers set it, and only one of them is the number most people adjust.

• The configured daily limit. The number people raise when they want more volume.
• The hourly limit. Autocloz defaults it to 10 per mailbox and does not rescale it when you raise the daily figure. Against an eight-hour window that is a ceiling of 80 a day no matter what the daily limit says.
• The warmup pool share. Warmup traffic on an opted-in mailbox is bounded at a fraction of the effective cap, defaulting to 0.3. That leaves campaigns at least 70% of the ceiling.
• The sending window. Monday to Friday, 09:00 to 17:00 by default. Five days out of seven cuts the calendar-week average by five sevenths.

Compose them. With the defaults above, the binding ceiling is 80, campaigns keep at least 56 of it on a working day, and the calendar-day average is 56 times five sevenths, or 40.

Now invert it. Fleet size is target divided by that per-mailbox figure:

• 1,000 campaign sends on a working day: 1,000 ÷ 56 = 17.9, so 18 mailboxes.
• 1,000 campaign sends averaged across a calendar day: 1,000 ÷ 40 = 25, so 25 mailboxes.

The gap between 18 and 25 is entirely the weekend, and it is the single most common reason a fleet that looked correctly sized on a spreadsheet underdelivers by a third. Decide which of the two numbers your target is stated in before you buy anything. If you want the compounding in the other direction — why a mailbox configured for 200 delivers far fewer — the throttle arithmetic behind a mailbox that underdelivers works the same numbers forwards.

Raising the daily limit alone changes none of this. Until the hourly limit and the window are widened too, the daily number is not the binding constraint and moving it does nothing at all.

What a 21-day ramp costs you, exactly

A new mailbox does not carry its configured volume. Autocloz ramps it on a smoothstep curve: the multiplier for a given day is t squared times (3 minus 2t), where t is the day number divided by the ramp length, defaulting to 21 days.

That curve has a property worth knowing before you plan a launch date. Integrate t squared times (3 minus 2t) from 0 to 1 and the area under it is exactly 0.5. In plain terms: across its ramp, a mailbox delivers about half of what the same mailbox at full capacity would deliver in the same period. Summing the 21 discrete daily multipliers gives 0.524, so the continuous result holds in practice.

The individual days follow from the same formula, and they are worth seeing rather than approximating. Day 1 is 0.007. Day 5 is 0.143. Day 7 is 0.259. Day 10 is 0.464 and day 11 is 0.536, so the curve crosses half between them. Day 16 is 0.857. Averaged across the first seven days a mailbox is at 11% of its configured capacity, and by the start of week three it is at about 80%.

There is a second ramp above it that most people never notice. Autocloz also applies a 14-day domain-level warmup on top of the per-mailbox one, and skips it entirely while the workspace's total daily volume is below 50 sends — a deliberate right-sizing, because a five-lead campaign from a fresh domain is not the pattern the domain gate exists to catch. Above that floor, both ramps compound.

Three planning consequences fall straight out:

1. Add mailboxes a full ramp length before you need them. Capacity ordered today arrives in three weeks.
2. Stagger the starts. A fleet that all begins on the same day has one uniform capacity curve and one uniform reputation history, which is both a planning problem and a pattern.
3. Model it before you commit. The email warmup planner runs this curve in the browser against your own fleet size, target and ramp length.

Crossing 5,000 messages a day changes your obligations, not just your volume

Two documented thresholds sit at almost the same number, and both are counted per sending domain rather than per mailbox — so a fleet of twenty mailboxes on one domain crosses them together.

Google. Since 1 February 2024, a sender transmitting close to 5,000 messages or more to personal Gmail accounts within 24 hours, counted across the same primary domain, is a bulk sender. Bulk senders must authenticate with SPF and DKIM, publish a DMARC record on the sending domain, align the visible From domain with either the SPF or DKIM domain, and offer one-click unsubscribe on marketing and subscribed mail. Google also asks that unsubscribe requests be processed within two days.

Microsoft. Announced 2 April 2025 and enforced from 5 May 2025, domains sending more than 5,000 messages a day to outlook.com, hotmail.com or live.com must pass SPF, DKIM and DMARC, with rejection rather than junk filing for those that do not.

One-click unsubscribe is where fleets fail this, because RFC 8058 is stricter than it looks. The specification requires the message to carry a valid DKIM signature covering at least the List-Unsubscribe and List-Unsubscribe-Post header fields, requires the List-Unsubscribe-Post field to contain exactly List-Unsubscribe=One-Click, and states that the sender must not return an HTTPS redirect from the unsubscribe endpoint. A fleet architecture that gives every sending domain its own unsubscribe host and redirects each to a central handler is precisely the forbidden pattern.

The United States CAN-SPAM Act adds obligations that scale with the fleet rather than being satisfied once: every commercial message needs a valid physical postal address, opt-outs must be honoured within 10 business days, and the Federal Trade Commission sets the maximum civil penalty at $53,088 per email in violation. Twenty domains means twenty footers that have to be right.

More mailboxes per domain, or more domains?

This is the real architectural decision, and the honest answer is that it is a tradeoff rather than a rule.

What another domain costs. A registration, an SPF record, a DKIM selector with a published key, a DMARC record, and somewhere for bounce notifications addressed to the Return-Path to land. Five things per domain that can be wrong, and a DKIM key that was generated but never published looks identical to one that was never generated. Twenty domains is a hundred DNS facts to keep true. Setting up a cold email domain properly is the per-domain checklist.

What another domain buys. Blast radius. Reputation is gathered per sending domain, so complaints accumulated by one domain damage the mail sent from that domain. A fleet spread across five domains loses a fifth of its capacity to a bad month rather than all of it. That is the entire argument, and it is a good one.

The mistake that cancels the benefit. Pointing every sending domain's tracking links at one shared host. The link domain is a visible identifier present in every message you send from every domain, so separating the From domains while sharing the click host leaves an obvious join between them. No mailbox provider documents how it weights that, and anyone who quotes you a figure is guessing — but the cost of giving each sending domain its own tracking host is one CNAME, and the cost of being wrong is the reason you bought the domains.

One more constraint is per-domain and worth counting deliberately. RFC 7208 section 4.6.4 caps SPF evaluation at ten DNS-lookup mechanisms, and exceeding it produces a permerror that most receivers treat as a failure. Each domain has its own budget of ten, which means a fleet is not more exposed than a single domain — but it also means one over-long record fails silently on its own domain while the other nineteen look fine.

The four things that break first as the fleet grows

Ranked by how often they are the real cause, rather than by how dramatic they sound.

1. Suppression scoped to a campaign instead of the workspace. With one campaign, per-campaign suppression is indistinguishable from correct. With eleven, someone who opted out of campaign three receives campaign seven. Autocloz keeps suppression at workspace scope with a separate global layer, and the shared store is the single most important thing to get right before a fleet exists rather than after.
2. Reply handling. Covered below; it is a capacity problem, not a tooling one.
3. A DNS record that broke after it was published. Nobody re-checks a domain that worked. A vendor rotates its IP ranges — the include: for a relay such as Amazon SES resolves to whatever that vendor publishes today, not what it published when you copied it — or a DKIM key is rotated on the platform but not in DNS. Monitoring published records continuously is the only version of this that works at twenty domains.
4. Bounce damage arriving before anyone reads a report. One unverified import contaminates every mailbox that touches it simultaneously. The controls that stop a bad list at the fleet level have to be automatic, because a human checking a dashboard once a day is slower than the damage.

What a sender pool has to do when one mailbox is refused

A fleet is only a fleet if a refusal on one mailbox becomes a send on another. The naive implementation — pick one alternative, try it, defer if it is also blocked — fails in the exact case a fleet exists for. A workspace with 99 mailboxes on an early ramp day has 99 candidates, and stopping after the first rejected one defers every enrollment while 97 mailboxes sit idle.

Two behaviours are what separate a pool from a list of mailboxes:

• Selection weighted by health, not by order. Autocloz's email channel samples from the highest-scoring candidates with probability proportional to their health score, rather than hammering the single best one and queueing behind its rate limiter.
• Failover that tries every candidate. When the pinned mailbox is refused, every other mailbox in the campaign's pool is atomically probed in turn, and the enrollment defers only when all of them are genuinely exhausted. Any pool that gives up after one alternative will underdeliver in exactly the conditions that matter.

Autocloz's free plan covers 5 users and 10 mailboxes with the ramp, the pool failover and SPF, DKIM and DMARC monitoring on each connected domain — start free and size the fleet against the arithmetic above before you register a second domain.

Scale the reply capacity or do not scale the sends

The arithmetic here is trivially simple and almost universally skipped. At 1,000 sends a day, every percentage point of reply rate is 10 replies a day. Two points is 20; five points is 50. Substitute your own measured rate — there is no published industry benchmark and this post will not invent one — but do the multiplication before you increase the numerator.

Now cost it honestly. A reply that needs reading, qualifying and a considered answer takes minutes, and the replies arrive as an unpredictable stream through the working day rather than in a batch. A programme that quadruples sends without adding the person-hours to answer them converts its best outcome into its worst: a prospect who answered and was ignored is more damaging than one who never replied.

The same is true of the negatives. Opt-out requests carry a 10-business-day legal clock under CAN-SPAM, and out-of-office replies, role-mailbox auto-responders and delivery notifications all land in the same place and all have to be separated from real answers before anybody counts anything.

What scaling cannot fix, and what Autocloz does not do

More capacity multiplies whatever you already have, in both directions.

Scaling cannot fix targeting. If the contacts already in the list are marginal, the ones you add to fill a bigger fleet will be worse, because you exhaust the best-matching contacts first. A larger fleet mailing a weaker list produces more complaints, and complaint rate is the signal every provider agrees on.

Scaling cannot fix a message nobody wants. Volume changes the denominator of your reply rate, not the numerator.

Scaling cannot outrun list contamination. A fleet distributes a bad import across every sending identity at once, which is strictly worse than concentrating it in one.

And Autocloz specifically: it does not sell contact data or bundle a lead database, so the list you scale is one you bring and can defend. It does not register domains or manage your DNS — it monitors what you publish and tells you when a record breaks, which is a different job. It does not operate its own sending IPs or offer a dedicated-IP tier, so sender reputation on the infrastructure layer belongs to whichever provider you connect. And no fleet size, ramp shape or pacing rule makes placement certain; what they remove are the failure modes that are documented, measurable and yours to control.