30 Mailboxes, 900 Emails a Day: What Smartlead Actually Sends (and What the Dashboard Won't Tell You)

Short answer: 30 mailboxes at 30 emails a day is 900 sends, not 900 new people. Take out the 5 or so each box spends on warmup, remember that every prospect costs 3 emails, and a fleet like the one behind the outbound engine I built for a Swedish client can reach about 250 genuinely new people a day. When I audited that engine, 11,556 leads were sitting in Smartlead queued and unsent, because our own database called a lead "contacted" the moment it was pushed to Smartlead, not when an email left. A per-mailbox wait setting was also capping every box at about 20 sends a day, and the nine Outlook accounts were sending nothing while repeatedly pausing the whole campaign. None of it showed up as an error.

The engine targets Swedish e-commerce brands. I built it end to end: Apollo for leads, one AI-written opening line per lead, Smartlead sending from 30 mailboxes across 19 campaigns, and AI reply classification routed to Slack. Where Smartlead's docs disagree with what I saw, I say so and link them. A field report that quietly contradicts the vendor isn't worth much.

How many new people can 30 Smartlead mailboxes really email in a day?

About 250. The 900 everyone quoted is a count of emails, and it got used as a count of people.

Sourcing was pulling leads as if 900 new people a day could be contacted. Two documented Smartlead behaviors make that impossible. Follow-ups go out before new leads ↗ and count against the same mailbox limit. And the per-campaign "max new leads per day" setting excludes follow-ups ↗, while one mailbox's daily limit is split across every campaign it's attached to.

Each prospect gets 3 emails: the first touch, then follow-ups about 4 and 10 days later. Warmup takes about 5 sends a day per box, so the practical cap we set was 25.

Headline figure
  30 mailboxes x 30 per day                    = 900 sends/day

Warmup takes about 5 per box, so cap at 25
  30 mailboxes x 25                            = 750 sends/day

Each prospect costs 3 sends
  day 0, then follow-ups at about day +4 and day +10

Steady state (every day's batch eventually gets all 3)
  750 sends/day / 3 sends per prospect         = 250 new people/day

If sourcing delivers the 900 it planned for,
the queue grows by 900 - 250                   = 650 leads/day

With the 9 Outlook boxes detached (below)
  21 mailboxes x 25 = 525 sends/day / 3        = 175 new people/day

That 250 is a steady-state simplification, and I'd rather label it than defend it. It ignores replies and bounces, which end a sequence early, so the true figure sits somewhat above 250, depending on your reply and bounce rates. It also hides a trap. For the first four days of a fresh fleet no follow-ups are due, so all 750 slots go to new people and the ceiling looks like 750. Then the day 4 follow-ups come due, then the day 10 ones, and once things settle two thirds of the capacity belongs to people you've already written to. Smartlead serves them first.

Why were 11,556 leads sitting in Smartlead unsent?

Because our database said "contacted" when it meant "pushed".

When the engine handed a lead to Smartlead through the API, it marked that lead contacted, and every number downstream believed it. Smartlead, meanwhile, put the lead in a queue behind follow-ups. At audit, 11,556 leads were in that state: flagged contacted on our side and still waiting in Smartlead's queue, with no email sent.

There was no error anywhere, because the bug was a definition.

A lead now counts as sent when Smartlead's own lead status says so, and not before. The no-reply follow-up logic reads Smartlead's status too, not our local flag, because a rule that asks "did they reply?" means nothing if the email it's asking about hasn't left yet.

If you run an agency and your client reports show a "contacted" number, find out which of those two things it counts.

Why does a Smartlead mailbox send less than its daily limit?

In our case, a per-mailbox wait setting that nobody was looking at.

minTimeToWaitInMins is the minimum number of minutes between two sends from the same mailbox. Ours was 23, inside a 480-minute sending window:

window 480 min, gap 23 min    480 / 23 = 20.9    about 20 sends per box
window 480 min, gap 10 min    480 / 10 = 48      the 25 cap decides again

At 23 minutes a box can't send more than about 20 a day, whatever its daily limit says. Ours said 25, and that field gives no hint the number is out of reach. Stack it with the nine idle Outlook boxes below and, on paper, 21 boxes at about 20 sends each is 420 sends a day, or 140 new people, against a sourcing plan of 900. That's arithmetic, not a measured day.

The setting that looks like the lever is the campaign-level interval. It isn't. I lowered the per-mailbox gap to 10 on 16 September 2026, which gives each box room for 48 sends in the window, so the 25 cap is the only thing deciding volume again.

One more thing, because it will tempt you to change settings that are fine: Smartlead sends in rounds. Check a campaign between rounds and it looks like sending has stopped. It hasn't. A quiet minute is not a stall, so look at sends per mailbox over a few hours before you touch anything.

Why do Outlook mailboxes keep pausing a Smartlead campaign?

I can't tell you the mechanism, and Smartlead's docs don't either. I can tell you the pattern.

The nine mailboxes that were sending nothing were exactly the nine Outlook accounts. The same nine kept making Smartlead auto-pause the entire campaign, which stopped every healthy box in it as well. Smartlead's list of pause reasons ↗ only mentions mailbox connection problems for a campaign with a single mailbox. The rest are bounce-rate protection, quota, billing and running out of leads. The disconnection article ↗ lists Microsoft 365 throttling as a cause of disconnects, but says nothing about Outlook boxes pausing a multi-mailbox campaign.

On 18 September 2026 I detached the nine. One API detail: the POST endpoint for a campaign's email accounts only adds accounts. It doesn't replace the list, so posting the 21 you want leaves the 9 you don't. Removing them takes the DELETE endpoint. There have been zero pauses since. That was three days before I wrote this, so treat it as early evidence. I also added a job that runs every five minutes and resumes the campaign if it finds it paused. If you build one, make sure it can't resume a campaign that paused for bounce-rate protection.

Whatever caused ours, Outlook boxes come with Microsoft rules to plan around:

• SMTP AUTH basic authentication is disabled by default for existing Exchange Online tenants at the end of December 2026 ↗, and tenants created after that won't have it. Cold email tools often connect Outlook boxes over SMTP with a password. I'm not saying that's what broke ours, but if yours connect that way you have about three months. One cold email infrastructure blog ↗ says Microsoft already switched it off in March 2026, while Microsoft's own page ↗, updated in July 2026, says it's still available. Read the primary source.
• TERRL, the tenant external recipient rate limit ↗, caps how many external recipients a whole Microsoft 365 tenant can email in a 24-hour sliding window. It depends on license count, and a trial tenant gets 5,000 a day. Every box on that tenant shares it.
• 550 5.7.515: since May 2025 Microsoft rejects rather than junks ↗ mail from domains sending more than 5,000 a day to outlook.com, hotmail.com and live.com that fail SPF, DKIM or DMARC, with that error code ↗. It's scoped to consumer mailboxes, and a fleet capped at 900 sends a day is far below 5,000, but aligned SPF, DKIM and DMARC are the minimum anyway.

Should you turn off open and click tracking in Smartlead?

For cold email, yes, and you have to do it on purpose, because it's on by default.

Smartlead's help center says opens and link clicks are tracked by default ↗. The part that caught us is in the API: an empty track_settings array means track everything ↗. We'd assumed empty meant off. It's a reasonable assumption, and it's wrong.

What I saw: the tracking pixel showed up as a broken image in Outlook. A cold email from a stranger with a broken image in it looks like exactly what it is. That's my observation from one fleet, not a study.

Hunter's State of Cold Email 2026 ↗ reports a 7.4% reply rate without tracking against 4.4% with it, and Snov.io's analysis of more than 44 million emails ↗ found 2.36% against 1.08%. Both are correlations. Senders who switch tracking off may just be more careful senders, so I wouldn't claim the pixel alone halves anyone's replies. Smartlead's own deliverability guide ↗ tells you to disable it for cold outreach, which is an odd thing to read next to a default that turns it on.

I turned tracking off on the live campaign and in the code that creates campaigns. The help center ↗ also says tracking can't be changed once a campaign starts sending, yet I changed it on a running one, so either that line is stale or it means something narrower. I haven't pinned down which. Set it at creation and you never need to know.

Does Smartlead stop the same lead going into two campaigns?

Its documentation says yes, by default. I saw a case where it didn't, and I'm not going to claim more than one case supports.

What I measured: a lead that already existed in campaign A was accepted into campaign B. Separately, the counters in the addLeads response didn't match what actually landed in the campaign. The only number that held up was reading the lead list back with GET /campaigns/{id}/leads.

What the docs say: the API reference ↗ describes ignore_duplicate_leads_in_other_campaign as allowing leads that already exist in other campaigns, with a default of false. So duplicates should be blocked unless you ask for them. Clay's Smartlead integration docs ↗ say the same.

The trap is the word "ignore". In Smartlead's app, the option "Ignore the leads that exist in another campaign" means skip them, and the help article on duplicates ↗ tells you to enable it. In the API, setting ignore_duplicate_leads_in_other_campaign to true means let them in. Same word, opposite behavior. Someone who set up the app first and wrote the integration second could easily send true thinking it matches the checkbox. I can't rule that out as the explanation for what I saw, and it's the first flag I'd check in yours.

On the counters, the outside evidence leans my way, weakly. A public repo's September 2026 run ↗ records Smartlead refusing 358 of 366 leads because they were already in other campaigns, so dedup worked for them, while the same response reported an upload_count of 387 and total_leads of 29. That's one project and a small sample. The response fields also appear to differ between Smartlead's older docs (upload_count, already_added_to_campaign, duplicate_count) and the current reference ↗ (added_count, skipped_count, skipped_leads), and Smartlead says lead counts can take 10 to 15 minutes to update ↗. Any one of those is reason enough to stop trusting a counter.

The conclusion I acted on doesn't depend on who was right about the flag. Uniqueness lives in the engine's own database, and I verify by reading back, never by trusting the response.

Why keep the source of truth outside the sending tool?

Because a sending tool tells you what it accepted, and you need to know what actually happened. On this project the gap between those two was 11,556 leads.

The engine's database now owns who can be emailed:

• a unique constraint on the normalized email address
• a domain blocklist
• a 15-day blocklist after contact
• a permanent suppression list of about 21,000 addresses that a previous system had already contacted

One silent failure ran the other way: the engine was too strict. When the email-verification provider's credit balance ran out, every check came back "unknown". The engine treated unknown as bad, so it stopped sending, silently, and blocklisted good domains on the way. By its own logic it was being careful. It just didn't tell anyone.

The fix: a first "unknown" now fails open, and an empty balance raises a visible alert on the engine's system page. An empty credit balance tells you about your account, not about the address. From the outside, a stop like that and the quiet gap between sending rounds look the same, which is why it needs an alert and not someone glancing at a dashboard. If your engine runs on Node.js, the tracing in my post on agent observability with OpenTelemetry ↗ is a sensible place to hang that alert.

Two more rules came out of this project. Never re-save the sequence on a live campaign: saving it re-fires step 1, so copy changes now go into a new campaign. And the AI-written opening line gets linted before it can send. That check exists because the model once wrote a line naming the prospect's own product as the competitor beating them. It read fluently. Testing what a model produces instead of trusting the prompt is the same discipline as evaluating agents in CI ↗, and if you build this for clients, settle who owns a line like that ↗ before one goes out.

What should you check on every new Smartlead setup?

This is the list I run through before a new setup sends anything.

1. The real ceiling. Mailboxes x (daily limit minus warmup) / emails per prospect, compared with what sourcing produces. The excess becomes a queue.
2. The per-mailbox gap. Window minutes / minTimeToWaitInMins must exceed the daily limit on every box. The campaign interval is not the fix.
3. What "sent" means. Smartlead's lead status, nothing else. The no-reply logic reads it too.
4. Tracking. Set track_settings explicitly at creation. Never an empty array.
5. Duplicates. Set ignore_duplicate_leads_in_other_campaign on purpose and log the value. Keep uniqueness in your own database and read the lead list back once the counts settle.
6. Microsoft boxes. How they connect (before December), the tenant's recipient limit, and whether each one sent anything this week.
7. Pauses. Something that notices within minutes, tells a person, and never resumes past bounce protection.
8. Complaints. Google's bulk sender rules ↗ kick in at about 5,000 messages a day to personal Gmail accounts: spam complaints below 0.1% and never reaching 0.3%, with enforcement, rejections included, ramping up since November 2025. Mail to Google Workspace accounts is exempt, which covers a lot of B2B, but I'd still aim under 0.1% and treat 0.3% as the hard stop.
9. Live sequences. Never re-save one. New copy, new campaign.
10. Silent failures. An alert when a box sends nothing for a day or a paid dependency runs out of credit.

If your own fleet's volume, pauses or duplicates don't add up and you want someone to go through it with the API open, that's the work on my cold outreach automation ↗ page, and the contact page ↗ reaches me directly. I'd rather tell you your 30 boxes are fine and your sourcing number is wrong than sell you a rebuild.