Client-ready email deliverability report template for cold email agencies

An email deliverability report is not useful if it only lists DNS records. Agencies need a report that answers the client question underneath the technical work:

Can we launch this cold email campaign safely, and what still needs to be fixed?

Use this template when a client workspace is moving from setup to launch approval. It is designed for cold email agencies that need to explain domains, inboxes, tracking domains, authentication, blacklist risk, and launch blockers without sending a client a raw spreadsheet of lookups.

Review the sample launch QA report first if you want to see the finished format, or book a launch QA pilot if you need this generated for a real client setup.

What the report must prove

A client-ready deliverability report should prove four things:

Question	What the report should show
What was checked?	Domains, inboxes, tracking domains, DNS records, blacklist status, and sender-rule readiness
What is the verdict?	Ready, Needs Fix, or Do Not Launch for each launch asset
What needs action?	The exact broken record, missing selector, provider mismatch, listing, or tracking issue
Who can use it?	Operators, account managers, strategists, and clients can all understand the next step

The report should not promise inbox placement. It should document infrastructure readiness before the campaign goes live.

The client-ready report template

Copy this structure into your launch process.

1. Executive summary

Start with the decision. A client should not need to read every DNS detail to understand whether the campaign can launch.

Include:

• Client or workspace name.
• Date checked.
• Number of domains, inboxes, and tracking domains reviewed.
• Overall verdict: Ready, Needs Fix, or Do Not Launch.
• Count of passed checks, warnings, and launch blockers.
• One paragraph on what happens next.

Example:

Field	Example
Workspace	Acme outbound launch
Checked	July 7, 2026
Assets	4 domains, 12 inboxes, 2 tracking domains
Verdict	Needs Fix
Summary	SPF and MX are ready, but one DKIM selector is missing and one tracking domain has an invalid SSL certificate. Fix those before volume starts.

OutboundQA maps this section to the workspace-level verdict in the sample report.

2. Asset inventory

List every asset included in the launch. This prevents a common agency failure: the report looks clean because only the easiest domain was checked.

Include:

• Sending domains.
• Inboxes or aliases.
• Tracking domains.
• Sending tool or SMTP path.
• Mailbox provider.
• DNS host when known.
• Owner or operator responsible for fixes.

Use this table:

Asset	Type	Provider	Sending tool	Status	Owner
client-mail.com	Sending domain	Google Workspace	Smartlead	Needs Fix	Ops
alex@client-mail.com	Inbox	Google Workspace	Smartlead	Ready	Ops
links.client-mail.com	Tracking domain	Smartlead tracking	Smartlead	Do Not Launch	Ops

If you only need a first-pass domain read, run the cold email domain checker before filling this section.

3. Launch verdicts by asset

Every checked asset should have a verdict that non-technical stakeholders can act on.

Use three statuses:

• Ready: this asset can be included in the launch plan.
• Needs Fix: this asset has an issue that should be corrected before sending starts.
• Do Not Launch: this asset has a severe blocker and should not be used for campaign volume.

Template:

Asset	Verdict	Reason	Required fix
client-mail.com	Needs Fix	DKIM selector does not resolve	Publish the selector from the sending tool and recheck DNS
links.client-mail.com	Do Not Launch	HTTPS certificate is invalid	Fix tracking SSL before tracked links are enabled
client-replies.com	Ready	MX, SPF, DKIM, DMARC, and blacklist checks passed	No action required

This is the section that turns a technical audit into a launch signoff.

DNS and authentication checks

The report should include enough detail for an operator to fix the setup without burying the client in raw DNS output.

MX records

MX records decide whether replies and bounces can route back to the right mailbox provider.

Include:

• Whether MX records exist.
• Whether the MX hostnames resolve.
• Whether the provider matches the expected mailbox provider.
• Any stale or conflicting records.

Manual check: use the MX record checker.

Template:

Domain	Expected provider	MX status	Launch note
client-mail.com	Google Workspace	Pass	Replies route to Google
client-replies.com	Microsoft 365	Needs Fix	MX still points to legacy provider

SPF

SPF checks whether the right sending services are authorized without breaking the 10 DNS lookup limit.

Include:

• Whether exactly one SPF record exists.
• Whether the sending provider is included.
• DNS lookup count.
• Duplicate, stale, or malformed records.

Manual check: use the SPF checker.

Template:

Domain	SPF status	Lookup count	Required fix
client-mail.com	Pass	7 of 10	No action required
client-replies.com	Needs Fix	12 of 10	Flatten or remove stale includes before launch

