Cold email infrastructure checklist before launch

A cold email launch usually breaks in the quiet parts of the setup: one client domain has a missing DKIM selector, another mailbox is pointed at the wrong MX records, a tracking CNAME resolves but the SSL certificate fails, or a new domain is already carrying blacklist history.

The painful moment comes after the campaign goes live. Replies are low, bounces are high, and the agency has to explain a deliverability problem it could have caught before launch.

Use this checklist before a client workspace moves from setup to sending.

The launch-ready standard

A cold email setup is not ready just because the sending tool says the inbox is connected. Before launch, every sending domain, inbox, and tracking domain should have a written verdict:

• Ready: the asset can go into launch rotation.
• Needs Fix: the setup has a specific issue that should be corrected before volume starts.
• Do Not Launch: the issue is severe enough to block the campaign.

That verdict matters because agencies rarely launch one inbox at a time. They launch batches of client domains, inboxes, aliases, and tracking domains, and one broken asset can damage the whole rollout.

1. Confirm the domain is fit for outbound

Start with the domain itself, before you inspect individual DNS records.

Check:

• The domain resolves consistently.
• The domain is not parked, expired, or newly transferred in a way that creates DNS instability.
• The domain age fits your risk tolerance for the campaign.
• The root domain and common subdomains do not redirect to suspicious or irrelevant destinations.
• The domain is not already associated with an obvious spam history.

OutboundQA check: domain readiness, DNS resolution, domain age, and launch-risk classification.

Fast manual starting point: run the domain through the cold email domain checker before you spend time configuring the rest of the workspace.

2. Verify MX records and receiving mail

Every sending domain needs reliable receiving infrastructure. If prospects reply and mail cannot route back to the client inbox, the campaign fails even if outbound delivery works.

Check:

• MX records exist.
• The MX hostnames resolve.
• The MX provider matches the mailbox provider you expect.
• There are no stale records from a previous provider.
• The domain can receive mail at the intended inboxes.

OutboundQA check: MX presence, MX resolution, provider mismatch risk, and client-facing status.

Manual check: use the MX record checker for a quick DNS read.

3. Validate SPF without exceeding DNS limits

SPF tells receivers which services are allowed to send on behalf of the domain. Cold email stacks often break SPF by adding every tool, CRM, help desk, and legacy include into one record.

Check:

• Exactly one SPF TXT record exists at the root domain.
• The record includes the active sending provider.
• The record does not include stale providers.
• The record stays under the 10 DNS lookup limit.
• The syntax is valid and ends with an intentional policy.

OutboundQA check: SPF presence, duplicate-record detection, syntax, lookup count risk, and provider alignment.

Manual check: run the domain through the SPF checker.

4. Confirm DKIM for every sender

DKIM is where many launches pass a surface check but still fail in practice. The sending tool may show a selector, but the DNS record may be missing, copied to the wrong host, or published with a malformed key.

Check:

• DKIM is enabled in the sender.
• The selector published in DNS matches the selector in the sending tool.
• The public key resolves.
• The record has not been split, escaped, or pasted incorrectly.
• Each active sending provider has its expected DKIM record.

OutboundQA check: DKIM selector availability, DNS resolution, malformed key risk, and provider-by-provider coverage.

Manual check: use the SPF/DKIM/DMARC checker when you want an authentication snapshot in one pass.

5. Publish DMARC with a deliberate policy

DMARC ties SPF and DKIM together and gives receivers a policy for failed mail. For cold email, a missing DMARC record is now a launch blocker, especially when sending to Google and Yahoo recipients.

Check:

• A DMARC record exists at _dmarc.yourdomain.
• The policy is intentional, not an accidental default.
• Reporting addresses are valid if rua or ruf tags are used.
• Alignment is understood for the sender setup.
• The policy does not conflict with how the domain is being used.

OutboundQA check: DMARC presence, syntax, policy strength, reporting configuration, and launch recommendation.

Manual check: run the record through the DMARC checker.

6. Check tracking domain DNS and SSL

Tracking domains are easy to overlook because they sit outside the basic mailbox connection flow. A tracking CNAME can resolve while SSL is broken, misissued, or pointed at the wrong host.

