How to Set Up a Cold Email Stack That Sends 3,000 Emails a Day (2026)

The full build for a 3,000 emails a day cold email system: domains, inboxes, authentication, warmup, sending tools, and the per-inbox math that keeps you out of spam. Plain English, real tools, real costs.

Most people who want to send more cold email do the obvious thing. They take their company inbox, plug it into a sending tool, and crank the daily volume up. Within a few weeks their open rates collapse, replies dry up, and their main domain starts landing in spam for normal business email too. They blame the copy. The copy was rarely the problem.

The problem is infrastructure. Sending 3,000 cold emails a day is not one inbox working hard. It is dozens of inboxes, spread across many domains, split between two email providers, each one sending a small and safe amount, all of it rotated by a sending tool so no single inbox ever looks like a spam machine. When you build it this way, you can send serious volume and still land in the primary inbox. When you skip the structure, you burn your reputation and there is no quick way to get it back.

I run these systems for B2B companies, so this is the build we actually use, not a theory. By the end of this guide you will understand exactly how to get to 3,000 sends a day: how many domains and inboxes you need, why the per-inbox limits matter, how to authenticate domains so you stay out of spam, how warmup works, the difference between the Google and Microsoft sides of the stack, which sending tool ties it together, and roughly what the whole thing costs per month.

This is a long one because the build has a lot of moving parts. I have put the full summary table and a step-by-step checklist near the end so you can come back to them. Let us start with the math, because the math is the spine of everything else.

TL;DR / Key takeaways

• To send 3,000 cold emails a day reliably, you spread the volume across roughly 35 sending domains and 75 inboxes. No inbox sends much.

• Split the volume 50/50: 1,500 a day through Google Workspace (Gmail) and 1,500 a day through Microsoft (Outlook on Azure). Two providers means risk diversification and different spam filtering.

• Gmail side: send about 25 emails per inbox per day. That needs about 60 inboxes across about 20 domains (roughly 3 inboxes per domain).

• Outlook side on Azure: you can push higher per domain, about 100 a day, so you need about 15 domains.

• Never send cold email from your main company domain. Use separate sending domains that redirect to your main site.

• Authenticate every domain with SPF, DKIM, and DMARC. Without these you go straight to spam.

• Warm every inbox for 2 to 4 weeks before sending real campaigns, and ramp volume up slowly.

• A sending tool like Instantly or Smartlead rotates your campaigns across all the inboxes so no single one gets overloaded.

• Budget roughly $700 to $1,300 a month for a 3,000 a day stack, depending on provider mix and tools.

1. The core math: how 3,000 a day is actually built

Before buying a single domain, you need to understand why a 3,000 a day stack looks the way it does. Almost every decision flows from one rule: each individual inbox should send a small, human-looking amount of email every day. Once you accept that rule, the rest is arithmetic.

Why per-inbox limits matter

An inbox provider like Google or Microsoft is constantly judging your sender reputation. They watch how much you send, how fast you ramp up, how many people open and reply, how many bounce, and how many mark you as spam. A brand new inbox that suddenly fires off 200 cold emails on day one looks exactly like a spammer, because that is what spammers do. The provider throttles you or starts routing your mail to spam.

A safe, established inbox sending 25 to 50 emails a day to recipients who sometimes reply looks like a real person doing real outreach. That is the behaviour we are trying to imitate, because it is the behaviour that lands in the primary inbox.

So we keep per-inbox volume low on purpose and add more inboxes to reach the total. The volume comes from the number of inboxes, never from pushing any single one hard.

Why split across many domains

You could in theory put a lot of inboxes on a handful of domains. You should not. A domain is a single reputation bucket. If one domain gets flagged, every inbox on it suffers at the same time.

Spreading inboxes across many domains is risk isolation. If one domain burns, you lose a small slice of your sending capacity and you keep going. Lose one domain out of twenty and you have lost five percent of your stack, not all of it. This is the single most important reason the stack uses dozens of domains instead of a few.

Why a separate sending domain, never your main one

This is the mistake that hurts the most, so I will be blunt about it. Never send cold email from your primary company domain.

If your company is acme.com, and you blast cold email from names@acme.com, you are gambling your real domain reputation on a cold campaign. If it goes wrong, your invoices, your support emails, and your replies to existing customers can all start landing in spam. There is no fast fix for a burned primary domain.

