Infrastructure readiness report, September 2026
We checked the agencies who sell deliverability. 60% would fail their own audit.
35 organisations that sell cold email or outbound as a service, one publicly visible sending domain each, three records every receiver reads before deciding anything else. No domain is named in this report, and none of the data came from a customer.
40%
Ready
No blocker in the three public records checked.
14 of 35
45.7%
Needs Fix
Sends, but publishes something receivers penalise.
16 of 35
14.3%
Do Not Launch
A record is missing or contradicts itself.
5 of 35
Everyone gets the easy part right
Mail routing is the check nobody fails. It breaks loudly and immediately, so it gets fixed. The records that decide how a receiver treats the domain fail quietly, and they are the ones left undone.
DMARC policy
48.6% not clean · 4 fail, 13 warn
SPF record
22.9% not clean · 2 fail, 6 warn
MX record
0% not clean · 0 fail, 0 warn
What actually blocks them
Of the 21 domains carrying a finding, this is the first thing an operator would have to fix.
DMARC policy
61.9% (13)
SPF record
38.1% (8)
Signals kept separate
These are public too, but they are not part of the verdict above. Mixing them in would let a reputation signal quietly change a configuration result.
What this does not say
Public MX, SPF, and DMARC for one sending domain per organisation. Inboxes, tracking domains, SMTP egress, and sender history are not visible from a public run and are not counted.
A Ready result here is not a prediction that mail reaches the inbox. It means three public records on one domain hold up. The rest of the catalog needs inboxes, tracking hostnames, SMTP egress paths, and sender history, none of which are visible from outside an organisation. We did not ask anyone for access, so we did not measure them.
There is no trend line here either. This is the first run. A second period is worth publishing when one exists, not before.
Check the same three records yourself
Every number above came from records anyone can read. Run the same check on your own sending domain, or read the full catalog and what each check costs when it fails.
Repost it
The numbers are free to quote. Credit the report so a reader can check the method.
We ran a public infrastructure check on 35 agencies that sell cold email as a service. 40% were clean. Every single one had mail routing right. 48.6% had a DMARC problem. The easy part is done everywhere. The part receivers actually judge on is not. No domains named. Method and numbers linked below.
Newsletter
60% of the outbound agencies we checked would not pass their own pre-launch audit. The sample: 35 organisations selling cold email, one public sending domain each, three records (MX, SPF, DMARC). MX passed 100% of the time. DMARC did not.
Questions
Whose domains were checked?
35 organisations that sell cold email or outbound as a service, each checked on one publicly visible sending domain. No customer data was used, and no domain is named anywhere in this report.
How can you publish this without naming anyone?
The published dataset holds counts only. The audited domains exist while the report is generated and never reach the output, and the generator refuses to write a file that contains one.
Does a Ready result mean their email reaches the inbox?
No. This checks three public records on one domain. Inbox placement also depends on list quality, message content, volume, and mailbox provider behaviour that no public source exposes.
Why only three checks when the catalog has 75?
The other checks need inboxes, tracking hostnames, SMTP egress paths, and sender history, none of which are visible from outside an organisation. Reporting a readiness rate from a full audit would need access we deliberately do not ask for.
Sample of 35 organisations, September 2026. Generated by
npm run generate:readiness-report, which reads public DNS, RDAP, and HTTPS
only, and refuses to publish a dataset containing an audited domain.