How many cold emails can you send per day safely?

Nobody publishes a safe number, and the widely quoted 30 to 50 per mailbox has no primary source behind it. What you can do instead is find which of five simultaneous ceilings is actually binding, because that is almost never the one you set, and then derive a working number from three quantities you can measure: how many replies you can answer, how many verified contacts you can supply, and how much room your complaint ratio has at your volume. The published provider caps are far higher than any of those and are rarely your constraint.

Nobody publishes a safe number, and they could not

Google, Yahoo and Microsoft all publish sender requirements. Read them and notice what is absent: none of them states a per-mailbox daily volume that is safe for cold outreach, and none of them could, because "safe" depends on who you are mailing and how they react rather than on a count.

What they publish instead is a ratio. Google's guidelines say to keep the spam rate reported in Postmaster Tools below 0.30%, and below 0.10% as a guideline. Yahoo publishes the same 0.3% figure. Those are the numbers with a source. A volume figure would have to assume a complaint rate to be meaningful, and no provider is going to publish an assumption about how annoying your mail is.

So where did 30 to 50 come from? It is a reasonable inference dressed as a rule. A person at a mid-sized company sends somewhere in that range of external messages on a working day, and staying inside that band means your sending pattern is not conspicuous. That is a defensible piece of reasoning and it is worth following. It is not a published threshold, nothing enforces it, and quoting it as though a provider said it is the kind of small dishonesty that makes the rest of a deliverability guide untrustworthy.

Five ceilings apply at once, and only the lowest one is real

Any given mailbox is bounded by all of these simultaneously. The one that binds is the smallest, and it changes as a mailbox ages.

The provider's account cap. Google Workspace allows 2,000 messages a day on a paid seat, with 3,000 unique recipients a day of which 2,000 may be external, and 500 for trial accounts. Exchange Online allows 10,000 recipients a day per mailbox with a message rate limit of 30 messages a minute, plus a tenant-wide external recipient limit that scales with licence count. Amazon SES starts sandboxed at 200 messages per 24 hours and one message per second, to verified addresses only. The full picture, including how each provider counts a different unit, is in sending limits by provider.

Your platform's per-mailbox daily limit. In Autocloz this defaults to 40. It is the number people change and the one least likely to be binding.

The warmup ramp. While warmup runs, the configured daily limit is replaced by a ramp value for the mailbox's current day. On a 21-day smoothstep curve at a 40-a-day configured limit, day eight allows 13.

The hourly limit multiplied by the sending window. A per-mailbox hourly limit defaults to 10 and is not rescaled when someone raises the daily number. Nine open hours in a window therefore produce a ceiling of 90 a day regardless of what the daily field says.

The minimum gap between sends. A default of 90 seconds allows at most 40 sends an hour, so it only binds if the hourly limit is raised above 40. It exists to stop a burst, not to cap a day.

Compute all five. Take the minimum. Then, and only then, decide whether the number you want to change is the one doing the work.

Per day is the wrong unit — per hour and per calendar week are the ones that bind

Take a concrete configuration. A mailbox past its ramp, configured for 120 a day, hourly limit left at the default 10, sending window 09:00 to 18:00 Monday to Friday, opted into the warmup pool.

Nine open hours at 10 an hour is a ceiling of 90. The daily limit of 120 never applies. The pool reservation of up to 30% of the daily figure — 36 — bounds warmup traffic rather than adding to it, so campaigns retain a floor of 84 on a working day and usually more, because the pool's own target is often lower than its share.

Now convert to the unit a plan is actually written in. Five sending days out of seven means 90 times five sevenths, or 64.3 sends per calendar day, and 450 a week. A team that budgeted 120 a day and planned around 840 a week will conclude something is broken. Nothing is broken; three ceilings that nobody looked at are doing exactly what they were configured to do.

The general rule this produces is worth more than the specific numbers. Quote capacity as a weekly figure derived from the window you actually send in, and always name the constraint that produced it. "90 a day, hourly-limited, 450 a calendar week" is a statement someone can check. "120 a day" is a field value.

The counting unit is recipients, not messages

Every provider counts a different unit, and every one of them counts recipients somewhere.

Google Workspace publishes messages per day and unique recipients per day as separate limits, and documents the distinction plainly: five messages sent to ten different addresses count as ten unique recipients, while five messages to a single address count as one.

Exchange Online's recipient rate limit is the maximum number of recipients a mailbox can send to in a 24-hour period, counting every address in the To, Cc and Bcc fields. A distribution group stored in the organisation's shared address book counts as one recipient; a personal distribution list has its members counted individually. The tenant-wide external recipient limit counts group members individually after full expansion, so a message to a 1,000-member external group counts as 1,000.

