Cold Email Infrastructure: The Complete Setup Guide

Cold email lives or dies on infrastructure. The copy matters and the list matters, but if the domains, the mailboxes, the DNS or the warm-up are wrong, nothing else gets a chance to work. A filter decides about your message before a person sees the subject line, and almost everything it decides on was set weeks earlier, by you.

This is the setup we run in production, written out so you can build it by hand, or judge the work of any vendor who offers to build it for you. Every number here is one we send against. Where a provider publishes a limit we quote the provider; where the safe number is lower than the published limit, we say why.

Never send cold email from the domain your company runs on. Reputation damage there does not stay in one place: it follows your invoices, your password resets and your support replies. Buy separate sending domains and treat them as consumable. Variations of the brand work best, because a recipient who looks you up should find something coherent: getacme.com, acmehq.com, tryacme.com, acme-team.com. Stay on mainstream extensions, .com first, then .co and .io if you must. Avoid the cheap extensions that spam has ruined, and avoid hyphens and digits where you can; both correlate with throwaway domains in every filter's training data.

How many domains? Work backwards from the volume you actually need. At two mailboxes per domain and eight to ten sends per mailbox per day, one domain safely carries sixteen to twenty cold emails a day at steady state. A target of a thousand a day therefore needs roughly fifty to sixty-three mailboxes across twenty-five to thirty-two domains. One or two mailboxes per domain is safer than three, and three is the ceiling. Past that you are concentrating risk: the domain, not the mailbox, is the unit a filter eventually blocks.

Buy them before you need them. A domain that has existed for a month reads differently from one registered yesterday, and registrars rate-limit bulk registration anyway; ours caps at fifty a day. Point each sending domain at a real page, even a one-page redirect to your main site, so a curious recipient does not land on a parked page full of advertising. That single step costs nothing and removes one of the easiest reasons to distrust you.

Microsoft 365 packs cleanly. A fresh tenant comfortably carries about twenty-five licensed users, eight domains in a batch and three to four users per domain, and Exchange Online's own ceiling is ten thousand recipients a day, thirty messages a minute and five hundred recipients per message. Those are abuse limits, not deliverability advice, and you should never approach them. What Microsoft gives you is a well-regarded sending reputation and a tenant boundary that contains damage.

Google Workspace provisions well, particularly through domain-wide delegation, and gives you the strongest placement at Gmail, which is where most B2B replies come from. Its published limits are two thousand messages a day for a paid account, five hundred on a trial, and three thousand external recipients a day. Again, those numbers describe when Google stops you, not when Google starts distrusting you.

Self-hosting is the third route: your own mail hosts, real mailbox accounts, your own DKIM keys and your own IP addresses. It costs the least per mailbox and gives the most control, including control over reputation you cannot borrow from anyone. The price is that you operate it: the IP warm-up, the blocklist monitoring, the patching, the reverse DNS, the TLS certificates. That work is real and it never stops, which is exactly why we automated it.

Whichever route you pick, use fresh personas per domain. The same three names across twenty domains is a pattern, and pattern detection is what filters are for. Store the credentials somewhere encrypted and auditable rather than in a spreadsheet, because in eighteen months you will need to prove who had access to which mailbox and when.

The honest comparison is per mailbox per month, including the domain. A Google Workspace seat is $8.40 a month; a Microsoft 365 seat is whatever Microsoft charges for the plan you pick; a domain is about twelve dollars a year, so a dollar a month, shared across the two mailboxes on it. Provisioning work, if someone else does it, is a one-off: ours is five dollars a mailbox. A self-hosted server that carries a large fleet is $39 a month, or three for $99, and the marginal cost of an extra mailbox on a server you already run is close to nothing.

That means a fifty-mailbox fleet on Google Workspace costs about $445 a month in seats and domains, the same fleet self-hosted costs under a hundred, and the difference buys you Gmail's reputation and Google's uptime. Neither answer is wrong. The mistake is not pricing the third column: the hours spent writing DNS, chasing propagation, replacing burned domains and re-authenticating tenants. At fifty mailboxes that column is a day a month. At five hundred it is a job.

