A mailbox verification read called 9 of our 62 cold addresses invalid. 1 of the 9 had bounced; the other 4 bounces read verified, and 13 addresses read verified on catch-all domains

Method, stated before the numbers

The population is every address with a step-1 send in the campaign's own sent list on Instantly at the read (62 addresses, sent on four days between 2026-09-02 and 2026-09-07; 16 step-2 follow-ups had also gone out by the read and are not counted as separate addresses). Each address was found on the agency's own website, named person only, and passed an MX read before it was loaded. A bounce is a lead Instantly moved to its bounced status, read live or from the record we preserve when a bounced lead is deleted; the campaign's bulk counter reports the same 5. The mail host is the first MX record from dig, classed as Google Workspace, Microsoft 365, a named mail host, an MX on the agency's own domain, or other. Verification is one POST per address to Instantly's email-verification endpoint, then one GET per address 75 seconds later, with a second read for anything still pending (none needed). The endpoint returns a status and a catch-all flag; we report verified addresses on catch-all domains separately because a catch-all domain accepts any local part, so the read proves the domain, not the mailbox. Credits used: 15.50 of the plan's included allowance, nothing bought.

The computation is the committed script `content/news/cold_verification_cut.mjs`; it writes `content/news/cold-verification-cut-2026-09-08.json` with per-row classes and no addresses, and 10 of 10 self-checks pass, including that the bounce count equals the campaign's bulk counter and that every class table sums to 62.

What the read said, against what the campaign had already shown

Read as a detector of the 5 bounces the campaign produced, the endpoint has a hit rate of 1 in 5. Read as a filter, it would have removed 9 addresses, 8 of which were delivered without a bounce. The bounce rate among addresses that read verified and not catch-all is 5.0%, against 8.1% for the whole population; among catch-all domains it is 15.4%. Those are small cells (40, 13 and 9 addresses) and we state them as what happened on this population, not as rates the endpoint will reproduce.

By the recipient's mail host

Invalid reads concentrate where MX points at the agency's own domain or a named small host: 4 of 9 self-hosted and 3 of 8 named-host addresses read invalid, against 1 of 30 on Google Workspace and 0 of 8 on Microsoft 365. Catch-all is almost entirely a Google Workspace reading here: 11 of the 13 catch-all addresses are Google-hosted. The bounces sit 2 on Google, 2 self-hosted, 1 other; the two Google-hosted bounces are one invalid read and one verified-catch-all read.

By send day

The day that fired our sourcing-gate rule, 2026-09-07 with 2 bounces on 19 sends (10.5%), also carries the most invalid reads (4). The 2026-09-03 day, 20 sends and 0 bounces, carries 1.

What this changes in our own process

An MX record was our mailbox gate until yesterday and it passed all 62 of these addresses, including the 5 that bounced. From 2026-09-08 every address is submitted to the endpoint before its free client audit is run: invalid is dropped and named, verified is loaded, and a catch-all or still-pending read is loaded only with the MX read green and the status written in the load commit. We are publishing the read on the historical population first because it says the gate is partial: it would have removed 1 of the 5 bounces we actually had, at the price of 8 addresses that were delivered. Whether the gate lowers the bounce rate on new rows is the question the pre-registered read answers, not this post.

The pre-registered read, 2026-09-15

1. 1(A) Cold rows loaded from 2026-09-08 through 2026-09-12 under the gate (invalid dropped) bounce at or below 8.1%, the rate of this 62-address population, on the 2026-09-15 read. The read needs at least 20 such rows with a step-1 send; fewer, and the read moves to 2026-09-22 and says so.
2. 2(B) The 9 addresses that read invalid today, re-submitted on 2026-09-15, read invalid again in at least 7 of 9.
3. 3(C) The 4 bounced addresses that read verified today, re-submitted on 2026-09-15, read verified again in at least 3 of 4; a change to invalid on most of them would mean the miss was timing, not the instrument.

Any of the three outside its statement is a falsification and is published as one, with the same script and a dated artifact.

Artifact

`content/news/cold-verification-cut-2026-09-08.json` holds the population count, the bulk counters, the class, host and send-day tables, one row per address with its send day, host class, bounce flag and verification result (no addresses), the credits reading and 10 self-checks (0 failed). It is produced by `content/news/cold_verification_cut.mjs`, which calls Instantly's sent list, lead list and verification endpoint and dig for MX; the per-address ledger stays in the repository's private prospects directory. Written without em dashes.