Cold email pre-launch checklist for agencies

A cold email launch rarely fails because nobody knew SPF, DKIM, DMARC, MX records, tracking domains, or blacklists mattered. It fails because the final launch pass happens under deadline pressure.

One operator assumes the sender status screen is enough. Another operator fixes a DNS record but never reruns the check. A client swaps mailbox providers two days before launch. The campaign goes live, replies are low, bounces climb, and the team has to reconstruct what was checked after the fact.

Use this cold email pre-launch checklist as the last gate before a campaign starts sending. It is built for agencies that need one practical pass across domains, inboxes, tracking domains, list hygiene, sending controls, and client-ready signoff.

If you only need a fast technical read on one domain, start with the cold email domain checker. If you need a reusable planning aid, use the cold email launch checklist generator.

The launch gate

Before volume starts, every client workspace should have a clear launch gate:

Status	Meaning	Launch decision
Ready	The asset passed the required checks	Include it in the launch plan
Needs Fix	The asset has a specific issue to resolve	Fix and rerun before launch
Do Not Launch	The asset has a launch blocker	Remove it or hold the campaign

Do not replace this with “looks fine” or “sender says connected.” A cold email checklist should produce a decision that the operator, account manager, and client can understand.

OutboundQA maps this to asset-level verdicts across Domain + Email + Links checks: domains, inboxes, authentication, tracking domains, blacklist signals, sender requirements, and the client-ready report.

1. Lock the launch scope

Start by defining what is actually going live. This prevents the most common agency mistake: checking the obvious domain and missing the assets that were added late.

Confirm:

• Client or workspace name.
• Launch date and owner.
• Sending platform.
• Sending domains.
• Inboxes or aliases.
• Tracking domains.
• SMTP egress paths or custom sending IPs, if used.
• DNS owner and escalation contact.
• Client approver for launch signoff.

OutboundQA check: roster import, asset normalization, duplicate detection, and workspace-level launch scope. Agencies managing several clients can use multi-client cold email QA to define the ownership and evidence needed across workspaces.

Checklist row:

Item	Owner	Status	Notes
Launch roster is complete	Ops lead	Ready / Needs Fix / Do Not Launch	Include every domain, inbox, tracking domain, and sender path

2. Confirm domain readiness

Check the domain before you inspect individual records. A technically valid SPF record does not help much if the domain is expired, parked, unstable, or obviously risky for outbound.

Confirm:

• The root domain resolves.
• The domain is not expired, parked, or redirecting to a suspicious destination.
• Nameservers are stable and expected.
• The domain age fits the launch risk profile.
• The root domain loads over HTTPS or redirects cleanly.

OutboundQA check: DNS resolution, domain age, root-domain HTTPS, parked-domain risk, and launch-risk classification.

Manual tools: run the cold email domain checker for a quick first pass and the domain reputation checker when you need observable domain-risk context.

3. Verify reply routing with MX

Cold email infrastructure is not ready if replies cannot route back to the right mailbox provider. MX failures are easy to miss when the sender only confirms that an inbox connection exists.

Confirm:

• MX records exist.
• MX hostnames resolve.
• The provider matches the intended mailbox provider.
• There are no stale records from a previous provider.
• Reply handling is clear for aliases, forwards, and shared inboxes.

OutboundQA check: MX presence, MX resolution, provider mismatch risk, and asset-level launch note.

Manual tool: use the MX record checker.

4. Check SPF for authorization and lookup risk

SPF should authorize the active sender without becoming a dumping ground for old providers. Cold email teams often break SPF by leaving stale includes in place until the record exceeds the 10 DNS lookup limit.

Confirm:

• Exactly one SPF TXT record exists.
• The active sending provider is included.
• Old senders are removed when they are no longer used.
• The record stays under the 10 DNS lookup limit.
• The policy is intentional.

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

Manual tool: use the SPF checker.

5. Check DKIM for every active sender

DKIM is a launch-day failure point because it depends on the exact selector from the sending platform. Guessing the selector or checking only one provider can leave a campaign partially unsigned.

Confirm:

• The sender shows DKIM as enabled.
• The selector in DNS matches the selector in the sender.
• The public key resolves.
• The key is not malformed, split incorrectly, or pasted into the wrong host.
• Every active sender has its expected DKIM record.

OutboundQA check: DKIM selector resolution, malformed-key risk, provider-by-provider selector coverage, and fix guidance when the selector is missing.

Manual tool: use the DKIM checker or the SPF/DKIM/DMARC checker for a combined authentication read.

6. Confirm DMARC exists and is deliberate

DMARC is now a baseline for legitimate sending, especially when campaigns reach Google and Yahoo recipients. The pre-launch question is not only “does a record exist?” It is “does this policy match how the domain will send?”

Confirm:

• _dmarc exists for the sending domain.
• The record has valid syntax.
• The policy is deliberate.
• Reporting addresses are valid if used.
• Alignment is understood for the visible From domain.

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

Manual tool: use the DMARC checker.

7. Check tracking domains before links go live

A tracking domain can look configured in the sender while the public path is still unsafe. CNAME, SSL, redirects, and final URLs all matter before a client campaign starts generating clicks.

Confirm:

• The tracking subdomain is unique to the client or workspace.
• The CNAME points to the expected sender target.
• The target resolves.
• HTTPS works without certificate warnings.
• Redirects are not unexpectedly long or routed through unrelated hosts.
• The final campaign URLs load over HTTPS.

OutboundQA check: tracking CNAME, host resolution, SSL validity, certificate identity, redirect behavior, and link-domain launch blockers.

Useful background: read the tracking domains guide before assigning this work to a junior operator.

