How LeadHaste Scales 100+ Client Campaigns on InboxKit Without Burning Domains

At LeadHaste we manage cold email infrastructure for over 100 active client campaigns at any given time. That means thousands of domains, thousands of inboxes, and millions of emails per month flowing through our system.

When your reputation depends on landing in the primary inbox across that many accounts, infrastructure isn't something you can afford to get wrong. One misconfigured domain can tank a campaign. One lazy shortcut on DNS can flag an entire batch. And at our scale, "manually setting up mailboxes" stopped being an option a long time ago.

This is the playbook we use to keep everything running. And InboxKit is the backbone that makes it possible.

Most agencies set up 5-20 domains per client and call it a day. We set up 50.

Here is how our standard client campaign breaks down:

• 50 dedicated domains per client
• 2 inboxes per domain (100 sending accounts total)
• 15 emails per inbox per weekday (7,500 emails per client per week)
• Monthly inbox rotation replacing the bottom 10% by reply rate

Why 50 domains and not 5? Volume distribution. When you spread 7,500 weekly emails across 100 inboxes, each inbox only sends 15 emails per weekday. That is a volume Google and Microsoft consider normal human behavior. When you try to push the same volume through 10 inboxes, you are sending 150 per day per inbox, and that is a fast track to the spam folder.

The 2-inboxes-per-domain rule is deliberate too. Three inboxes on one domain means if that domain gets flagged, you lose three sending accounts. Two keeps the risk contained while still maximizing each domain purchase.

Here is the part most teams skip: we don't just set and forget. Every month, we pull performance data across all 100 inboxes and identify the bottom 10% by reply rate. Those get retired and replaced with fresh domains and inboxes.

This means a client's infrastructure is constantly improving. The worst performers get swapped out. The best performers keep building sender reputation. Month over month, the average inbox quality goes up. It is a compounding effect applied to infrastructure.

Bad domain names get flagged before you send a single email. We have tested hundreds of naming patterns and here is what works:

Rules we follow:

• .com only. No .io, no .co, no .xyz. These TLDs carry higher spam association out of the gate.
• Brand variations only. If the client is Acme Corp, we buy domains like tryacme.com, getacme.com, acmehq.com, meetacme.com. Close enough to the brand that replies feel legitimate, different enough that the primary domain stays protected.
• No dashes. acme-outbound.com looks like a throwaway domain. acmeoutbound.com is better but still not great. Keep it clean.
• No spammy keywords. Avoid words like "leads," "sales," "deals," "growth," or "marketing" in the domain itself. Spam filters pattern-match on these.
• Short is better. 8-12 characters is the sweet spot. Anything longer looks artificial.

What we avoid:

• Domains with numbers (acme123.com)
• Exact match keyword domains (bestb2bleads.com)
• Domains that have been previously owned and carry bad history
• Anything that looks like it was bulk-purchased for cold email, because it probably was

InboxKit's domain health checks are useful here. Before we even start warm-up, we run every domain through their blacklist and reputation pre-screening. Occasionally a "clean" domain we purchased turns out to have residual reputation issues from a previous owner. Catching that before warm-up saves us weeks.

We warm up through Smartlead's built-in warm-up network, but the principles apply regardless of your tool. If you are not using a sequencer with warm-up built in, InboxKit's own warm-up works well as a standalone option.

Our warm-up protocol:

• Week 1: 5-8 emails per day per inbox, all warm-up (no live sends)
• Week 2: 10-15 emails per day, still all warm-up
• Week 3: Begin mixing in live campaign sends at low volume (5-10 per day) while maintaining warm-up
• Week 4+: Full sending volume (15 per weekday) with warm-up running in the background permanently

The key insight most people miss: warm-up never stops. Even inboxes that have been sending for six months keep warm-up running in the background. It maintains the engagement signals that keep sender reputation healthy.

Rotation across 50 domains:

We don't warm up all 50 domains simultaneously. We stagger in batches of 10-15, bringing new batches online every week. This means:

• Week 1: Domains 1-15 start warm-up
• Week 2: Domains 16-30 start warm-up, domains 1-15 move to week 2
• Week 3: Domains 31-45 start warm-up, domains 1-15 start live sends
• Week 4: Domains 46-50 start warm-up, domains 16-30 start live sends

