Cold email setup: build the stack in the right order

A cold-email setup should not start with a sequencer login.

Start with the campaign assumptions and ownership. Then build domains, mailboxes, authentication, data acceptance, connections, and measurement in that order. Each layer should leave evidence for the next one.

Otherwise, the first campaign becomes the setup test—and every bad result turns into a guess about which layer failed.

The dependency map

Buying every component does not mean the system is ready. The handoffs make it ready.

Give every stage an entry, exit, and rollback

The dependency map becomes useful when each row has a gate.

An exit gate is evidence, not “done” in somebody's task list. A rollback condition is not a prediction of failure. It is the point where the team stops adding complexity and returns to the last known-good layer.

Do not buy the next layer early

Several purchases feel productive before the earlier decision is ready:

• buying domains before deciding ownership and isolation;
• ordering mailboxes before assigning each domain;
• connecting a sequencer before SPF, DKIM, and DMARC are verified on a real message;
• importing a large list before suppression and acceptance rules exist;
• enabling open and click tracking before deciding whether those signals will drive an action;
• increasing volume before the team can explain the current batch.

Delay is frustrating. Rework is worse. The setup should make later changes boring instead of turning every tool into a dependency nobody can remove.

1. Write down the campaign assumptions

The infrastructure cannot be sized from “we want to scale.” It needs inputs.

Record:

• target audience and geography;
• number of new contacts in the first campaign;
• number and timing of follow-ups;
• expected campaign days;
• whether separate clients or business units need isolation;
• preferred Google or Microsoft mailbox mix;
• who owns domains, DNS, mailboxes, data, campaigns, and replies;
• what event pauses the launch.

Do not treat a provider's maximum sending limit as a cold-email recommendation. Google and Microsoft publish service boundaries and enforce their own policies. Your operating plan still has to fit the recipients, message, account history, and risk controls.

The inbox calculator can turn your assumptions into an infrastructure estimate. It is an estimate, not a fixed promise about sending behavior or campaign results.

Use a planning range, not one magic number

Campaign assumptions change. Build a base case and a high case.

new contacts per campaign day:
follow-up steps:
campaign days per week:
separate clients or business units:
mailbox provider preference:
domain/workspace isolation rule:
spare capacity required for maintenance:

Run the calculator with both cases and record the inputs beside the output. If the estimate changes, the team should be able to point to the changed assumption instead of saying the calculator was wrong.

Keep provider service limits separate from your planning assumptions. A documented maximum is a boundary enforced by the service, not proof that the account, domain, recipient mix, or campaign should operate at that level.

2. Give every domain one job

For each domain, record whether it is used for a public website, cold-email sending, replies, redirects, or tracking. Avoid letting one hostname quietly accumulate several roles because different tools were connected on different days.

Use a domain register:

Cheap Inboxes supports domain purchase and import workflows. Keep ownership and renewal evidence in your own operating record regardless of where the domain was acquired.

Separate domains by the failure you can tolerate

Isolation is an operations decision. Ask what should remain unaffected if one domain needs to pause, move, expire, or be handed back.

Possible boundaries include:

• client;
• business unit;
• brand;
• campaign type;
• mailbox provider;
• region;
• test versus production work.

Do not create a new domain for every spreadsheet row. Do not put unrelated work on one domain because it is easier to buy. Choose a rule that an operator can apply repeatedly and explain during offboarding.

For every domain, test the exit path before it becomes important. Confirm who can access the registrar, nameservers, billing method, renewal controls, and recovery contact. An imported domain should not become functionally trapped because the DNS owner disappeared.

3. Choose the mailbox model

Standard Google Workspace and Microsoft 365 mailboxes use the underlying Google and Microsoft transport. The infrastructure vendor does not create a secret third transport layer for those accounts.

The vendor still matters for the operating work around the service:

• workspace or tenant structure;
• domain assignment;
• account provisioning and administration;
• DNS coordination;
• billing and renewal clarity;
• support when a human needs to trace an issue;
• handoff and exit.

Cheap Inboxes supports Google and Microsoft mailboxes and uses a one-domain-per-workspace structure. That structure is an isolation and operations choice. It is not proof that Google or Microsoft will place messages differently.

