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

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.