Build cold email infrastructure once
Cold email infrastructure is the sending domains, mailboxes and DNS records your outbound goes out from, kept away from the domain your invoices and your investors' email run on. It is not your sequencer and it is not a shopping list. It is one decision about blast radius, plus arithmetic from two providers' published limits.
By Kshitij Maheshwari, co-founder · Updated August 2026 · 21 min read
Written by operators who build and run this for seed-stage teams, not by a company selling you mailboxes.
What cold email infrastructure actually is, and who named it
It is the identity your outbound sends from: the domains, the mailboxes behind them, and the records that let a receiver check both. The sequencer decides what goes out and when. The infrastructure decides who it appears to come from.
Cold email infrastructure is the sending domains, mailboxes and authentication records you run outbound from, held apart from your primary domain so a bad campaign cannot reach it.
The term is worth a little suspicion. It appears in no RFC, in no M3AAWG document, and in neither provider's sender documentation. It came out of the mailbox reseller category itself, which is also who wrote nearly everything ranking for it.
So ask three companies what it means and you get three products back:
Infrastructure is the domains and mailboxes you rent from them, plus the DNS wiring, because that is the shelf they stock.
Infrastructure is everything upstream of the sending tool, which conveniently makes it a different company's problem than theirs.
Infrastructure is the IP, domain and authentication identity a receiver evaluates. This one is closest to right, and it is the rarest.
Founders make the slip in reverse, calling a sequencer their infrastructure. Smartlead and Instantly are a separate purchase on a separate invoice, compared on our cold email tools guide.
The infrastructure decides whether a message is allowed to arrive. It has never once decided whether anyone wanted it. Build it to earn the right to be judged on your offer, not to rescue a weak one.
The one decision the whole build comes out of
You are not choosing a product. You are deciding which identity absorbs the damage when a campaign goes wrong, then building so nothing else can be touched by it.
The domain your contracts, your invoices, your investor updates and your support inbox run on. If that lands in spam, cold email was not the expensive part.
A sending domain, a mailbox, a month of ramp. All replaceable for a registration fee and some patience, as long as none of it points back at the first one.
The standing attached to the domain everyone already has in their address book. Records and mailboxes you can rebuild in an afternoon. That, you cannot.
Every downstream question, how many domains, which provider, which records, is arithmetic once you have answered the first one. Teams that skip it end up buying a shape a vendor picked for them.
Why you do not send from your main domain
Because a complaint attaches to the domain that sent the message, and you cannot separate the campaign from the invoice once they share one.
- ✓A blast radius that stops at a domain you can abandon
- ✓Room to ramp without touching live business mail
- ✓Per-domain records, so one broken setup breaks one domain
- ✓A reputation you can lose without losing your billing
- !The new domain inherits nothing, so you start at zero
- !Nothing you build there transfers back to your main domain
- !Every extra domain is another MX, alias pair and page
- !The fan-out is the shape abuse uses, and receivers know it
Here is the part the category does not print. The industry's own standard tells you not to build the thing the industry sells you, and the objection is worth reading before you overrule it.
Cousin domains, their use is strongly discouraged. The main recommendation of this industry best common practices document: send from subdomains of the main domain.
Cold outbound does the opposite on purpose. A subdomain shares the parent's fate, and the entire point of the build is that nothing shares your parent's fate.
We still build separate domains, knowing what the standard says, and we do not pretend the trade is free. What we refuse to skip is the part that makes the shape look legitimate: a real page, a real MX, monitored addresses, correct records.
A secondary domain that does none of that is just a cheap domain with your name misspelled in it.
How many domains and mailboxes: the arithmetic
Nobody ranking for this derives the number. They hand you one. Here is the arithmetic instead, and the two published ceilings it has to sit under.
| What it measures | The number | Who published it |
|---|---|---|
| Google Workspace, per user per day | 2,000 messages, and 3,000 external recipients. Exceed it and sending stops for up to 24 hours. | Google, sending limits documentation, as of August 2026 |
| Microsoft 365, per mailbox per day | 10,000 recipients, with a rate limit of 30 messages a minute. | Microsoft Learn, Exchange Online limits, page updated May 2026 |
| Microsoft 365, per tenant per day | External recipients capped across the whole tenant, scaled to license count. Trial tenants capped at 5,000. | Microsoft Learn, same page |
| What the tools recommend, per mailbox per day | Maildoso caps its own mailboxes at 15 cold sends. Smartlead and Instantly document 40 to 50. | Each tool, in its own pricing page or documentation, as of August 2026 |
Notice the gap. The providers publish ceilings in the thousands. The sending tools work to dozens, and their own documentation disagrees with itself, from 15 to 50. So the per-inbox number is a filtering convention you choose and defend, not a limit anyone enforces. Pick one, write down why, and change it for a reason, not because a vendor says so.
Say you want 300 sends a day. At a 30 a mailbox convention that is 10 mailboxes. At 2 mailboxes a domain that is 5 domains, each one needing an MX, two monitored aliases, its own DKIM selector, a DMARC record and a live page.
On Google, no published per-user limit comes close to binding. On Microsoft, check the tenant ceiling before you add mailboxes, because adding them inside one tenant does not add capacity in proportion. Change the convention and every number under it moves.
The lead time nobody plans for
You cannot buy sending capacity on day one, at any price. Both providers slow a brand new account on purpose, and both publish the terms.
Google starts you at 500 a day
Google's own sending-limits page puts trial accounts at 500 messages a day and 500 unique external recipients a day, against 2,000 and 3,000 on a paid account. Cross any of them and sending stops for up to 24 hours.
Paying does not lift it that day
Limits rise once the domain has cumulatively paid at least $100 USD. Google then says on the same page that it can take up to 75 days after meeting that threshold for account sending limits to increase. Not a queue you can jump.
Microsoft counts the whole tenant
Microsoft Learn documents a tenant external recipient rate limit, the most external recipients a tenant can reach in a rolling 24 hours. It scales with license count and caps trial tenants at 5,000 a day.
The default domain is throttled hardest
Microsoft documents on the same page that outbound from the default onmicrosoft.com domain is limited to 100 external recipients per organization in a rolling 24 hours, with a 550 5.7.236 rejection past it. Register and verify real sending domains before you test anything.
Then the warm-up sits on top
M3AAWG's Sending Domains BCP suggests treating six weeks as an average warm-up, from a body with no warm-up product to sell. That runs on top of the throttles, not instead of them, and ramping belongs to our deliverability guide.
So the order is fixed: buy the infrastructure before you build the list, and plan the first month at a fraction of the eventual number. A signal window will not wait 75 days for a quota review. Every promise to spin up fifty inboxes in ten minutes is true about provisioning and false about sending.
Provider choice: Google, Microsoft, or a reseller's SMTP
The real question is not placement percentages, which nobody in this category has measured and published. It is who owns the IP layer, and what happens to your authentication when they do.
| Option | Who owns the IP and PTR | How alignment happens | Published price, August 2026 | What breaks |
|---|---|---|---|---|
| Google Workspace | Google. The IP, the reverse DNS and TLS are its problem, not yours. | By construction. You publish Google's SPF include and its DKIM keys on your own domain. | Business Starter, €6.80 per user a month on Google's EU pricing page | Nothing you control. New tenants are throttled, and a price far under list means a different license. |
| Microsoft 365 | Microsoft, on the same terms. | By construction, same shape as Google. | Business Basic, $7.00 USD per user a month paid yearly | The tenant ceiling, and password-based SMTP sits on Microsoft's published deprecation path. |
| Reseller SMTP | A pool you cannot see, shared with senders you did not choose. | Depends on you. The return path (the address bounces and delivery reports actually go to) is often the vendor's domain, so DKIM on your domain does all the work. | Mailforge $3 a mailbox a month billed monthly, ten minimum; Maildoso $2.50 at thirty; Infraforge $4 billed quarterly | Alignment, quietly. You also inherit whatever the neighbors are doing. |
Ask any infrastructure vendor one question: what domain sits in the return path of my messages, and does it align with the domain in my From line? A vendor who cannot answer in a sentence is selling mailboxes, not deliverability. Which one to buy is its own comparison, and the two resellers priced above are broken out head to head.
A mailbox well under list price is not a discount, it is a different license type. Google publishes eligibility rules for Workspace for Education that a cold email agency does not meet. The risk is continuity, not deliverability.
The records, as a build task
This is not a click-by-click DNS tutorial and you do not need one. What you need is what each record is for, and the two places a correct-looking build breaks without telling you.
Chain every include
v=spf1 include:_spf.google.com include:sequencer.example include:warmup.example include:relay.example ~all
- ✕Four includes, each nesting more
- ✕Ten DNS lookups is a hard ceiling
- ✕Past it, every message permerrors
Count the lookups first
v=spf1 include:_spf.google.com ~all
- ✓One include, counted at build time
- ✓DKIM carries the sequencer's mail
- ✓Aligned, and nowhere near the ceiling
It checks an address nobody reads
SPF checks the envelope sender and the HELO name, not the From line a human sees. The SPF standard caps DNS-querying terms at ten; past that, every message returns permerror, which evaluates as if you had published nothing.
One selector per sending domain
M3AAWG's Sending Domains BCP says each sending subdomain should sign with a different selector, and that keys must be generated at a minimum of 1024 bits. A shared selector across domains is a single point of failure you built on purpose.
Publish it, and actually read it
Publish it on every sending domain, and actually read what comes back. Start at p=none: it asks for reports on failing mail, and blocks or quarantines nothing. RFC 9989 then moved DMARC onto the Standards Track in May 2026 and removed the pct tag, so staged-rollout advice built on it is out of date.
A domain that cannot receive is unfinished
M3AAWG is explicit here: a sending domain needs a proper MX record pointing at a functional mail server, and abuse@ and postmaster@ that exist, are read, and never bounce. Almost no self-built cold infrastructure does this.
Point it at something real
M3AAWG says the domain in the visible From should resolve or forward to a live current page related to the sender. A recipient who checks a suspicious domain and finds a parking screen has learned something about you.
None of that is the bulk-sender specification. Cross 5,000 messages a day to Gmail accounts and a stricter tier applies, laid out in the Google and Yahoo sender rules. Below it you still owe the baseline: SPF or DKIM, valid forward and reverse DNS, and TLS.
Alignment is the status, not "we set them up"
Having the records is not a status. Aligned is a status, and only one of the two can be tested.
Records present means three DNS lookups resolve. Aligned means the domain in the From line matches an authenticated identity, which is what DMARC evaluates. A build can pass the first and fail the second on every message.
One test settles it, in ten minutes. Send a real message from every sending mailbox to an address you control at Gmail and Microsoft, then open the headers. You want SPF pass, DKIM pass, DMARC pass, and the From domain aligned with the signing domain or the return path. Anything short of that is a guess with good paperwork.
Count your SPF lookups on the day you build, not the day something breaks. A mailbox provider, a sequencer and a warm-up tool chained through nested includes will walk you past ten, and permerror does not announce itself.
Want the build done once, properly, and handed over?
Book a Fit CheckWhat the build costs, honestly
Every figure below comes from the vendor's own page and is current as of August 2026. Prices in this category move, so treat these as the shape of the bill rather than a quote.
The cheapest line, and the one that multiplies
A .com is $11.08 at Porkbun for registration and renewal. Mailforge and Infraforge list domains at $14 a year, Maildoso at $12. The cost is trivial. The maintenance behind each one is not.
Cheap per unit, opaque per message
Mailforge lists $3 a mailbox a month billed monthly, about $2.40 billed yearly, with a ten-mailbox minimum. Maildoso lists $2.50 at thirty mailboxes, falling to $0.49 at a thousand. Infraforge lists $4 billed quarterly, about $3.32 annually. All from their own pricing pages.
The honest comparison price
Google Workspace Business Starter is €6.80 per user a month on Google's EU pricing page. Microsoft 365 Business Basic is $7.00 USD per user a month paid yearly. Different currencies and locales, so compare the shape rather than converting.
The line most teams should not buy
Infraforge lists a dedicated IP at $99 an IP a month. An IP earns its reputation from consistent volume, and a program deliberately spread across dozens of mailboxes never concentrates enough on any one of them to matter.
Not infrastructure, and billed separately
The tool that decides what goes out and when is a different purchase on a different invoice. We keep it out of the infrastructure number on purpose, because bundling the two is how a build gets priced by whoever is selling the sequencer.
Warm-up tooling, list verification, and whoever runs the thing all sit outside this number. So does our own pricing, which is scoped on a fit check rather than published. Add the parts you will actually buy.
What the architecture costs you in visibility
The same fan-out that protects your primary domain is what stops you seeing whether any of it is working.
Google's own Postmaster Tools help says data might be missing if a day's total message count is too low, to protect users' privacy, and it publishes no numeric floor. Split fifty sends a day across ten domains and none will ever populate. So the architecture the category sells you is also why you cannot read Google's one free reputation signal.
Pick one on purpose: concentrate volume on fewer domains and read a real reputation signal, or spread it thin and monitor at the reply and bounce layer. Assuming both is how teams fly blind for a quarter.
Whichever you pick, the thresholds, the monitoring cadence and what to do when a number moves belong to the cold email deliverability guide, not here. This page stops at a build you can prove is correct.
The unsubscribe, reply and bounce paths
Decide these before the first send, not after the first complaint. A build with no suppression path is not finished, whatever the DNS says.
-
1Before send · Opt-outs
One suppression list, all domains
Decide where an opt-out lands and what honors it across every mailbox and every domain. A list living inside one sequencer is not a suppression path, it is a setting.
-
2Before send · Replies
A human sees every reply
Every sending mailbox needs a route to a person, including the ones nobody logs into. Route abuse@ and postmaster@ the same way, because that is where a receiver tells you something is wrong.
-
3Before send · Bounces
Bounces get read, not counted
Hard bounces usually mean the list was wrong before the infrastructure was. Verify before you send, and read a rising bounce rate as a data problem first.
Running the build: the order of operations
None of this is difficult. The order is what saves you, because one of the five steps has a lead time you cannot compress and the other four do not.
-
1
Buy the domains and mailboxes first
Before the list, before the copy, before the sequencer. This is the only part of the build with a lead time you cannot buy your way past, so it goes first and everything else waits on it.
-
2
Finish each domain before adding the next
MX, abuse@ and postmaster@ routed to a person, a distinct DKIM selector, a DMARC record with a reporting address, and a real page. A half-built domain is worse than one you never registered.
-
3
Count the SPF lookups, then connect the tools
Add only the includes you actually need, and count them before you connect the sequencer and the warm-up tool. Five minutes here, or months of silent permerror later.
-
4
Test from every mailbox, at both providers
One real message to an address you control at Gmail and at Microsoft, from each mailbox. Read the headers. Fix whatever fails before anything touches a prospect.
-
5
Ramp, then point a campaign at it
Warm-up and volume ramping start here and belong to the deliverability side of the work. The build is done when the test passes, not when the ramp finishes.
The step teams skip is the second one. Registering forty domains takes an afternoon and finishing one takes an hour, so the finishing never happens. Build the number of domains you are willing to maintain, then stop.
That order holds whether you run it yourself or hand it to one of the shops that do this for a living.
How you know the build is done and correct
Every guide in this category ends on a setup checklist. None gives you a way to prove the build is right before you point a campaign at it. This is ours.
- 1 One real message from every sending mailbox, to Gmail and to Microsoft.
- 2 Headers show SPF pass, DKIM pass, DMARC pass, and alignment.
- 3 SPF resolves inside ten DNS lookups, with no permerror.
- 4 MX resolves, and abuse@ and postmaster@ receive without bouncing.
- 5 Every sending domain loads a page you would show a buyer.
- 6 A reply, a bounce and an opt-out each reach a human.
Almost every self-built infrastructure passes one or two of these and quietly fails the rest. If all six hold, the build is correct, and everything after it is deliverability rather than construction.
Where infrastructure builds go wrong
None of these are exotic. Every one of them shows up on a build that looks finished from the DNS side.
The domain in your From line resolves to a registrar placeholder. Anyone who checks has now learned exactly what you are.
The one channel a receiver has for telling you something is wrong, pointed at nothing. You find out from your own reply rate instead, weeks later.
One include too many, and the specification says hard failure. Every record still looks present in a DNS checker while every message goes out unauthenticated.
One policy change or one suspension wave stops the whole program at once. Running two is a resilience decision, not a placement trick.
You do not know which edition the mailbox sits on or how it was created. The failure mode is not spam, it is the mailbox disappearing mid-campaign.
Opt-outs live in one tool, replies land where nobody looks, bounces are a number on a dashboard. The build works and the program does not.
If you are already sending and messages land in spam, start from the symptoms in why cold emails go to spam, then come back when the answer turns out to be the build.
Where the common advice is wrong
Nearly every page ranking for this query is published by a company that sells the mailboxes or the sequencer that uses them. Four claims that do not survive a look at the specifications.
"Spin up forty domains with two or three inboxes each, hold every inbox under thirty sends a day, and you are safe."
- ✕More domains means more safety
- ✕Thirty a day is the rule
- ✕Infrastructure is why your cold email fails
- ✕A dedicated IP protects you
"Build the number of domains you can finish and monitor, pick a per-inbox convention you can defend, and let the offer do the convincing."
- ✓More domains is more surface, not more safety
- ✓The tools quoting the number disagree, from 15 to 50
- ✓A perfect build sends a bad message faster
- ✓Spread thin, an IP never earns a reputation
The Spamhaus Project's glossary defines snowshoe spamming as spreading output across many IPs and domains to dilute reputation metrics and evade filters. That is the standard cold email build, described by the people who maintain the blocklists. You cannot escape the shape and still protect your primary domain, so the only move left is to be that shape with a real company behind it.
Which is why we point people at the message before the mailboxes. Infrastructure buys the right to be judged on your offer and nothing more, so if replies are the problem, start with the copy, not another domain.
Questions founders ask
What is cold email infrastructure, in plain terms?
How many domains and inboxes do I need?
Which per-inbox number do I use in the arithmetic?
How long before I can actually send?
Where does the infrastructure bill actually go?
Do I need SPF, DKIM and DMARC on every sending domain, and is that enough?
Co-founder of Real Good GTM. He has been the first business hire and Chief of Staff at seed-stage B2B startups, and has built and rebuilt the sending side of outbound often enough to have opinions about it. Infrastructure and deliverability sit inside the engine we run for early-stage teams, which is why this guide reads like a build sheet rather than a product page.
Connect on LinkedInThe build is done. Now what?
Three directions from here: keeping it healthy, choosing what to buy, and deciding what you point at it.
Cold email deliverability
Exactly where this page stops: reputation, ramping, list hygiene, what to monitor, and what to do when a number moves against you.
Read the guideBest cold email infrastructure tools
This page says how to design the build. That one says which mailboxes and domains to actually buy, including who should skip the category.
Compare the toolsSignal-based selling
What you point the build at. Outbound triggered by a real buying event instead of a static list, which is the part infrastructure cannot fix for you.
Read the guideWant the build run for you, records and all?
Book a fit check. We'll look at what you are sending from today, how much capacity you actually need, and whether the build is your problem or your offer is. If it's the offer, we'll tell you that too.
Book a Fit CheckNo hard sell. No fake numbers. Real good work speaks for itself.