Domains and mailboxes — the procurement and setup reference.
The cold email infrastructure reference (the protocol layer) presupposes a sending estate already exists. This reference is the layer underneath — the actual procurement of domains, the selection of registrars, the choice of DNS hosting, the mailbox-provider economics, and the operational workflow of wiring it all together before a single message is sent.
Seven chapters. The case for separate sending domains, TLD and naming selection, registrar tradeoffs, the buying workflow, DNS hosting, the Google Workspace vs Microsoft 365 vs other-provider decision, and the multi-mailbox-per-domain configuration that bridges into the authentication layer.
A working multi-domain sending estate for a typical 30-rep SDR team requires approximately 30-40 registered domains, 90-120 mailboxes across those domains, two DNS providers (one for sending domains, one for the corporate domain), one or two mailbox providers, and 25-40 hours of operator time to provision before warmup can begin. The unit economics are roughly $1,200-2,800 per month in standing infrastructure cost. Most operators discover this scope late, after attempting to run cold outbound from a single corporate mailbox and burning the domain in week three.
Layer one — what to buy.
Selection decisions cascade. The domain name shapes registrar choice; the registrar shapes DNS choice; DNS shapes the authentication record set. Read in order.
Why buy separate sending domains
The cost-and-risk asymmetry between sending cold outbound from the corporate domain and registering separate sending domains, and the per-domain inbox-count math that determines how many domains the operation actually needs.
Domain selection — TLDs and naming
The empirical TLD reputation differential (.com vs .co vs .io vs .net), the brand-adjacent naming pattern (try{brand}, use{brand}, get{brand}), trademark considerations, and the pattern-matching risk when 30 sending domains share an obvious naming convention.
Registrar selection
The categories that meaningfully differ across registrars (privacy posture, DNSSEC support, bulk-registration tooling, API access, renewal pricing), the categories that don't, and the practical effect of registrar choice on reputation at major mailbox providers.
Layer two — how to buy.
The actual procurement workflow. The step-by-step that turns “we need 30 domains” into 30 registered domains with DNS configured and ready for the authentication layer.
The buying workflow
The step-by-step of registering 30 domains in a single sitting without triggering anti-bulk-registration heuristics, the registrant-entity decision, privacy-protection configuration, and the timeline from purchase to DNS-propagation-complete.
DNS hosting choices
The tradeoffs between using the registrar's bundled DNS and migrating to a dedicated DNS provider, the operational lift of managing 30+ zones across a dedicated provider, and the reputation signal of the DNS provider itself.
Layer three — the mailbox layer.
The provider decision that determines per-mailbox cost, the feature set available at the SMTP layer, and the operational ceiling on per-account sending volume.
Mailbox provider selection
The empirical comparison of Google Workspace, Microsoft 365, and other mailbox providers for cold sending: per-mailbox cost, sending-volume caps, deliverability reputation differential at major receivers, admin tooling depth, and the patterns of operator migration between the two.
Multi-mailbox setup and handoff
The operational pattern of provisioning 2-3 mailboxes per domain across 30+ domains, the SMTP-versus-API integration decision, the bulk-creation tooling, and the handoff to the authentication-record configuration of the cold email infrastructure reference.
The end-to-end procurement and setup of a 30-domain, 90-mailbox sending estate is 25 to 40 hours of operator time, plus the standing infrastructure cost.
Allston Labs runs the procurement, DNS configuration, mailbox provisioning, and authentication wiring end-to-end. The domains and mailboxes are registered under your entity. The engineer on call lives in your Slack.