Instead you buy lookalike sending domains, things like getacme.com, acme-hq.com, tryacme.io, and you point them all to redirect to your real site. The cold email runs entirely on these throwaway domains. If one gets burned you delete it and spin up another. Your real domain never touches a cold campaign.

Why both Google and Microsoft

We split the 3,000 across two providers, Google Workspace on one side and Microsoft on the other. Two reasons.

First, diversification. If Google changes a policy, throttles a sending pattern, or suspends accounts in a sweep, half your stack keeps running on Microsoft. You are never one provider decision away from going dark.

Second, different spam filtering. Google and Microsoft judge mail differently and inbox to different places. Some of your prospects use Gmail, some use Outlook, and mail tends to land better when the sending provider matches or at least when you are not putting all your eggs in one filtering system. Sending from both sides gives you broader, more resilient inboxing.

The numbers, step by step

Here is the whole calculation in plain English.

The goal is 3,000 cold emails per day.

Split it 50/50 across the two providers. That is 1,500 a day on the Google side and 1,500 a day on the Microsoft side.

On the Google side, we send about 25 emails per inbox per day. This is deliberately conservative. Google is strict, and 25 a day per inbox is a volume that keeps reputation healthy. To get 1,500 a day at 25 per inbox: 1,500 divided by 25 equals 60 inboxes. We put about 3 inboxes on each domain, so 60 inboxes divided by 3 equals 20 domains on the Google side.

On the Microsoft side, we use Azure tenants, which let us run higher volume per domain safely. (A tenant is just Microsoft's word for one organisation's account, which owns one or more domains and their inboxes.) We send about 100 emails per domain or tenant per day. To get 1,500 a day at 100 per domain: 1,500 divided by 100 equals 15 domains on the Microsoft side.

Add it up. The Google side is 20 domains and 60 inboxes. The Microsoft side is 15 domains. Together that is roughly 35 domains and the full 3,000 a day. We will lay this out as a clean table in section 9.

The exact per-inbox numbers are judgement calls, not laws. Some operators run Gmail a little higher once an inbox is well aged, some run it lower to be safe. The principle holds either way: keep each inbox modest and reach your total through breadth.

2. Buying and configuring your sending domains

With the math settled, the first thing you build is the domains. You need around 35 of them for a 3,000 a day stack.

Choosing the domains

Buy variations of your brand that a recipient would still trust. If your company is acme.com, good sending domains look like getacme.com, acmehq.com, tryacme.io, acme-team.com. They should read as obviously connected to you, not random.

A few practical rules:

• Prefer the cheaper, clean top-level domains like .com, .co, and .io. Avoid the spammy bargain-bin endings (.click, .live, .info and similar), because some spam filters distrust them by default.

• Spread purchases across a couple of registrars (Cloudflare, Namecheap, Porkbull and the like) rather than buying all 35 in one place on one day. It is cleaner and avoids any single point of failure.

• Keep a simple spreadsheet of every domain, where it is registered, what it redirects to, and which inboxes live on it. You will thank yourself later.

Redirecting them to your main site

Each sending domain should redirect to your real website. When a prospect gets your email and types the domain into a browser, or clicks through out of curiosity, they should land on your actual company site, not a parked-domain error page. An error page or a blank domain looks suspicious and hurts trust.

The redirect is a one-time setup at the registrar or DNS provider: point the sending domain to your main site with a simple forward. Do this for all of them before they start sending.

3. Domain authentication: SPF, DKIM, and DMARC explained simply

This is the part that scares non-technical founders, and it should not. SPF, DKIM, and DMARC are three small records you add to each domain's DNS settings. DNS is the address book of the internet, and these records are notes in that address book that tell receiving mail servers "this sender is legitimate." Without them, you go to spam. With them, you have cleared the basic bar to reach the inbox.

You set all three on every sending domain. Here is what each one does, in plain terms.

SPF: who is allowed to send for this domain

SPF stands for Sender Policy Framework. It is a list of which mail servers are permitted to send email on behalf of your domain. When a receiving server gets your email, it checks the SPF record to confirm the email came from an approved server and not from an impostor.

In plain English: SPF says "these are the post offices allowed to send letters with my return address." If a letter shows up from a post office not on the list, the receiver treats it as suspect.

