How to audit a cold email setup before launch

To audit a cold email setup before launch, inventory every sending domain, inbox, tracking domain, and known SMTP egress path. Check each asset with current evidence. Record failures as owned fixes. Rerun every failed check. Launch only when the overall verdict matches the worst unresolved blocker.

The output is one decision:

• Ready: every required launch check passed with current evidence.
• Needs Fix: a specific, correctable issue still blocks the affected asset.
• Do Not Launch: a critical failure makes the current setup unsafe to approve.

Do not average the results. Three clean domains do not cancel one domain with missing authentication. A working inbox does not cancel an expired tracking certificate. A sender dashboard showing Connected does not prove the whole workspace is ready.

Use the cold email domain checker for one domain. Use the cold email infrastructure audit template when you need a manual evidence register. Use the full audit below when the launch needs one decision across the workspace.

The cold email setup audit in one table

Run the audit in this order. The order keeps scope mistakes from hiding behind clean record checks.

Layer	Question	Minimum evidence	Launch blocker example
Scope	Is every active asset included?	Approved asset roster with owner	A late-added domain or inbox is missing
Sending domains	Can the domain authenticate and support the intended sender?	Live DNS, provider setup, and a real message when available	Active DKIM selector does not resolve
Inboxes	Can each mailbox send, receive, and route replies through the expected provider?	Provider status, controlled send and reply, message headers	Replies route to an old provider
Tracking domains	Does each campaign link host resolve and work over HTTPS?	CNAME, certificate, final redirect, and one real tracked link	Certificate is invalid or CNAME points to the wrong tool
SMTP egress	Does the known sending path present a coherent public identity?	IP, PTR, forward DNS, HELO, TLS, banner, and listing result	PTR and forward DNS do not match
Decision	Does the verdict match the worst unresolved finding?	Finding owner, fix, rerun, and approval	A blocker is marked Ready without a rerun

The audit is time-bound. Save the observed result and UTC capture time. DNS, certificates, listings, provider settings, and receiver policies can change after signoff.

Use the cold email infrastructure scorecard when the team needs a compact map of authentication, server identity, and link-layer checks before assigning owners.

1. Lock the launch scope

Write the asset roster before checking records. Do not audit one representative domain and assume its siblings match.

Record:

• Client or workspace name.
• Planned launch date and accountable approver.
• Sending platform and mailbox provider.
• Every visible From domain and sending domain.
• Every active inbox and alias used for replies.
• Every custom tracking domain.
• Every known SMTP egress IP or relay path.
• DNS, mailbox, sending-tool, and remediation owners.

Give the audit a stable ID such as CLIENT-2026-08-LAUNCH-01. Keep that ID on findings, reruns, evidence, and signoff.

If an active path is unknown, record Unknown. Missing evidence is not a pass. Agencies managing several workspaces can use the multi-client cold email QA workflow to assign owners and prioritize open blockers.

2. Audit every sending domain

Start with live public state. Then compare it with the sender configuration and a real sent message when one is available.

Domain and routing checks

Confirm that:

• The domain resolves and the nameservers are expected.
• Registration and expiry do not create an immediate operational risk.
• MX records route replies to the intended mailbox provider.
• Old MX or provider records are not still active.
• The root domain and expected public destinations load without an obvious parked or broken state.

Run the MX record checker when reply routing is unclear. MX proves the public inbound route. It does not prove that an individual mailbox is licensed, connected, or receiving replies.

SPF, DKIM, and DMARC checks

For each active sender, confirm:

• One SPF record exists and authorizes the actual sending service.
• Old SPF includes are removed when no longer needed.
• SPF evaluation stays within the protocol limit of 10 DNS-querying terms.
• The DKIM selector used by the active sender resolves to the expected public key.
• The sender signs real messages with that selector.
• DMARC exists and the visible From domain aligns with SPF or DKIM on a real message.
• The DMARC policy and reporting destinations are deliberate.

The SPF limit comes from RFC 7208. Use the SPF, DKIM, and DMARC checker for the public records, then inspect a controlled message header for the authentication path that actually ran.

Example finding:

Asset	Check	Evidence	Verdict	Required fix
mail.example.com	DKIM selector	Sender uses s2, but s2._domainkey.mail.example.com returns no record	Needs Fix	Publish the sender-provided key, enable signing, send a new test, and rerun

3. Audit every inbox

Shared domain records do not make every inbox equivalent. Audit each mailbox that will send or receive replies.

Confirm:

• The inbox is connected to the intended provider and sending platform.
• A controlled message can be submitted and accepted without a sender-side restriction.
• The visible From address is correct.
• Replies reach the intended mailbox, alias, or shared inbox.
• Forwarding and reply-to rules do not send responses to an old or unmonitored destination.
• A received test message shows the expected SPF, DKIM, and DMARC results.
• Bounces, suppressions, unsubscribes, and complaints have named owners.

Save one controlled test per provider path, not one test for the entire client. If ten inboxes share the same confirmed provider configuration, document the shared evidence and still keep a row for each inbox. Any exception needs its own test.

A browser DNS lookup cannot prove mailbox licensing, provider restrictions, live reply routing, or the authentication result on a real message. Keep those results Unknown until provider evidence or a controlled test resolves them.

4. Audit every tracking domain

Tracking domains sit inside message links. Treat them as first-class launch assets.

For every host, confirm:

• The host belongs to the correct client or workspace.
• The CNAME points to the target supplied by the active sending tool.
• The target resolves publicly.
• HTTPS works without a certificate warning.
• The certificate covers the exact tracking hostname.
• A real tracked campaign URL follows the expected redirect path.
• The final destination loads over HTTPS.
• An old platform, unrelated client, or default shared tracking host is not in the path.