For every mailbox, store the provider, workspace, domain, user, owner, recovery path, assigned campaign, and status. A spreadsheet of usernames and passwords is not enough.

Verify the mailbox order against the operating record

When the order arrives, compare what was received with what was planned:

If the account model or access differs from what was ordered, stop before connecting campaigns. A working login is not acceptance if the ownership or provider model is wrong.

Keep credentials in an appropriate credential system, not in the handoff sheet. The operating record should say who owns access and where the approved recovery process lives without exposing the secret itself.

4. Authenticate the real path

List every source that sends as the domain. Then configure:

• one SPF policy for the active MAIL FROM sources;
• DKIM signing for the mailbox provider and any other legitimate sender;
• DMARC reporting and a deliberate policy path;
• forwarding or reply records required by the workflow;
• tracking-domain records only from the selected sequencer's current documentation.

Send a message through the real path to an external recipient. Preserve the headers and confirm SPF, DKIM, DMARC, and alignment. A green DNS checker does not prove that the real campaign uses the expected domains.

Use the provider-aware authentication guide for the full check.

Preserve the before-and-after message

For each domain, keep at least one received-message sample from the real route after configuration. Record the visible From, Return-Path, DKIM signing domain, SPF/DKIM/DMARC results, recipient provider, and timestamp.

When a DNS or connection change is made later, capture a new sample. The comparison is stronger than a screenshot of a green DNS tool because it proves which identities the message actually used.

If a tracking domain is enabled, document it separately from authentication. A tracking CNAME cannot repair a broken SPF, DKIM, or DMARC path.

5. Define which data can enter a campaign

An address reaching the sequencer should already have:

• source and acquisition date;
• verification result and date;
• suppression history;
• duplicate handling;
• segment and campaign fit;
• a named decision owner.

The mailbox layer does not clean a list. The sequencer does not make the targeting correct. Preserve the data decision before importing the file.

Create one acceptance action

The import should not contain three verification columns and no decision.

Map the evidence into one owned action:

Keep the reason, date, and owner. The sequencer imports the accepted segment; it does not decide what unknown means for the business.

6. Connect the sequencer without hiding ownership

Use the selected sequencer's current connection instructions. Record:

• mailbox and provider;
• connection method;
• connected account identifier;
• campaign assignment;
• reply and forwarding path;
• tracking choice;
• who can revoke or reconnect the account;
• error and restriction evidence;
• last verification date.

Exact connection paths vary by platform. Do not copy a setup screen from one sequencer into another, and do not assume a feature exists because a logo appears on a marketing page.

CheapSequencer is a separate sending product. It is not bundled into Cheap Inboxes, and the infrastructure setup should still make sense if the sequencer changes later.

Run four connection tests

Do more than authenticate the account.

1. Send: deliver an internal test through the real campaign path and preserve the provider result.
2. Reply: send a reply and confirm the correct workspace, owner, and stop-on-reply behavior.
3. Fail: create or capture a safe test error and confirm the operator can see the exact state instead of a generic failure.
4. Remove: disconnect one test mailbox and verify campaign, credential, billing, and inventory consequences.

The removal test matters. A workflow that connects quickly but cannot be cleanly revoked or reassigned will create problems during a client handoff or provider change.

7. Build measurement before the first send

Every result needs enough identifiers to trace the path:

campaign_id
client_or_business_unit
list_source
segment
sending_domain
mailbox
mailbox_provider
workspace_or_tenant
sequencer
copy_version
tracking_state
sent_at
provider_response
bounce_class
reply_class

That record makes the cold email deliverability diagnostic possible. Without it, a drop in replies becomes a debate about tools instead of a scoped investigation.

Decide which system owns each event

The sequencer may own campaign and step state. Google or Microsoft may own provider errors and restrictions. A verifier owns its dated classification. The infrastructure record owns domains, workspaces, and mailbox assignment.

Write the source of truth beside every field. Do not copy several dashboards into one table and assume the newest value is correct. If two systems disagree, keep the conflict and investigate which layer owns the fact.

For example, a sequencer can show an attempted send while the provider returns a restriction. Those are two different events. Preserve both.

8. Launch in a stage you can stop

Start with a small, representative batch. Pick a review window before launch and define the stop conditions.

Pause and inspect when:

• authentication fails;
• a mailbox is restricted or disabled;
• connection errors repeat;
• hard bounces cluster by source;
• replies or negative responses expose a targeting problem;
• the actual schedule differs from the plan;
• identifiers are missing from the evidence record.

Do not increase scope until the team can explain the current result. “The dashboard looks fine” is not an acceptance gate.

Use a staged launch review

Pick the review moment before the first send. The team should know who pauses the campaign and what evidence they need.

If one row is inconclusive, keep the next stage small. “No alert appeared” is not the same as verified acceptance.

A worked handoff example

Imagine a team preparing one new outbound campaign for one business unit.

The planning record says which market is in scope, how many new contacts enter each campaign day, which follow-ups are planned, and what stops the launch. Two dedicated sending domains are registered under the organization account. Each domain is assigned to its own workspace under the chosen provider model. Every mailbox is named, inventoried, and tied to a campaign role.

The DNS owner inventories Google or Microsoft plus any other legitimate sender. A real external message proves the intended SPF or DKIM alignment and DMARC result. The data owner exports only rows with a current acceptance action and preserved suppression history. The campaign operator connects a small mailbox group, tests send/reply/fail/remove behavior, and confirms the event fields.

The first stage runs with a review window and written stop rules. If a bounce cluster follows one list source, the team pauses that source without replacing every mailbox. If one account shows a provider restriction, it isolates the account and checks the provider state. If a tracking redirect breaks, it rolls back the tracking record without rewriting authentication.

That is the point of the order. Every symptom has a smaller place to start.

Assign owners before launch day

One person can hold several roles on a small team. The roles still need names.

The handoff should say who can change the system, not only who can view it. If the DNS owner notices a reply decline, that does not authorize an untracked campaign change. If the campaign owner sees an authentication error, it should know who can inspect the record without sharing credentials in chat.

For an agency, add the client decision owner and offboarding owner. Clarify which assets belong to the client, which accounts the agency administers, who pays renewals, and what is returned or disconnected at the end of the engagement.

Review the setup after it becomes ordinary

The first launch receives attention. The fifth one exposes whether the process is repeatable.

Run a short recurring review:

• domains nearing renewal or missing a recovery owner;
• workspaces with unclear admin ownership;
• mailboxes without a current campaign or status;
• DNS records whose source or owner is no longer known;
• verification and suppression rules that changed without versioning;
• sequencer connections with repeated errors or unknown revocation paths;
• tracking hostnames with certificate or redirect failures;
• campaigns whose evidence cannot be traced across list, domain, mailbox, and provider.

Retire unused infrastructure deliberately. Disconnect the sequencer, preserve required campaign evidence, cancel the correct billing unit, remove or update DNS records, decide whether the domain renews, and record the final owner. An abandoned domain or mailbox is not spare capacity if nobody knows whether it can still be used.

The setup is to spec when a new operator can follow the records, run the tests, and explain where to start when something breaks. If that knowledge only exists in the person who assembled the tools, the handoff is not finished.

Put every later change through the same gates. A new list source goes back through data acceptance. A new sequencer repeats connection and removal tests. A new sending service updates the sender inventory and authentication evidence. A new domain receives an owner before it receives DNS records.

That discipline is slower than clicking “connect” once. It is much faster than rebuilding the system during a client launch or provider restriction. The goal is not a stack that never changes. It is a stack that can change without losing ownership or evidence.

Call the setup complete only when a second operator can locate every owner, reproduce the real-message test, trace one accepted contact into a campaign, explain one provider failure, pause the correct layer, and run the documented exit path. If any of those depend on private memory, the system is still being assembled.

Keep that second-operator test in the launch review instead of assuming the handoff document is clear because its author understands it.

Run it without the original builder in the room. Questions are evidence that the handoff still needs work.

The final handoff

The finished setup should leave one packet with:

• campaign assumptions;
• domain register;
• mailbox and workspace register;
• DNS records and sources;
• received-message authentication evidence;
• data acceptance rules;
• sequencer connection record;
• measurement fields;
• launch date, owner, and stop conditions;
• support and escalation path.

That packet is the setup. The tools are only the parts.

Sources

• Google email sender guidelines
• Microsoft outbound spam protection
• Cheap Inboxes developer overview
• Cheap Inboxes API specification