DKIM: proof the email was not tampered with

DKIM stands for DomainKeys Identified Mail. It adds an invisible digital signature to every email you send. The receiving server uses a key published in your DNS to check that signature. If it matches, the server knows the email came from you and was not altered in transit.

In plain English: DKIM is a tamper-proof seal on the envelope. If the seal is intact and matches your published key, the receiver trusts the contents came from you and were not altered.

DMARC: what to do if the checks fail

DMARC stands for Domain-based Message Authentication, Reporting and Conformance. It ties SPF and DKIM together and tells the receiving server what to do when an email fails those checks: let it through, send it to spam, or reject it. It also lets you receive reports on who is sending mail using your domain.

In plain English: DMARC is the policy that says "if a letter claiming to be from me fails the return-address check and the seal check, here is how to handle it." For cold email a relaxed policy is fine to start with. The point is that the record exists and is set up correctly, because receiving servers increasingly expect to see one.

The good news

You almost never set these up by hand record by record. Both Google Workspace and Microsoft give you the exact records to paste in, and most done-for-you inbox providers (more on those next) configure SPF, DKIM, and DMARC automatically when they provision your domains. If you buy infrastructure through a provider like Mailreef, Maildoso, or the inbox setup built into Instantly and Smartlead, the authentication is handled for you. If you build it manually, follow Google's and Microsoft's own step-by-step pages, because they give you the precise values to enter.

4. Inbox setup, per-inbox limits, and ramp-up

Once domains are bought, authenticated, and redirecting, you create the inboxes on them.

How many inboxes per domain

On the Google side, put about 3 inboxes per domain. Across 20 domains that is your 60 Gmail inboxes. The inbox names should look like real people: john@getacme.com, sarah.lee@acmehq.com, and so on. Avoid obvious role accounts like sales@ or info@ for cold sending, because filters treat those with more suspicion.

On the Microsoft side, you can run inboxes per domain too, but because Azure lets you push more volume per domain, you size the inboxes to hit roughly 100 a day per domain in total.

Per-inbox daily limits

Set each Gmail inbox to send around 25 cold emails a day once it is fully warmed. On the Microsoft side, the per-domain ceiling is higher (around 100 a day) and you divide that across the inboxes on the domain.

Keep these limits in the sending tool, not just in your head. Instantly and Smartlead both let you cap the daily sending volume per inbox, and they will respect that cap when they rotate your campaigns. This is your safety rail.

Ramp-up: do not start at full volume

A brand new inbox should not send 25 cold emails on its first real day. You ramp. Start low, maybe 5 to 10 a day in the first week of live campaigns, and step up over two to three weeks until you reach the full per-inbox limit. This gradual increase mirrors how a real person's sending grows and keeps the providers comfortable. The sending tools have a ramp setting that does this automatically once you turn it on.

5. Warmup: what it is and why you cannot skip it

Warmup is the process of building an inbox's reputation before you send a single real campaign from it. A fresh inbox has no history, and a no-history inbox that starts cold emailing looks risky to the provider. Warmup gives it a track record of normal, healthy email behaviour first.

How warmup works

Warmup tools have your inboxes send small, friendly emails back and forth with a large network of other real inboxes. Those emails get opened, replied to, and pulled out of the spam folder if they land there. To the provider, your inbox now looks like it belongs to someone who sends and receives normal email that people engage with. That is exactly the reputation you want before going live.

How long it takes

Warm each inbox for about 2 to 4 weeks before using it for real campaigns. Two weeks is the floor. Three to four weeks is safer, especially on the Microsoft side, which can be slower to trust new senders. You also keep a low level of warmup running in the background even after the inbox goes live, so its reputation stays topped up while it sends real campaigns.

The tools

Warmup is built into the main sending platforms. Instantly includes warmup across all your connected inboxes. Smartlead does the same. There are also standalone warmup tools, but for most stacks using the warmup that comes with your sending platform is simpler and keeps everything in one place. Turn it on the day each inbox is created, then leave it running.

The order matters: buy and authenticate domains, create inboxes, start warmup immediately, wait two to four weeks, then begin real campaigns. Skipping or rushing warmup is one of the fastest ways to burn a stack before it has sent a single useful email.

6. Google Workspace vs Microsoft on Azure: which to use and when

The two sides of the stack behave differently. Here is how I think about each.

