Cold email infrastructure checklist for B2B teams
Before buying domains, mailboxes or a sequencer, agree how the system will be owned, what its providers allow and what must work before anyone sends. Use this checklist to turn a proposed setup into decisions you can verify.
- What does a cold email setup need?
- A suitable sending service, clear sender identity, working authentication, controlled access, clean audience data, reliable reply handling and enforceable stop conditions. A connected mailbox alone does not establish that the setup is appropriate or ready to launch.
1. Decide whether the planned sending belongs on the provider
Write down the audience, how the addresses were obtained, the message purpose, countries involved and expected sending pattern. Assign responsibility for the applicable marketing rules and the provider’s terms before selecting accounts. Technical capacity is not permission to use a service for every type of outreach.
Microsoft says bulk sending is not a supported use of Microsoft 365 (opens in a new tab) and is handled on a best-effort basis. Google documents Workspace sending limits and restrictions (opens in a new tab). A published maximum is not a recommended prospecting target or assurance that a campaign is acceptable.
Acceptance check: the person choosing the provider can explain how the planned activity fits its current terms and controls. If the answer depends on adding accounts to evade restrictions, pause the design. The solution may be a different channel or a different audience approach.
2. Check ownership before paying for the stack
| Decision | Evidence to request | Reason to pause |
|---|---|---|
| Who controls the domains? | Registrar account, renewal contact and recovery process owned by your organisation. | The supplier owns the only login or cannot explain how transfer works. |
| Who administers the mailboxes? | Named administrators, suitable authentication controls and a documented access-removal process. | A shared password is the entire security model. |
| Who owns the sequencer and data? | Account ownership, export options, user roles and the destination of replies and suppression records. | Leaving the supplier would strand active conversations or opt-outs. |
| What costs continue after setup? | An itemised list of recurring subscriptions, renewal dates and which party approves them. | The proposal describes only a setup charge and leaves dependencies unspecified. |
3. Map the identity and route before changing DNS
Draw the route from the sending application to the mailbox provider and recipient. Record the visible From address, reply destination, signing domain and any tracking domain. If a system sends through its own network, include that route separately from mail sent through a connected inbox.
Agree which traffic should be separated from everyday business email and why. A dedicated sending domain is not a reputation firewall. The identity must remain understandable to recipients, and separation does not make unwanted messages acceptable.
Acceptance check: an administrator can name each legitimate sender and show which configuration applies to it. Test a message through the actual application and inspect its received authentication results. A DNS dashboard showing records exist does not prove that the application signs messages correctly.
For an existing setup with unexplained failures, start with the email deliverability audit checklist before replacing infrastructure.
4. Make audience controls and replies part of the build
A launch checklist should cover what happens after a contact is imported and after a person replies.
Before a contact enters a sequence
- Check duplicates against the agreed CRM identity rules, not just the latest upload.
- Apply opt-outs, known bounces, existing-customer exclusions and open-conversation rules before scheduling.
- Record the source and reason for inclusion. Address validation does not establish permission or relevance.
- Decide which system is authoritative when the CRM and sequencer disagree.
After a response arrives
- Route the original thread to a named owner with cover for absence.
- Stop further automated follow-ups when a real conversation starts.
- Ensure opt-outs reach every connected sending process that uses the contact.
- Test out-of-office replies, referrals and replies from an alias rather than assuming every reply is interest.
5. Agree which tracking you actually need
Document links, redirects, tracking domains and open tracking before launch. Make sure the owner can explain their purpose and remove them for a controlled comparison if a delivery investigation requires it. Do not change several variables at once and then claim to know which one caused the result.
Define the commercial measures first: unique prospects contacted, human replies, interested conversations and accepted opportunities. Opens are not proof that a person read the message, and a delivered status does not establish inbox placement. Our delivery-status guide explains that distinction.
Acceptance check: a report can be reconciled with identifiable events and a defined period. It does not quietly mix sends, recipients, automatic replies and meetings into one success rate.
6. Run acceptance checks before launch
| Test | Expected result | Keep as evidence |
|---|---|---|
| Send through each planned route | The intended identity and authentication appear on the received message. | Message ID, route, timestamp and received results. |
| Reply with a genuine question | The thread reaches its owner and subsequent automated follow-ups stop. | Owner assignment and cancellation of the scheduled step. |
| Send an opt-out | The agreed suppression process completes and a fresh import cannot re-enrol the contact. | Suppression state checked in the relevant systems. |
| Repeat an integration event | The same event does not create duplicate tasks or actions. | Event reference and the resulting single record. |
| Disconnect an integration | A visible alert reaches an owner, with unsafe dependent activity paused where designed. | Alert, pause state and documented recovery procedure. |
7. Approve the handover and operating plan
The handover should identify account owners, sending routes, configuration decisions, test results, routine checks and the person authorised to pause sending. Record outstanding issues explicitly. A successful demonstration does not close an untested dependency.
Agree a controlled launch with review points and stop conditions tied to provider warnings, unusual bounces, complaints and failed reply handling. Avoid a fixed promise that a domain age or warm-up score makes any sending pattern safe.
Neotiqa can scope and implement outbound infrastructure in your accounts, with documentation and an agreed handover. If you also need campaign operation, managed outreach is a separate scope. For the hand-off after a reply, use our reply-handling guide.
Questions before buying an outbound setup
How many domains and mailboxes should we buy?
Start with provider fit, audience, expected activity and operating capacity. There is no universal mailbox count that makes a campaign suitable. Buy only the components justified by the design and its constraints.
Does a separate domain fully protect our main domain?
No. Separating traffic can make ownership and controls clearer, but it does not remove reputation risk or guarantee inbox placement. Recipients must still be able to identify the business behind the message.
Can we use this checklist for a supplier handover?
Yes. Ask the supplier to show the evidence behind each applicable check and identify anything that remains untested. Agree the actual acceptance criteria in your written scope.
Know what you need before buying the stack.
Tell us what you already use, who you intend to contact and where the setup is unclear. We can scope the architecture, implementation and handover.