Cold email infrastructure: what to build, buy, and own

A cold email system is not one tool. It is a chain of domains, DNS records, mailbox accounts, sending software, data, people, and handoffs.

If one person owns the domain, another buys the inboxes, and a third connects the sequencer, the system can look ready while nobody can answer a basic question: who fixes it when replies stop or an account needs attention?

Map the infrastructure first. Then decide what your team should own, what a provider should operate, and what still has to be tested before a campaign goes live.

The cold email infrastructure map

Start with the actual path a message takes.

These layers affect each other, but they are not interchangeable. A sequencer cannot repair a bad DNS record. A warmup dashboard cannot tell you whether the wrong list was uploaded. A mailbox supplier cannot control the quality of your targeting or copy.

That separation is useful. It keeps a problem in one layer from turning into a full-stack rebuild.

What to build, buy, and own

There is no prize for building every piece yourself. There is also no reason to hand away control of an asset your team may need to recover later.

Use this split as the default.

The operating rule is simple: buy repetitive execution; keep enough access and documentation to audit, change, or leave.

Build the rules that are specific to your business

Your team should define:

• how domains are named and separated;
• which client, campaign, or offer uses each domain;
• who approves mailbox counts and later changes;
• where credentials and recovery information live;
• what evidence is required before launch;
• when an inbox, domain, or campaign is paused;
• how a batch moves from infrastructure to campaign operations.

A provider can help execute those rules. It should not be the only place the rules exist.

Buy work that repeats

Mailbox ordering, DNS setup, account creation, bulk actions, and support are good candidates for a service because the work repeats across domains and batches.

Cheap Inboxes supports Google and Microsoft mailboxes, new or imported domains, DNS and authentication management, and documented developer workflows through its API, MCP-compatible interface, and webhooks. Each workspace uses one domain. Those capabilities remove operating work; they do not remove your need for a capacity plan, an owner, or a launch test.

Own the exit path

Before an order is large enough to hurt, test what happens when you need to:

• recover registrar or administrator access;
• change a DNS record;
• disconnect a mailbox from the sequencer;
• cancel a mailbox or workspace;
• export the records your team needs;
• move responsibility from one operator to another.

An exit path is not pessimism. It is part of knowing what you bought.

Calculate capacity from the campaign, not a round number

“We need 100 inboxes” is not a capacity plan.

Work backward from the campaign:

1. How many new contacts will enter each day?
2. How many messages can one contact receive across the sequence?
3. How many active sending days are in the month?
4. What daily operating volume will you use per mailbox?
5. How much spare capacity do you need for pauses, changes, and uneven volume?

The inbox calculator can turn those inputs into an estimate. Treat the result as a planning number, not a promise about placement or a universal sending limit.

Then decide how to distribute that capacity.

• Keep outbound activity away from the primary company domain.
• Use a domain and workspace structure your team can explain.
• Avoid putting the entire program behind one credential or one undocumented owner.
• Leave room for operational changes instead of running every asset at its planned maximum.

Provider limits are also not campaign recommendations. Google and Microsoft publish product restrictions and sender requirements. Those documents describe what their systems allow or expect; they do not tell you that a particular cold email volume is appropriate for your audience, domain, or account.

Domain ownership comes before DNS

Teams often start with SPF and DKIM because those records are visible. The first question should be more basic: who controls the domain?

For every sending domain, record:

• registrar;
• registrant or account owner;
• renewal date and payment owner;
• authoritative nameservers;
• recovery email and recovery procedure;
• workspace or tenant assignment;
• client, brand, and campaign assignment;
• offboarding or transfer path.

If the provider registers the domain, ask what access you receive and how a transfer works. If you import a domain, document which records the provider needs to manage and which remain under your control.

Cheap Inboxes can register domains or import domains you already own. That distinction should be explicit in the order record because the recovery and exit steps are different.

DNS is a maintained system

SPF, DKIM, and DMARC are not three badges to collect. They authenticate different parts of the message path and need to be checked against the provider actually sending mail.