The Google (Gmail / Google Workspace) side

You set up Google Workspace, add your sending domains to it, and create the inboxes. Google is strict on cold email, which is why we keep per-inbox volume low at around 25 a day. The upside is that a healthy, well-warmed Gmail inbox tends to inbox well and reach the many prospects who use Gmail or Google Workspace themselves.

Cost-wise, standard Google Workspace runs at a per-inbox monthly fee, which adds up across 60 inboxes. There are reseller and infrastructure providers that offer Google inboxes more cheaply at volume, which is how most agencies keep the Google side affordable.

Pros: strong inboxing when warmed, trusted by recipients, well supported by every sending tool. Cons: strict limits mean more inboxes for the same volume, and per-inbox cost is higher than the Microsoft side at scale.

Use the Google side as a core, reliable half of every stack. I would never run a 3,000 a day system on Microsoft alone.

The Microsoft (Outlook / Azure) side

The Microsoft side is set up through Azure, Microsoft's cloud platform, where you create tenants (organisation accounts), add domains, and provision Outlook inboxes. The big advantage is volume economics: you can run higher sending per domain, around 100 a day, which means fewer domains and a lower cost per email sent. This is why the Microsoft side carries half the load with only about 15 domains versus 20 on the Google side.

The tradeoff is that the Azure setup is more technical to stand up yourself, and Microsoft can be slower to trust new senders, so warmup matters even more here. Most people use an infrastructure provider that handles the Azure provisioning, so you get the cost advantage without doing the cloud engineering by hand.

Pros: cheaper per email at volume, higher per-domain throughput, fewer domains to manage. Cons: more technical to set up from scratch, can be stricter on brand new senders, slower to warm.

Use the Microsoft side to carry volume efficiently alongside the Google side. The two together give you both reliability and economics, which is the whole point of the 50/50 split.

7. The sending tool layer: how Instantly or Smartlead ties it together

You now have 35 domains, 75 inboxes, all authenticated and warmed. You do not log into 75 inboxes to send. The sending tool is the layer that connects every inbox and runs your campaigns across all of them at once.

What the sending tool does

You connect every inbox to the platform once. You load your prospect list and write your email sequence. Then the tool distributes the sending across all your connected inboxes, respecting each inbox's daily cap. This is inbox rotation: instead of one inbox sending 3,000 emails, the tool spreads those 3,000 across the 75 inboxes so each one sends its small, safe share.

Rotation is what makes the whole stack work as one system. From your side you set up a single campaign aimed at 3,000 prospects. Behind the scenes the tool decides which inbox sends which email, paces the sending through the day, and stays within every limit you set. It also handles the replies: when a prospect responds, the tool pulls that into a single shared inbox so you manage all conversations in one place rather than across 75 logins.

Instantly vs Smartlead

Both are strong. Instantly is the one we use most. It connects unlimited inboxes on the right plan, includes warmup across all of them, rotates campaigns across inboxes automatically, and has a clean shared inbox for replies. Its analytics API is solid, which matters when you want to track campaign and variant performance programmatically. One detail worth knowing if you ever go deep on the data side: Instantly's API keys are per workspace, so a setup spanning multiple clients uses one key per workspace.

Smartlead is the main alternative and works on the same principles: connect inboxes, warm them, rotate campaigns, unified reply inbox. Teams choose between the two on price, interface preference, and specific features. Either one will run a 3,000 a day stack well. Pick one and learn it deeply rather than splitting across both.

Where the sending tool fits the cold email system

The sending tool is the engine, but it is only one part of a working outbound system. Upstream of it you have your prospect data and list building (tools like Apollo and Clay), and the offer and copy that actually earn replies. The best infrastructure in the world still fails behind a weak offer. We have written separately about why most cold email fails on the offer, not the copy, and the same caution applies here: build the stack properly, but do not expect plumbing to fix a message nobody wants.

8. Monitoring deliverability: knowing if you are landing

A stack that lands today can drift into spam next month if you are not watching. Monitoring is how you catch a problem while it is still small. Three things to track.

Google Postmaster Tools

Google Postmaster Tools is a free dashboard from Google that shows the reputation of your sending domains: spam complaint rates, domain reputation, and authentication pass rates. Connect your Google sending domains to it. If a domain's reputation drops or spam complaints climb, you see it here before your reply rate craters. This is your early warning system on the Google side.