For cold outreach this is mostly academic, because a cold email with five people on the To line is a bad idea for reasons that have nothing to do with quotas. It stops being academic the moment somebody adds a colleague to Cc on every send, or builds a follow-up that copies an assistant. Those doubles come out of the same budget.

Low volume is not automatically safe, and here is the arithmetic

The instinct is that sending less is always safer. For bounce risk that is roughly true. For complaint rate it is the opposite, and the reason is that complaints are whole numbers while the threshold is a ratio.

Google's published ceiling is a spam rate below 0.30%, measured against your traffic to Gmail. Suppose a mailbox sends 40 cold emails a working day and half the list is on personal Gmail addresses. That is 20 Gmail-visible messages a day, roughly 600 in a calendar month. Three tenths of one percent of 600 is 1.8. Two complaints in a month puts that sender over the published line.

Compare a sender doing 2,000 Gmail-visible messages a day. Their monthly Gmail volume is around 60,000, and 0.30% of that is 180 complaints. They can absorb a bad campaign. The small sender cannot absorb two annoyed people.

This is not an argument for sending more. It is an argument against believing that low volume is a form of protection, and an argument for two specific habits: care about who is on the list at least as much as about the daily number, and read your complaint ratio over a month rather than a day, because at these volumes a single day is a coin flip.

The same quantisation applies to bounces, which is why Autocloz requires at least 100 sends inside the rolling 24-hour window before any bounce threshold can fire. Three bounces out of twelve is 25% and means nothing; the gate deliberately cannot trip on it.

Autocloz's free plan covers 5 users and 10 mailboxes with per-mailbox pacing, the warmup ramp and authentication monitoring included — start free if you want the ceilings enforced by the sender rather than remembered by a person.

Deriving your own daily number from three things you can measure

Skip the folklore and compute a number you can defend. Three quantities constrain a cold programme long before any provider does.

Reply capacity. At a 3% reply rate, 300 sends a day produces about nine replies. A reply that waits two days is worth a fraction of a reply answered in two hours, so the honest question is how many conversations one person can genuinely carry. Sending faster than you can answer converts interest into nothing, and it does it silently. If one person can hold thirty live threads, your sustainable send volume is whatever produces thirty threads, not whatever your mailboxes permit.

Verified supply. How many genuinely qualified, verified contacts enter your list each week? Sending faster than you can qualify is the mechanism by which list quality degrades — the shortfall gets filled with weaker fits, and weaker fits are where complaints come from. Your send rate should be bounded by your research rate, not the other way round.

Complaint headroom. Multiply your expected Gmail-visible monthly volume by 0.003. If the answer is under three, you are operating in a regime where individual human reactions dominate your published ratio, and the correct response is tighter targeting rather than a different daily cap.

Take the smallest of the three, divide by working days, and compare it against the minimum of the five ceilings above. The lower of those two numbers is your answer, and unlike 30-to-50 it comes with a derivation you can show someone.

What raising the daily limit actually does

Usually nothing, because it is usually not the binding ceiling. That is the first thing to check before spending an afternoon on it.

When it is binding, raising it moves the constraint to the next ceiling up rather than removing constraints altogether — most often to the hourly limit, which is where a raised daily number reveals itself as a change in shape rather than in volume. A mailbox permitted 200 a day with an hourly limit of 10 does not send 200; it sends 90 in a nine-hour window and stops, and the operator concludes the platform is broken.

The change that does raise real capacity is adding a mailbox, and it has a lag. A new mailbox on a 21-day ramp delivers about half the sends a plateaued one does over its first three weeks. Capacity added in response to a shortfall therefore arrives roughly three weeks after the shortfall. Plan fleet growth ahead of demand rather than against it — the arithmetic for how many mailboxes and domains a target volume needs is worked through in scaling outbound without wrecking deliverability, and the ramp's cost day by day is in the 21-day domain ramp.

One more thing raising a limit does not change: the shape of the send. Forty messages released across a nine-hour window with a randomised gap resembles a person working. The same forty fired in ninety seconds resembles a script, and the pattern is visible to the receiver regardless of what the copy says. Autocloz enforces a minimum gap between sends per mailbox alongside the hourly and daily ceilings, which is what stops a sequence releasing its whole day at 09:00 sharp — and the send-time calculator is the place to work out which window your audience is actually in before you set one.

Which ceiling binds at one, three and ten mailboxes