Every sending domain needs exactly four things. One SPF record, merged, never two, because two SPF TXT records on the same host is an automatic permanent error and the domain fails authentication outright. DKIM, with the key the provider issues, published on the selector the provider names, verified as signing rather than merely present. DMARC, starting at p=none with a reporting address so you can watch before you enforce. And correct MX records, because a sending domain that cannot receive mail cannot receive replies, bounces or the out-of-office messages that tell you a person exists.

Add two more if you can: a tracking subdomain for click redirects, and a reply subdomain if your platform separates them. Both keep your links and your reply path off shared reputations, which matters more every year as filters weigh the domains inside a message as heavily as the domain that sent it.

Watch the ten-lookup limit in SPF. Each include, a, mx and redirect costs a DNS lookup, and the eleventh causes a permanent error exactly like a duplicate record. Chains that worked when you had one provider break quietly when you add a second. Flatten or consolidate rather than stacking includes, and re-check after any provider change.

Then verify against public DNS rather than the registrar dashboard. The dashboard shows what you saved; the mailbox provider sees what a public resolver serves. Query it directly, with dig or any public resolver, and only trust a record once a resolver outside your account returns it. Propagation runs from minutes to hours. We treat a record as unverified until public proof comes back, and the same discipline works by hand.

Start every new mailbox at its provider's safe floor, a handful of messages a day, and ramp gradually toward the per-mailbox cap over two to three weeks. Real warm-up means conversation-shaped mail between real mailboxes that reply, and it includes rescuing messages that land in junk, because the rescue is the signal that teaches the filter. A warm-up that only sends is a warm-up that only looks busy.

During the ramp, warm-up traffic and campaign traffic share the same daily cap. This is the part teams get wrong: they finish a two-week warm-up, start a campaign at ten a day on top of a warm-up still running at eight, and wonder why placement fell. Count everything the mailbox sends.

Any bounce spike or spam-folder signal should pause the ramp automatically rather than waiting for someone to notice on Monday. The cost of pausing a mailbox for a day is nothing. The cost of pushing through a week of soft rejections is a domain you replace.

The clearest signal is not a drop in replies, which lags by weeks. It is the shape of the refusals. A 5.1.1 rejection means the address does not exist and says nothing about you. A 5.7.x rejection is a verdict about the sender: the receiving system looked at your domain, your IP or your authentication and declined. Those two live in different worlds, and treating them the same is the most common bookkeeping error in cold email.

The practical rule: never suppress a recipient because of a 5.7.x. The recipient did nothing. Suppress the sending domain instead, or pause sends to that provider from that domain, and investigate. We keep a refusal ledger for exactly this and put an automatic hold on a sending domain per provider when refusals cross a threshold, because the alternative is discovering the pattern after it has spread across the fleet.

Rotate early. A domain that has started collecting provider-level refusals rarely recovers enough to be worth the risk, and each additional day of sending teaches more filters the same lesson. Buy replacements before you need them so the rotation is a swap rather than a three-week gap in pipeline.

Setting infrastructure up is a project. Keeping it working is a routine, and the routine is where the cost actually lives. DNS drifts when a registrar migrates a zone or a colleague edits a record. Provider tokens expire, and a mailbox that has quietly stopped authenticating looks exactly like a mailbox with nothing to send. Tenants hit their own ceilings: user counts, domain counts, licence counts, each with a different error message. Domains burn and need replacing, which means new DNS, new warm-up and a three-week wait unless you bought ahead.

None of this is difficult. All of it is recurring, and almost all of it fails silently. The reason we built the platform around one approval and an audit trail is that every incident we have had in production was something recorded but never surfaced: a record written and never verified, a token refreshed and never re-checked, a warm-up paused and never resumed. If you run this by hand, build the checks before you build the fleet.