Spam placement tests

A spam placement test (sometimes called a seed test) sends your campaign to a set of test inboxes across Gmail, Outlook, and others, then reports where it landed: primary inbox, promotions, or spam. Tools like GlockApps and the placement checks built into the sending platforms do this. Run one before launching a big campaign and periodically while it runs. If you are landing in spam on a test, fix it before you burn real prospects.

Reply and bounce rates

Your own campaign numbers are the most honest signal of all.

• Reply rate: a healthy cold campaign with a good offer and list earns replies in the low single digits and up. A sudden drop usually means deliverability slipped, not that the copy got worse overnight.

• Bounce rate: keep it low, ideally under 2 to 3 percent. A high bounce rate means your list is dirty, and dirty lists wreck sender reputation fast. Always verify your list with a tool like MillionVerifier before sending. Bounces are one of the quickest ways to burn a domain.

• Spam complaint rate: keep it very low. If people are marking you as spam, your targeting or offer is off, and the providers will punish the whole stack.

Watch these weekly. The stack is not a set-and-forget machine. It is closer to a garden you check on regularly and prune when something starts to go wrong.

9. The full stack at a glance

Here is the whole 3,000 a day stack in one table. This is the practical anchor to come back to.

The shape to remember: the volume comes from breadth, not from any inbox working hard. Roughly 35 domains, 75 inboxes, split evenly across two providers, each inbox sending a small and safe amount, all rotated by one sending tool.

10. Common mistakes that burn a stack

I have seen every one of these kill an otherwise good system. Avoid them and you are most of the way there.

• Sending from your main domain. The cardinal sin. One bad campaign and your real business email goes to spam. Always use separate sending domains.

• Skipping or rushing warmup. A cold inbox that starts blasting on day one looks like a spammer and gets throttled. Two to four weeks, no shortcuts.

• Cranking per-inbox volume too high. Pushing one inbox to 100, 200, or more a day to save on inboxes defeats the entire design. Keep each inbox modest.

• Missing or broken authentication. No SPF, DKIM, or DMARC means straight to spam. Set all three on every domain and confirm they pass.

• Sending to an unverified list. Dirty lists bounce, and bounces burn reputation. Verify every list before it goes near your inboxes.

• Putting too many inboxes on too few domains. Concentrating risk means one burned domain takes down a big chunk of your capacity. Spread wide.

• Ignoring the numbers. Deliverability drifts. If you are not watching Postmaster, placement tests, and bounce and reply rates, you find out you are in spam only after the campaign has already failed.

• Treating infrastructure as the whole job. The stack gets you to the inbox. A weak offer and a bad list still get ignored once you are there. Infrastructure is necessary, not sufficient.

11. Cost ballpark for a 3,000 a day stack

Exact costs move with providers and how much you do yourself, but here is a realistic monthly range for a 3,000 a day stack.

• Domains: around 35 domains at roughly $10 to $15 a year each works out to a small monthly figure, on the order of $30 to $45 a month amortised.

• Google inboxes: the Google side is the bigger line item. Whether you go direct on Google Workspace or through a cheaper infrastructure reseller, budget somewhere in the range of $300 to $600 a month for the 60 Gmail inboxes, depending heavily on the route you choose.

• Microsoft inboxes: the Azure side is more cost-efficient per email. Budget roughly $150 to $350 a month for the Microsoft inboxes across 15 domains.

• Sending tool: Instantly or Smartlead on a plan that supports unlimited inboxes and includes warmup runs roughly $90 to $200 a month depending on tier.

• Monitoring: Google Postmaster is free. A placement testing tool like GlockApps adds a small amount, often $50 a month or less on lighter plans. List verification (MillionVerifier and similar) is pay as you go and cheap per check.

All in, a 3,000 a day stack typically lands somewhere around $700 to $1,300 a month. The spread is wide because the inbox sourcing route is the biggest variable. Buying inboxes direct from Google and Microsoft is the most expensive path; using a dedicated infrastructure provider is usually cheaper and handles the authentication and provisioning for you, which is why most agencies go that way at volume.

Set against what a single closed deal is worth in most B2B, infrastructure is rarely the place to cut corners. The cost of a burned domain and a stalled pipeline is far higher than the cost of building it right.