The binding constraint moves as a fleet grows, and knowing where it moves to next is the difference between planning and reacting. Take mailboxes configured at 40 a day, hourly limit 10, a nine-hour weekday window, all past their ramps.

One mailbox. Forty a day is under the 90 the hourly limit permits, so the daily limit binds. Weekly capacity is 200 sends. The real constraint at this size is almost never technical — it is that one mailbox produces about six replies a week at a 3% reply rate, which is not enough conversation to learn anything from.

Three mailboxes. 120 a day, 600 a week, spread across two sending domains. The daily limit still binds per mailbox. The constraint that arrives at this size is supply: 600 verified, well-fit contacts a week is a real research load, and the temptation to fill the gap with weaker fits is where complaint rate starts moving.

Ten mailboxes. 400 a day, 2,000 a week, across four or five domains. Per-mailbox limits still bind individually, but two new constraints appear that did not exist before. Reply capacity becomes the binding one — 2,000 sends a week at 3% is about 60 replies, which is more than one person can hold properly. And the domain-level aggregate becomes visible: two or three mailboxes per sending domain keeps a single bad list from poisoning the whole fleet at once.

Notice that at no point in that progression does a published provider cap come near binding. Google's 2,000 messages a day on a single paid seat is fifty times what one mailbox in this fleet sends.

Two mistakes that make a correct number wrong

Counting warmup separately from campaigns. If warmup traffic and campaign traffic have separate counters, a mailbox warming at 12 while campaigning at 40 is sending 52, and neither dashboard shows 52. The receiving provider does not maintain two counters. Autocloz draws warmup from a share of the same daily ceiling rather than adding it on top, precisely so the ramp cannot be defeated by the scheduler — but the general point holds whatever you send with: find out whether your two numbers add up before trusting either.

Reading the ramp counter as evidence. A warmup day counter that advances on the calendar says how long ago the mailbox was created, not how much clean history it has. A mailbox idle for a fortnight mid-ramp arrives at day twenty-one having sent almost nothing, with a ceiling that assumes it sent everything. Resume below the stated ceiling rather than at it.

Five signals that say send fewer, and what each one means

Each of these is a different problem wearing the same costume, and the response differs.

Bounces are elevated with a sample large enough to trust. A list problem. Stop, verify, resume below where you stopped rather than at it. Read the status codes before you delete anything: a 5.1.1 and a 5.7.x are the same percentage and opposite causes.

A placement test put probes in spam at one provider. A reputation or authentication problem at that provider specifically. Volume down, diagnosis first. Do not average providers into a single health score — Gmail and Outlook are separate systems with separate thresholds.

Reply rate has fallen below your own baseline while placement is unchanged. A targeting problem. More volume accelerates the damage, because negative engagement is a signal and an ignored sequence is a long string of it.

The domain is under thirty days old, or the mailbox is mid-ramp. Not a signal at all, just an earlier point on the curve. Follow the ramp; do not override it.

A rejection string appeared that you have not seen before. Read it before reacting. An authentication refusal is a DNS fix and volume is irrelevant to it; a rate refusal is a volume fix and DNS is irrelevant to it. Treating one as the other is how a recoverable week becomes a lost domain.

What a daily cap cannot protect you from, and what Autocloz does not do

A daily cap controls one variable. It is a good control, and it is a narrow one.

It cannot make a message relevant, and complaint rate is a measurement of relevance rather than of volume. It cannot compensate for an unverified list, since every invalid address is a hard bounce whatever pace it arrives at. It cannot repair reputation that has already decayed, because it shapes future sends and has no mechanism to retract a complaint already filed. And it says nothing about placement: a mailbox sending a careful 30 a day into the spam folder is a mailbox wasting 30 sends a day.

Autocloz enforces per-mailbox daily and hourly ceilings, a minimum gap between sends, a sending window, and a warmup ramp that replaces the daily limit while it runs — and it names the binding constraint rather than making you infer it, using stable field names so "why did it only send 64?" has an answer rather than a theory. Per-mailbox sending and pacing is where those controls live.

What it does not do: it does not sell contact data or bundle a lead database, so the supply constraint above is genuinely yours. Its in-house verifier can never return a definitive deliverable verdict on its own, because the SMTP probe was removed in July 2026 — a clean address comes back as risky rather than confirmed, which is honest and is why "delete everything not marked deliverable" would empty a good list. Its placement seed tests classify a probe as inbox, spam or missing, and run when an operator triggers them rather than on a schedule. And no daily number, however carefully derived, settles where a message lands. If you are comparing a CRM that carries this pacing against a dedicated cold-email sender, the side-by-side with QuickMail covers where the two actually differ.