DKIM

DKIM is where many cold email launches fail because the selector in the sending tool does not match what was published in DNS.

Include:

• Selector checked.
• Whether the public key resolves.
• Whether the key appears malformed, split incorrectly, or missing.
• Which sending provider the selector belongs to.

Manual check: use the DKIM checker or the SPF/DKIM/DMARC checker for an authentication snapshot.

Template:

Domain	Selector	Provider	DKIM status	Required fix
client-mail.com	s1	Smartlead	Needs Fix	Publish the selector from Smartlead
client-replies.com	selector1	Microsoft 365	Pass	No action required

DMARC

DMARC is now a baseline requirement for legitimate sending, including many cold email setups.

Include:

• Whether the _dmarc record exists.
• Policy value.
• Reporting addresses when present.
• Syntax issues.
• Alignment notes if they affect the launch.

Manual check: use the DMARC checker.

Template:

Domain	DMARC status	Policy	Launch note
client-mail.com	Pass	p=none	Acceptable for launch, monitor reports
client-replies.com	Do Not Launch	Missing	Publish a valid DMARC record before sending

Tracking, blacklist, and reputation sections

Authentication can be clean while the launch is still risky. The report needs to cover the parts a sender status screen may miss.

Tracking domain

Tracking domains should be checked before links or opens are enabled.

Include:

• Tracking subdomain.
• CNAME target.
• Whether the destination resolves.
• HTTPS and certificate status.
• Whether the target matches the expected sending tool.

Template:

Tracking domain	CNAME status	HTTPS status	Verdict	Required fix
links.client-mail.com	Pass	Invalid certificate	Do Not Launch	Fix SSL before launch
go.client-replies.com	Pass	Pass	Ready	No action required

Blacklists

Blacklist checks should be framed as launch risk, not as a permanent reputation score.

Include:

• Domain listings.
• IP listings if an SMTP egress path is known.
• URL or tracking-domain listings.
• Severity.
• Remediation recommendation.

Manual check: use the email blacklist checker for a quick read.

Template:

Asset	Listing status	Severity	Recommendation
client-mail.com	Clean	Low	Recheck during first two weeks of sending
links.client-mail.com	Listed on URL-focused list	High	Do not use for tracked links until remediated

Sender requirements

Add a short section for Google and Yahoo sender expectations so the report connects technical checks to modern mailbox requirements.

Include:

• SPF or DKIM authentication.
• DMARC presence.
• Alignment notes.
• Unsubscribe handling for the campaign type.
• Complaint and bounce controls.

Template:

Requirement	Status	Note
SPF or DKIM authenticates mail	Pass	SPF and DKIM both present
DMARC exists	Pass	p=none published
Unsubscribe handling	Needs Review	Confirm one-click unsubscribe support for campaign type
Complaint controls	Needs Review	Monitor complaint rate and suppress risky segments

Fix log and final signoff

The report should make follow-through visible. A client-ready report is stronger when it records what changed after the first review.

Use this fix log:

Issue	Owner	Fix required	Recheck result	Status
Missing DKIM selector	Ops	Publish Smartlead selector	Selector resolves	Closed
Tracking SSL invalid	Ops	Regenerate tracking certificate	HTTPS passes	Closed
DMARC missing	Client IT	Add _dmarc TXT record	Record found	Closed

Then end with a signoff block:

Role	Name	Decision	Date
Agency operator		Ready to launch / Hold launch
Account owner		Client informed / Fixes pending
Client approver		Approved / Needs review

What not to put in the report

Keep the report credible by avoiding claims the checks cannot prove.

Do not include:

• A guarantee of inbox placement.
• A claim that a clean DNS report means the campaign will perform.
• Raw DNS output without a verdict.
• Warmup advice that ignores domain age, list quality, bounce risk, and campaign volume.
• A single overall pass if individual assets still have unresolved blockers.

The report should say whether the launch infrastructure is ready, not whether the campaign will get replies.

How OutboundQA fits

Manual templates are useful when an agency is small or when one client has a simple setup. They break down when a team launches many workspaces with multiple domains, inboxes, tracking domains, and operators.

OutboundQA turns this template into a launch QA report: upload the client assets, run the checks, get Ready, Needs Fix, or Do Not Launch verdicts, and share the report before the campaign goes live.

Start with the sample report to see the client-ready format, run a one-domain check with the cold email domain checker, or book a launch QA pilot for the next client setup.