Test one real campaign link. Opening only the tracking hostname can miss a broken redirect path.

Use the tracking domain checker for the live host and the tracking domain setup guide for the full CNAME, HTTPS, redirect, and ownership pass.

Example finding:

Asset	Check	Evidence	Verdict	Required fix
links.example.com	Tracked URL	CNAME resolves, but the final campaign link returns a certificate error	Do Not Launch	Provision the correct certificate and rerun the exact campaign link

5. Audit the SMTP egress path

The sending domain identifies the message. SMTP egress identifies the server path that hands it to a receiver. Audit that path when the IP or relay is known, dedicated, self-managed, or exposed by the provider.

Confirm:

• The sending IP is the approved IP for this launch.
• The IP has a PTR record.
• The PTR hostname resolves forward to the same IP.
• HELO or EHLO is coherent with the approved server identity.
• TLS is available on the tested path when the evidence is accessible.
• The live SMTP banner does not contradict the approved path.
• Relevant IP listings are clear, unavailable, or known with a recorded severity.

Google’s current email sender guidelines require valid forward and reverse DNS for sending domains or IPs and TLS for transmission to personal Gmail accounts. Yahoo’s sender best practices also call for valid forward and reverse DNS on sending IPs.

When a managed provider owns the SMTP path, do not invent a clean result. Record the provider, the evidence you can observe, and which checks are provider-managed or unavailable. Use the SMTP egress checks guide when a custom relay, dedicated IP, or mixed path needs deeper review.

6. Turn findings into one launch decision

Every non-passing finding needs five fields:

1. Exact affected asset.
2. Observed evidence and capture time.
3. Verdict and blocker reason.
4. Required fix and one owner.
5. Rerun result and approver.

Apply the decision at two levels. First, set the verdict for each asset. Then set the workspace verdict from the worst unresolved blocker.

Finding state	Asset verdict	Workspace action
Required checks passed with current evidence	Ready	Keep the asset in scope
Correctable blocker remains	Needs Fix	Hold the affected asset, fix it, and rerun
Critical failure remains	Do Not Launch	Stop approval for the affected scope
Evidence is missing or the check failed to complete	Unknown	Resolve the evidence gap or record an explicit exception before approval

Do not change a verdict because someone says a fix was made. Rerun the failed condition after the change is live. Then run one final full pass so the workspace decision comes from one current evidence set.

The launch verdict guide explains the severity model. The client-ready report template shows how to present the evidence and fixes. The sample Launch Report shows the finished client-facing result.

Worked cold email setup audit example

An agency plans to launch 12 inboxes across 3 sending domains, 1 tracking domain, and a dedicated SMTP IP.

The audit finds:

• Domain A is Ready.
• Domain B has a missing active DKIM selector.
• Domain C is Ready, but 2 inboxes route replies to an old shared mailbox.
• The tracking host resolves, but its campaign URL has an invalid certificate.
• The SMTP IP has matching PTR and forward DNS.

The workspace is not Ready. The clean domains and SMTP identity do not offset the DKIM, reply-routing, and tracking blockers.

The operator assigns three fixes, captures new DNS and mailbox evidence, reruns the exact failed checks, then runs one final full pass. Only after every in-scope asset has a current result can the approver issue the final launch decision.

Keep receiver requirements current

Receiver policies change. Treat the policy review as dated evidence, not permanent copy in an internal checklist.

At the final pass, compare the setup with current primary guidance from Gmail, Yahoo, and the receiver requirements guide. Check the rules that apply to the sender’s traffic shape, including authentication, alignment, forward and reverse DNS, TLS, complaint controls, and unsubscribe handling.

Passing observable receiver requirements does not predict where a message will land. It only removes known setup failures from the launch decision.

What this audit does not prove

A Ready verdict does not guarantee inbox placement, replies, meetings, or revenue. It does not prove private domain or IP reputation. It does not validate list consent, audience fit, message quality, or every provider-side control.

It answers a narrower question: does the defined cold email setup have enough current evidence to approve launch, or is there a known blocker to fix first?

That distinction keeps infrastructure readiness separate from inbox placement. If the setup is Ready but controlled messages land inconsistently, use a placement test and message evidence as a separate investigation. Do not rewrite the launch audit result to claim an outcome it did not measure.

Create the Launch Report

A spreadsheet can hold the evidence. It still depends on someone keeping the scope complete, applying the verdict rules, assigning fixes, and rerunning every failed check.

Create a Launch Report when the workspace needs one shareable decision across domains, inboxes, tracking domains, and SMTP egress. OutboundQA groups the current evidence, exact fixes, reruns, and final Ready, Needs Fix, or Do Not Launch verdict for client or internal signoff.

FAQ

What should a cold email setup audit include?

Include every sending domain, inbox, tracking domain, and known SMTP egress path. Check ownership, DNS, authentication, reply routing, link tracking, server identity, current receiver requirements, evidence, fixes, and reruns.

Can I audit one domain and apply the result to every inbox?

No. Several inboxes can share domain records but differ in provider connection, DKIM path, reply routing, restrictions, or message authentication. Keep an evidence row for every active inbox.

Do I need SMTP egress checks when a provider sends the email?

Record the sending path in every audit. Add IP, PTR, forward DNS, HELO, TLS, banner, and blacklist checks when the path is known or controlled. Mark unavailable provider-owned evidence as unknown or provider-managed, not Ready.

When is a cold email setup Ready to launch?

Ready means every in-scope asset passed the defined launch checks with current evidence and no unresolved blocker. Fixes need a fresh rerun before the overall verdict can change.

Does a Ready verdict guarantee inbox placement?

No. Ready is an infrastructure launch decision. Inbox placement also depends on private receiver signals, sender history, recipient response, sending behavior, list quality, and message content.