# Proving list quality to a client, without a number you made up

_2026-09-24 · Boundstone (https://boundstone.io/blog/prove-list-quality-to-a-client)_


An agency that delivers lists gets paid on volume and judged on bounces. Those two facts pull in opposite directions, and the usual resolution is a number on a slide: *98% verified*.

The problem with that number is not that it is wrong. It is that your client cannot check it, which means it does no work the first time a bounce report contradicts it.

## Hand over the artefact, not the adjective

Run the file through `POST /v1/bulk/email` and `POST /v1/bulk/phone`, then deliver `results.csv` **alongside** the list rather than instead of it.

That file carries, per row: the verdict, the checks that produced it, and — the part that matters in a dispute — the checks that did not run. Your client can open it, sort it, sample it, and re-run any row against the same endpoint to get the same answer.

You have replaced a claim with a thing. Claims get argued about; artefacts get read.

## What the not-run list does for you

Most quality disputes are not about a wrong verdict. They are about a mismatched expectation of what "verified" covered.

`checks.not_performed` settles that in advance, in writing, per row. For email it names `smtp_mailbox` and `catch_all`. That is Boundstone stating plainly that nobody knocked on the individual mailbox and nobody tested whether the domain accepts everything — because an SMTP probe is slow, frequently answered dishonestly by the receiving server, and damaging to the reputation of whoever runs it.

When a bounce arrives from a mailbox that no longer exists, you are not defending a broken promise. You are pointing at a line in a file you both already have, which said that check did not run.

## Date the file

Validation is a reading, not a property. An address that resolved on the third can be gone on the tenth.

Put the validation date in the deliverable and make it explicit that the answer decays from that moment. It protects you, it is true, and it converts a vague "the list was clean when we sent it" into a checkable claim.

## What you can defensibly say

You can say the list was screened for syntax, mail-server presence, disposable providers and role addresses, on a stated date, with the per-row evidence attached.

You cannot say it will not bounce, and you should not want to — the bounces only the receiving server knows about are invisible to every vendor, including the ones implying otherwise.

For phone, the same shape: `valid`, `line_type` and E.164 are what you screened, with `carrier_lookup`, `ported_status` and `hlr_liveness` marked `not_performed` unless you paid for a live dip with `hlr:true`. If a client's economics genuinely need liveness, that is a line item you can quote rather than a promise you absorb.

## Why this is a commercial position, not a disclaimer

The instinct is to see the not-run list as weakness — the thing to bury in a footnote so the deliverable looks stronger.

It is the opposite. An agency that hands over a scoped, dated, re-runnable artefact is doing something its competitors, who ship an unverifiable percentage, structurally cannot. The client learns that your numbers survive inspection. That is worth considerably more than two points of claimed accuracy, and it compounds across renewals.

The vendors selling certainty are betting the client never checks. You are better off being the agency that assumed they would.

## The short version

- **A percentage your client cannot verify does no work.** The first contradicting bounce report turns it into an argument.
- **Deliver `results.csv` with the list.** Per-row verdict, the checks that ran, and the checks that did not.
- **`checks.not_performed` prevents disputes rather than causing them.** `smtp_mailbox` and `catch_all` set the expectation in writing, per row, before anyone sends.
- **Date the validation.** The answer decays from that moment, and both sides should know when the clock started.
- **Never promise no bounces.** Some are only knowable to the receiving server at send time — for every vendor.
- **Scoped honesty is a commercial advantage.** It is the deliverable a competitor shipping an unverifiable percentage cannot match.