Operator checklist: use the cold email tracking domain setup checklist when the team needs a step-by-step launch pass for CNAME, SSL, redirects, and report evidence.

8. Review blacklist and reputation risk

Blacklist status is not a permanent score, but it is a launch blocker when a domain, IP, or tracking host is listed in the wrong place. Do this close to launch, not weeks earlier.

Confirm:

• Sending domains are not listed on major domain blacklists.
• Known mail-server IPs are not listed on major IP blacklists.
• Tracking domains and link hosts are not listed on URL-focused lists.
• Inconclusive lookups are recorded as unknown, not clean.
• Any listing has a remediation owner and recheck date.

OutboundQA check: blacklist lookup results, severity classification, unknown-provider handling, and fix recommendation.

Manual tool: use the email blacklist checker.

9. Match the setup to sender requirements

Google and Yahoo requirements should be treated as a launch-readiness baseline, not a separate compliance project. Even smaller cold email launches are affected by the same authentication and complaint-risk expectations.

Confirm:

• SPF or DKIM authenticates outbound mail.
• DMARC exists.
• The From domain aligns with authentication.
• Unsubscribe handling is appropriate for the campaign type.
• Bounce and complaint monitoring are part of the launch plan.
• Ramp limits are defined before the first send.

OutboundQA check: sender-requirement readiness, authentication evidence, alignment notes, and launch guidance for the report.

Useful background: read the Google and Yahoo bulk sender requirements guide.

Operator checklist: use the Google and Yahoo sender requirements for cold email guide when you need the agency launch version with report rows and ownership checks.

10. Check list hygiene and suppression rules

Infrastructure can be ready while the campaign is still unsafe to launch. The pre-launch pass should confirm list quality controls because high bounces and complaints can make a clean setup look broken.

Confirm:

• Leads were verified or sourced recently enough for the risk profile.
• Known unsubscribes and suppressions are excluded.
• Role accounts and risky addresses are handled deliberately.
• Bounce thresholds are defined.
• The first send segment is small enough for the domain and inbox age.

OutboundQA check: this is mostly outside DNS QA, but the launch report should record list-hygiene assumptions when they affect the final verdict.

11. Prepare the client-ready report

The final artifact should not be a private checklist in an operator’s notes. It should be a report that proves what was checked and what still needs attention.

Include:

• Workspace name and date checked.
• Domains, inboxes, tracking domains, and sender paths reviewed.
• Ready, Needs Fix, or Do Not Launch verdicts.
• Exact broken record, missing selector, stale provider, listing, or tracking issue.
• Required fix and owner.
• Recheck result after remediation.
• Final launch decision.

OutboundQA check: client-ready report generation with evidence, exact fixes, and shareable launch verdicts.

Reference format: use the client-ready deliverability report template, shareable proof-of-setup report before launch, or the sample launch QA report.

Cold email pre-launch checklist template

Copy this table into your launch process and require a status before the campaign goes live.

Area	Launch question	OutboundQA check	Status
Scope	Are all domains, inboxes, tracking domains, and sender paths listed?	Roster import and asset normalization	Ready / Needs Fix / Do Not Launch
Domain	Does every sending domain resolve and look safe to use?	Domain readiness, age, DNS, HTTPS, parked-risk checks	Ready / Needs Fix / Do Not Launch
MX	Can replies route to the expected mailbox provider?	MX presence, resolution, and provider match	Ready / Needs Fix / Do Not Launch
SPF	Is the sender authorized without duplicate records or lookup-limit risk?	SPF syntax, duplicate detection, provider alignment, lookup count	Ready / Needs Fix / Do Not Launch
DKIM	Does every active sender have a resolving selector?	DKIM selector resolution and malformed-key checks	Ready / Needs Fix / Do Not Launch
DMARC	Does the domain publish a valid, deliberate policy?	DMARC presence, syntax, policy, reporting, alignment notes	Ready / Needs Fix / Do Not Launch
Tracking	Do tracking domains resolve securely and route correctly?	CNAME, SSL, HTTPS, redirect, and host checks	Ready / Needs Fix / Do Not Launch
Blacklists	Are domain, IP, and URL listings clear enough for launch?	Blacklist results, severity, and unknown-provider handling	Ready / Needs Fix / Do Not Launch
Sender rules	Does the setup meet modern mailbox expectations?	Google/Yahoo readiness and authentication evidence	Ready / Needs Fix / Do Not Launch
List hygiene	Are bounces, suppressions, and first-send volume controlled?	Launch assumption recorded in report	Ready / Needs Fix / Do Not Launch
Report	Can the agency prove the launch decision?	Client-ready report with evidence and fixes	Ready / Needs Fix / Do Not Launch

What this checklist does not prove

A checklist does not prove live DNS is correct unless the team actually runs the checks. It does not guarantee inbox placement. It does not replace list quality, copy quality, sender reputation, or volume discipline.

Its job is narrower and more useful: make preventable launch blockers visible before sending starts.

That is where manual checklists become fragile for agencies. One client may have three sending domains and one tracking domain. Another may have twenty inboxes, multiple providers, several tracking domains, and DNS changes owned by the client. The workflow needs evidence, not memory.

OutboundQA turns the checklist into a repeatable launch QA pass: upload the workspace assets, get Ready, Needs Fix, or Do Not Launch verdicts, fix the blockers, rerun the checks, and share the report before the campaign goes live.

Run a first pass with the cold email domain checker, verify link tracking with the cold email tracking domain setup checklist, generate a planning version with the cold email launch checklist generator, or review the sample launch QA report when you need the finished client-ready handoff.