By week 5-6, the full infrastructure is live. This staggered approach also means we always have domains at different stages of maturity, which naturally diversifies our sending profile.

Here is our controversial take: we never try to recover domains.

The math does not support it. Diagnosing why a domain's reputation dropped takes time. Testing recovery strategies takes more time. And at the end of it, you might recover it, or you might not. Meanwhile, a fresh domain from InboxKit is set up with clean DNS in minutes and can start warm-up immediately.

Our retirement triggers:

• Bounce rate spikes above 5% on a domain that was previously healthy
• Inbox placement drops below 80% when tested
• Smartlead inbox health score drops below 95%
• Human reply rate drops below 0.5%
• The domain appears on any major blacklist (Spamhaus, Barracuda, etc.)

When any of these triggers hit, the domain gets retired immediately. No second chances, no recovery attempts. We order a replacement through InboxKit and start warm-up the same day.

This sounds expensive until you calculate the alternative. A "recovering" domain that is actually still hurting deliverability can silently damage an entire campaign for weeks. The opportunity cost of lost replies far exceeds the cost of a new domain.

The bottom 10% monthly rotation we mentioned earlier catches most problems before they become serious. By the time a domain hits a hard retirement trigger, we have already identified it as a weak performer.

We have tried several infrastructure providers. Here is why InboxKit became our default:

Setup speed at scale

When you are onboarding a new client and need 50 domains configured with proper DKIM, DMARC, and SPF records, speed matters. InboxKit's auto DNS configuration handles all of this automatically. No manual TXT record copying, no waiting for propagation confirmations, no human error on a critical security record.

For a single client setup, this saves a few hours. Across 100+ clients with regular domain rotation, it saves hundreds of hours per year.

Domain isolation that prevents cascade failures

This is the feature that sold us. Every domain on InboxKit sits in its own isolated panel. If one domain gets flagged or blacklisted, it has zero impact on the other 49 domains in that client's portfolio, or any other client's domains.

With other providers we tested, a reputation issue on one domain could bleed into others sharing the same infrastructure. At our scale, that kind of cascade failure is catastrophic.

API flexibility for custom monitoring

Our monitoring stack combines InboxKit's dashboard data with our sequencer analytics through InboxKit's API. We have built custom reporting layers on top that give us metrics neither tool provides alone:

• Per-domain reply rates cross-referenced with inbox placement scores
• Automated alerts when a domain's engagement metrics deviate from its historical baseline
• Portfolio-level health dashboards showing all 100+ clients at a glance

The API is clean and well-documented, which made building these integrations straightforward.

Workspaces and team access

With a team managing this volume of infrastructure, workspace management matters. InboxKit's team workspace features let us organize client infrastructure, control access for team members, and maintain clean separation between accounts. No one accidentally modifies the wrong client's DNS records at 2 AM.

Pricing that makes sense at volume

At 50 domains per client across 100+ clients, per-inbox pricing adds up fast. InboxKit's pricing structure stays reasonable at scale, which is critical when infrastructure cost is a line item you need to justify to every client.

Scaling cold email infrastructure is not about buying more inboxes. It is about building a system that gets better over time: monthly rotation that compounds quality, naming conventions that protect reputation, warm-up that never stops, and retirement triggers that cut problems before they spread.

InboxKit is the infrastructure layer that makes this system possible at scale. The setup speed, domain isolation, and API flexibility are not nice-to-haves when you are managing thousands of sending accounts. They are operational necessities.

If you are running cold email at any serious volume, whether for your own company or for clients, the playbook above will save you from the mistakes we made in the early days. Start with the infrastructure math (more domains, fewer inboxes per domain, lower volume per inbox), and build the rotation and monitoring systems around it.

The domains are disposable. The system is what compounds.

This case study was written by Dimitar Petkov, Co-Founder at LeadHaste.

LeadHaste is an outbound growth partner that builds, launches, and manages precision cold email systems for B2B companies. We orchestrate 20+ tools into one compounding outbound machine, and clients own everything we build. Book a free pilot to see the system in action.