Read how SPF, DKIM, and DMARC work together before treating a green DNS checker as final evidence. A record can exist and still be wrong for the message path you are using.

Keep a change log. At minimum, capture the domain, record, old value, new value, reason, owner, timestamp, and verification result. That record becomes useful the first time a client changes nameservers or another tool asks for a conflicting SPF include.

The mailbox provider and the inbox supplier are different decisions

Google Workspace and Microsoft 365 operate the underlying mailbox systems. A cold email inbox supplier changes the commercial and operating layer around those accounts.

That layer can change:

• domain and workspace structure;
• admin and recovery access;
• mailbox ordering and later expansion;
• DNS setup and support;
• billing terms and renewal behavior;
• sequencer handoff;
• developer controls;
• cancellation and disconnection workflows.

It does not turn standard Google or Microsoft transport into a different network just because the reseller uses stronger marketing language.

Compare like with like. A standard Google mailbox, an Azure/Entra offer, a shared SMTP product, and dedicated sending infrastructure may all appear in the same search results. They are different architectures with different owners, limits, and failure modes.

The launch acceptance test

Do not approve a batch because the order screen says complete. Approve it when the real path works.

Use one domain and a small group of inboxes for the acceptance test.

Access

• The registrar and nameserver owner are recorded.
• The mailbox admin or recovery path is recorded.
• Credentials are stored in the approved location.
• The people who need access can actually use it.

DNS and mail flow

• MX, SPF, DKIM, and DMARC resolve from the authoritative DNS.
• A real outbound message produces the expected authentication results.
• A real reply reaches the intended owner or forwarding destination.
• The team knows who changes DNS if the result is wrong.

Sequencer handoff

• The mailbox connects through the promised method.
• A test campaign can send, receive, and attribute a reply.
• The disconnect path is documented.
• The operator knows which system owns schedules, suppression, and replies.

Commercial and support check

• Mailbox, domain, software, and add-on costs are separated.
• Billing cadence and renewal behavior are written down.
• A later mailbox addition is tested or documented.
• Support answers one specific operating question using the route you will use after launch.

Evidence packet

The handoff should include:

• domain and mailbox inventory;
• provider and workspace assignment;
• DNS verification evidence;
• sequencer destination and connection owner;
• launch date and campaign owner;
• known limitations or unfinished work;
• support and escalation route;
• cancellation, disconnect, and transfer notes.

The campaign operator should not have to reconstruct this from order receipts and chat messages.

What the handoff looks like

Use one record per batch, not one vague message saying “the inboxes are ready.”

The handoff has one goal: make the next owner capable of operating the system without guessing.

Lifecycle work starts after launch

Most infrastructure articles end at setup. The expensive mistakes happen later.

Create recurring checks for:

• domain renewal and payment failures;
• administrator and recovery access;
• authentication changes;
• mailbox-to-campaign assignments;
• connection errors and reply routing;
• provider notices or restrictions;
• capacity changes;
• paused, unused, or canceled assets;
• client or employee offboarding.

When something fails, preserve evidence before changing everything. Capture the affected domain and inbox, provider, timestamp, error text, message headers when relevant, recent changes, and scope. Change one layer at a time, then retest the same path.

The minimum operating model

You do not need a complicated system. You need named owners and proof.

Before launch, somebody must own each of these decisions:

1. Capacity and domain plan.
2. Registrar and DNS access.
3. Mailbox order and billing.
4. Authentication verification.
5. Sequencer connection.
6. Campaign launch.
7. Monitoring and pause decisions.
8. Support escalation.
9. Cancellation and offboarding.

If the same person owns all nine, write it down anyway. The system should survive that person being unavailable.

Build the rules that are specific to your operation. Buy the repetitive setup and administration. Keep ownership of the evidence and the exit path. That is what makes cold email infrastructure manageable after the first campaign goes live.

Sources

• Google email sender guidelines
• Google Workspace SPF setup
• Google Workspace DKIM setup
• Google Workspace DMARC setup
• Microsoft Exchange Online limits
• Microsoft outbound spam protection
• Cheap Inboxes developer overview