Check:

• The tracking subdomain is unique to the client or workspace.
• The CNAME points to the expected provider.
• The destination resolves.
• HTTPS works without certificate warnings.
• The tracking domain does not redirect through unrelated infrastructure.

OutboundQA check: tracking CNAME, host resolution, SSL validity, and launch-blocking certificate failures.

This is one of the main reasons a single-record checker is not enough. Authentication can look clean while link tracking breaks reputation or click routing on day one.

7. Review blacklist and reputation risk

Blacklist status can change quickly, and reused domains can arrive with problems already attached. Check it before launch, then re-check during the first two weeks of sending.

Check:

• The sending domain is not listed on major domain blacklists.
• Related IPs are not listed on major IP blacklists.
• Link and tracking domains are not listed on URL-focused lists.
• Any listing has a clear remediation path before launch.
• The client understands when replacing the domain is safer than trying to recover it.

OutboundQA check: blacklist risk, severity classification, and fix guidance.

Useful background: read the guide on why cold email domains land on blacklists.

8. Match the setup to Google and Yahoo sender rules

Google and Yahoo sender requirements changed the baseline for legitimate outbound. Even if a client is not a bulk newsletter sender, these rules influence how mailbox providers evaluate authentication and complaint risk.

Check:

• SPF or DKIM authenticates outbound mail.
• DMARC exists for the domain.
• The visible From domain aligns with authentication.
• Unsubscribe handling is clear for campaign type and tooling.
• Complaint rate and bounce controls are part of the launch plan.

OutboundQA check: sender-requirement readiness and launch notes for client signoff.

Useful background: the DMARC for cold email guide explains the authentication side in more detail.

9. Document the client-ready verdict

The final step is not another DNS lookup. It is packaging the result so the agency, strategist, and client know exactly what can launch.

Your signoff should include:

• The domains, inboxes, and tracking domains checked.
• A Ready, Needs Fix, or Do Not Launch verdict for each asset.
• The exact broken record, missing selector, or provider mismatch.
• The recommended fix in plain language.
• A timestamped record of what was checked before campaign launch.

OutboundQA check: client-ready report generation with asset-level verdicts and fix notes.

See the client-ready deliverability report template or the sample launch QA report for the format to hand to a team or client.

Pre-launch checklist template

Copy this into your launch process and require every row to be resolved before sending starts.

Area	Launch question	Pass condition
Domain readiness	Is the domain stable and appropriate for outbound?	Domain resolves, has no obvious launch-risk history, and is not expired or parked
MX	Can replies route to the right mailbox provider?	MX exists, resolves, and matches the intended inbox provider
SPF	Is the sender authorized without DNS-limit risk?	One valid SPF record, active sender included, under 10 lookups
DKIM	Can receivers verify signed mail?	Correct selector published and resolving for every active sender
DMARC	Does the domain publish a receiver policy?	Valid DMARC record exists with an intentional policy
Tracking	Will click tracking resolve securely?	CNAME points correctly and HTTPS certificate is valid
Blacklists	Is the launch blocked by reputation history?	No severe domain, IP, or URL listing remains unresolved
Sender rules	Does the setup meet modern mailbox expectations?	Authentication, alignment, unsubscribe handling, and complaint controls are addressed
Report	Can the agency prove what was checked?	Asset-level verdicts and fixes are documented before launch

What a checklist still misses

A checklist is only useful if someone runs it consistently across every asset. That is where manual launch QA gets fragile. One client may have three domains; another may have twenty inboxes, two tracking domains, and records split across several DNS providers.

The risk is not that the agency does not know SPF, DKIM, DMARC, MX, tracking, or blacklists matter. The risk is that one asset is skipped, one warning is misread, or one fix never makes it back into the client handoff.

OutboundQA turns the checklist into a pre-flight report: upload the client assets, get a launch verdict for each one, and share a report with the exact fixes before the campaign goes live.

Run the first pass with the cold email domain checker, use the client-ready deliverability report template, or review the sample report if you need a finished signoff format.