The build checklist

Work through this in order. Each step depends on the ones before it.

1. Decide your volume target and run the math. For 3,000 a day: 1,500 Google at ~25 per inbox (~60 inboxes, ~20 domains) and 1,500 Microsoft at ~100 per domain (~15 domains).

2. Buy your sending domains. Around 35 lookalike domains of your brand, on clean top-level domains, spread across a couple of registrars. Never your main domain.

3. Redirect every sending domain to your main website.

4. Set up your provider accounts. Google Workspace for the Google side, Azure tenants for the Microsoft side (or buy both through an infrastructure provider).

5. Add authentication to every domain. SPF, DKIM, and DMARC. Confirm all three pass.

6. Create your inboxes. About 3 per domain on Google with real-person names, sized inboxes on the Microsoft side to hit ~100 per domain.

7. Connect every inbox to your sending tool. Instantly or Smartlead.

8. Turn on warmup for every inbox immediately. Leave it running for 2 to 4 weeks.

9. Set per-inbox daily caps and turn on ramp-up in the sending tool.

10. Connect Google Postmaster Tools and run a spam placement test before going live.

11. Verify your prospect list with a tool like MillionVerifier.

12. Launch your first campaign at ramped volume, then watch reply, bounce, and spam rates weekly and adjust.

If you can tick all twelve, you have a stack that can carry 3,000 a day and stay in the inbox.

FAQ

Do I need 35 domains, or can I just send more per inbox?

You could try, and it would work for a little while, then collapse. The whole design exists because providers punish high per-inbox volume and reward modest, human-looking sending. The domains and inboxes are how you reach 3,000 a day without any single inbox looking like a spammer. There is no shortcut that gets you the volume and the deliverability at the same time.

How long until the stack is ready to send real campaigns?

Plan for about three to four weeks from buying domains to launching real campaigns, almost all of which is warmup. You can buy domains, authenticate, and create inboxes in a few days. The waiting is the warmup, and it is the part you cannot rush.

Gmail or Outlook: if I had to pick one, which is better for cold email?

Do not pick one if you can avoid it. The 50/50 split exists precisely because each has a weakness the other covers. If you were forced to start with one, I would start on the Google side for its reliable inboxing when warmed, then add the Microsoft side for volume economics. But a single-provider stack is a fragile stack.

What is the difference between a domain and an inbox?

A domain is the part after the @ (getacme.com). An inbox is a single email address on that domain (john@getacme.com). One domain holds several inboxes. We spread inboxes across many domains so that if one domain's reputation is damaged, only the inboxes on that one domain are affected.

Can a sending tool like Instantly fix bad deliverability on its own?

No. The sending tool rotates and paces your sending and runs warmup, which all helps. But if your domains are not authenticated, your list is dirty, or you skipped warmup, no tool will save you. The tool is the engine. Deliverability comes from the whole build being right.

What happens if one of my domains gets burned?

You stop sending from it, remove its inboxes from active campaigns, and replace it with a fresh domain that you warm from scratch. Because you spread across many domains, losing one is a small dent, not a disaster. This is the entire reason for the wide, distributed design.

Is 3,000 a day the right number for me?

It is a serious volume, suited to companies running outbound as a real channel with a large addressable market. Plenty of effective programs run at a few hundred a day. Build the volume your pipeline and list size actually justify. The math in this guide scales down cleanly: halve the targets and you halve the domains and inboxes.

Conclusion

Sending 3,000 cold emails a day is not about finding one inbox that can take the load. It is about building a wide, distributed system where no single inbox ever works hard, the risk is spread across many domains, and two providers share the volume so you are never one decision away from going dark. Get the domains, the authentication, the warmup, and the per-inbox limits right, and you can send serious volume and still land in the primary inbox. Get them wrong and you burn reputation you cannot quickly rebuild.

The math is the spine. Keep each inbox modest, reach your total through breadth, split across Google and Microsoft, and let a sending tool rotate the whole thing. Everything else in this guide is detail hanging off that one idea.

This is the kind of system we build and run for B2B companies day to day, from the infrastructure through to the lists, the offer, and the campaigns. If you would rather have a working stack handed to you than spend a month assembling one, that is what we do at ToplineX. Either way, build it properly, watch the numbers, and do not gamble your real domain on a cold campaign.