Cold email · deliverability audit
Deliverability is a list problem before it is a sending problem
Most teams buy sending infrastructure first and look at the list last. The audit below runs the checks in the order that actually removes risk: identity and domain alignment, then the list, then the send mechanics. Each check reports what it threw away, so the decision to send is made on numbers rather than on a warm-up calendar.
Authentication is not the first check — it is the cheapest one
SPF, DKIM and DMARC take an afternoon. They are also the only checks whose failure is not measured by a reply rate but by a mailbox provider deciding, silently, that a whole domain is not worth the risk. Google and Yahoo made that formal for bulk senders: authenticate with SPF and DKIM, publish a DMARC policy, keep the spam-complaint rate under 0.3%, and offer one-click unsubscribe. Those are entry requirements, not advantages.
An audit that stops there produces a domain that is allowed to send a problem list quickly. That is why the checks continue into the list itself, where the failures produce bounces and complaints rather than an error message.
The nine checks, in order
Order matters: each check assumes the previous one passed. Running them out of order means fixing a symptom that a cheaper check would have removed upstream.
SPF and DKIM alignment
Both records exist and the sending domain matches the From domain. Misalignment is invisible in a test send and visible in the aggregate report.
DMARC policy and reporting
A published policy with an address that receives reports. p=none with reports is a
measurement stage, not a finished state; the check records which stage a domain is in.
Tracking-domain separation
Opens and clicks are rewritten to a CNAME on the sending domain rather than to a shared vendor domain. Shared rewrite hosts make two unrelated senders share a reputation.
One domain, one purpose
Marketing mail, transactional mail and cold outreach come from different subdomains, so a cold campaign cannot degrade the reputation of password resets.
Root-domain folding
Addresses are folded to the registrable domain before anything else is counted, otherwise one
company appears four times — as www, as app, as a regional subdomain and as the root —
and inflates both the segment size and its bounce estimate.
MX check per domain
Every domain behind an address is asked for a mail exchanger. A domain without MX cannot receive the message the campaign is about to send.
Address-to-domain match
The address has to belong to the domain it is filed under. This is the check that removes
hello@world.com and placeholder addresses taken from other companies' pages.
Role and pattern rejection
Role mailboxes (info@, support@, noreply@) are separated rather
than sent to, and address patterns that no real person uses are rejected by shape.
Suppression and send caps
Unsubscribes, bounces and previous non-replies are subtracted before the batch is built, and the batch is split across sending days with a per-domain cap — the same company is not hit twice in one week.
What the working file looks like after the checks
Numbers below come from our own prospecting file, not from a client engagement: 9,266 company domains, refreshed 19 September 2026. They show the shape of the problem — how much of a list survives contact with a mail server.
| Measure | Value | What it means for a send |
|---|---|---|
| Company domains in the file | 9,266 | Segment ceiling before any suppression |
| Domains carrying a public address | 1,358 | 15% of the file is mailable at all |
| Domains answering MX | 1,350 | 8 would have bounced from a "verified" list |
| Domains without MX | 8 | Kept in a reject file, not silently deleted |
The gap between 9,266 domains and 1,358 mailable ones is the point. Domain count is a sourcing metric; address count is a sending metric, and they differ by a factor of seven.
Yield per source family
Same checks, same budget, different sources. The share below is the fraction of kept rows that carry a public address — the number that decides whether a source is worth another run.
| Source family | Share of rows with a public address | Why |
|---|---|---|
| Agency directories (DAN, Semrush) | 60% | An agency site is built to be contacted |
| Package registries (NuGet, RubyGems, npm) | 15% | Half the project URLs point at docs or a repo |
| Repository homepages (GitHub) | 11% | An OSS project page links GitHub, not a sales team |
| Hiring feeds (Arbeitnow, HN Who is hiring) | 11% | The posting is about a job, not about a company inbox |
| App marketplaces (Zapier, first pass) | Not measured yet | Field is a website; mailbox harvesting is a separate pass |
For the market pass we can already report the funnel: 3,000 applications gave 2,377 domains that were not already in the file, 1,798 of those answered with a live site showing at least two product signals (76%), and 1,538 survived once the threshold was raised to three signals (65%) — 1,538 rows added in a single run, which is more than any directory gave us in a day.
Symptom, cause, check
| Symptom | Usual cause | Check |
|---|---|---|
| Open rates fine, replies zero | Warm-up was treated as a deliverability strategy | 05–09 |
| Sudden drop after a new campaign | Second send to the same domains inside a week | 09 |
| Hard bounces above 2% | Domains without MX or addresses folded from the wrong subdomain | 05–07 |
| Spam complaints on a "clean" list | Role mailboxes treated as people, unsubscribe not honoured | 08–09 |
| Everything authenticated, still throttled | Shared tracking domain or one domain for all mail types | 03–04 |
What the audit hands back
Authentication report
Per sending domain: SPF and DKIM alignment, DMARC policy and stage, whether the aggregate-report address is live, and where a tracking CNAME is missing.
List report
Folded domains, MX status per domain, three reject files (no MX, address-domain mismatch, placeholder or role address) and the count each one removed.
Send plan
Batch sizes across days, per-domain cap, which subdomain carries cold mail, what is suppressed before the first send, and the point at which the batch stops enlarging.
Read-out
One call on the numbers: what the checks removed, what remains, and what the first batch is expected to produce in replies rather than in sends.
Where the audit sits in the engagement
Sprint
Audit, offer and landing page, first batches built and sent from your domains, measurement wired to the reply.
Engine
Sprint plus weekly source runs, the nine checks re-run on every batch, and a read-out on replies and pipeline.
Full Build
Several segments across two ICPs, tooling left running in your stack, handover documentation.
Questions this page usually gets
Do we need a new domain for cold email?
A separate subdomain is usually enough, and it keeps campaign reputation away from transactional mail. A new registered domain starts with no history and no alignment, so it is a deliberate trade, not a default.
Where does the 0.3% complaint threshold come from?
It is the spam-rate level Google states for bulk senders. Our audit reports the complaint rate as measured in postmaster tooling rather than estimating it, because the estimate flatters the sender.
Can the checks run on a list we already own?
Yes. The same nine checks run against an existing file and produce the same reject lists, so a list can be measured before it is sent again rather than after.
How long does it take?
Authentication is an afternoon per sending domain. The list checks scale with file size: the 9,266-domain file behind this page was checked in one working session, so tens of thousands of rows is a matter of hours rather than weeks.
Will the numbers on this page be true for our market?
The share of mailable domains depends on the source family, not on the market — 60% for agency directories against 11% for OSS repository pages held across several countries. The audit measures your file instead of transferring our ratio onto it.
Related, with the checks written out
Run the checks before the next batch
The audit is the first thing in the Sprint, not an upsell after it.
Where this was written up
The nine checks and the measured yields behind this page are published as an article: Deliverability is a list problem before it is a sending problem.