Managing cold email at scale - the mailbox monitoring system I built with Claude Code

Sequencers report at the campaign level. That's the problem. You see the overall reply rate and the overall bounce rate, but you can't see which 12 of your 220 mailboxes are dragging the average down. You can't see that two of your fifteen domains are sitting at a 0.5% reply rate while the rest carry the campaign. You can't tell whether a 3.2% campaign bounce rate is one bad mailbox or three dying domains.

The data that actually matters at scale lives one level down - reply rate per mailbox, bounce rate per mailbox, reply and bounce per domain, performance per provider. None of it is surfaced. So either you don't know your real picture, or you know it but it takes hours (or a full-time person) to reconstruct it by hand every week.

That blind spot is expensive in a way that doesn't show up until something breaks. A burnt domain keeps sending. A blacklisted mailbox keeps eating your good leads. The campaign number looks fine on average, right up until your sender reputation has already cratered.

Picture a Monday morning - or, if you're a founder, a Sunday afternoon. You sit down to your campaigns and see solid overall numbers. What you can't see is whether some mailboxes are replying at 8% while others sit at 0.5%. If bounces jumped this week without a list change, you don't know whether it's every mailbox or just one. If a domain is burnt, you don't know which.

Then there's the operational sprawl on top. Running an agency, you might spin up fifteen campaigns in an afternoon. Every new campaign means pasting webhook URLs into the sequencer by hand, and across fifteen-plus active campaigns that's exactly where things break silently. Warmup disconnects go unnoticed - a reconnected mailbox can sit with warmup off for two weeks before anyone catches it. And when a mailbox underperforms, you can't easily tell which provider it came from.

For a while I had someone on the team managing all of it. When that role ended, I had a choice - hire someone immediately, maybe not the right fit, or carry it myself for a while and hire better later. What I knew for certain was that I couldn't keep doing it by hand. It was eating too much time. There had to be a better way.

My first instinct was pure automation. I started orchestrating Make and n8n workflows, and it worked - I automated lead forwarding, Slack notifications, CRM updates. Real time saved.

But it didn't hold at scale. I ended up with a different set of workflows for each use case, then a different set again for each client. Some of them broke. It was cheaper and better than doing everything by hand, but I was still pouring time into maintaining the automations themselves. The thing meant to save time had become its own job.

Like a lot of people using Claude Code now, I'm not a developer. I've never written a line of code in my life. But I knew exactly what I needed and exactly how it was supposed to work, and it turns out that's the part that matters most.

So I sat down with a coffee and started describing the system - what data it had to pull from Instantly's API, what it should flag, how each view should look. About 25 hours of work later it was running. Five years ago an application like this would have cost twenty or thirty thousand to commission. The fact that a non-developer can now build precisely the internal tool they need is, honestly, the bigger story than the tool itself.

Three of the seven features are about visibility, and together they're the first place I look every morning. The first is a unified mailbox view - one dashboard showing all 220+ mailboxes across providers (ZapMail, manually added accounts, and the rest), with status, sending volume and a health score for each. No more flipping between sequencer tabs and provider dashboards. Five seconds to see the state of everything.

The second is per-mailbox health monitoring. Each mailbox gets a health score calculated automatically from its bounce rate and reply rate, with anything below threshold flagged red. Instead of staring at campaign-level averages and guessing, I can see exactly which mailboxes are the problem before they tank an entire campaign.

The third is the domain-level rollup with dead-domain detection. Bounce and reply rate are aggregated per domain across every mailbox on it, and domains showing systemic issues - high bounce, zero replies, blacklist hits - get flagged for retirement. Domains die in patterns, not in isolation, so spotting a dying domain a week earlier saves the whole rotation that depends on it. There's a one-click blacklist check across every domain too.

This is the part that replaced a junior hire, and it has two halves. The first is a smart ramp-up curve. New mailboxes follow a 12-day volume schedule - 3, 5, 5, 8, 10, 10, 13, 16, 20, 20, 23, 25 emails a day. Aggressive ramp burns inboxes; cautious ramp leaves money on the table. The point is what runs alongside the curve - if a hard bounce hits during ramp, the curve rolls back three days and pauses for 48 hours before resuming. Nobody has to babysit it.

The second half is auto-healing, and it runs on every mailbox, not just new ones. When a mailbox's bounce rate crosses 5%, the system automatically cuts its daily sending limit in half. When it recovers below 2%, the limit climbs back up gradually. No human intervention. This matters because bounces compound - by the time anyone notices manually, the domain is already on a blocklist. The system catches it within hours, not days.

Together that means an aged mailbox I've used for months that suddenly starts bouncing gets flagged, throttled, and recovered on its own. I don't watch it. I look at what's flagged and trust the system has done the job a junior employee would otherwise be doing by hand.

Two more features do less glamorous but genuinely time-consuming work. The first is tag-based webhook injection. Tag a campaign with a client keyword and the system auto-attaches the right set of webhooks for that client - replies, MQLs, bounces - with no manual configuration per campaign. When you have eight clients each needing different webhook routing, manual attachment is where mistakes hide. This makes it impossible to forget one.

The second is auto-reconnect and warmup monitoring. The system watches for mailboxes that drop offline - expired authentication, lapsed ZapMail subscriptions - and for mailboxes silently sitting with warmup turned off. A disconnected mailbox is one you're paying for that's earning zero. Catching it within a day instead of two weeks is real money.

These aren't seven independent tools - they form one feedback loop. Every new mailbox enters a managed lifecycle - warmup confirmed, ramp-up started, health monitored, throttled if bouncing, rolled up at the domain level, flagged if disconnected, retired if the domain dies. The dashboard is the cockpit. The automation is the autopilot.

Concretely, it turned a full-time operational role into a glance. Before, mailbox operations took roughly four hours a day of checking provider dashboards, comparing campaign metrics, and manually adjusting limits. After, it's about 30 minutes a day reviewing the dashboard and acting on flagged items. The visibility went from 'Campaign X has a 3.2% bounce rate' to '12 mailboxes on this domain are accounting for 80% of the bounces' - campaign average to root cause.

It also removed an entire class of silent errors - manual webhook attachment across fifteen-plus campaigns, forgotten warmup toggles after reconnects, and subjective ramp-up calls ('should I push this to 25 today?'). The system doesn't replace strategy. It replaces the operational toil that comes with running infrastructure at scale.

Let me be honest about the tiering, because this is not for everyone. If you're running campaigns across five or ten mailboxes, don't build anything like this. You can manage that by hand and it won't take much time. And if you're at several thousand mailboxes, you almost certainly already have systems in place.

It's the middle ground where this matters - a hundred to a few hundred mailboxes, serious volume, but not yet an in-house platform team. That's the band where the manual work is heavy enough to hurt but not yet big enough to have been solved. That's exactly where I was at 220.

The broader takeaway is the one I keep coming back to. The infrastructure work behind cold email at scale used to require either a full-time hire or a five-figure custom build. Now the person who actually understands the problem can build the tool themselves, in about 25 hours, owning it outright instead of subscribing to someone else's SaaS. That shift is worth more than any single feature in the system.