Four different questions
Can the address be interpreted? Does its domain accept mail? What did the verifier learn about the mailbox? Are you entitled to send this particular message? These questions need different evidence. A positive result for one is not a shortcut through the others. Keep the observation date beside the result rather than turning a temporary finding into a permanent label.
Decide whether a tool is the missing piece
Start with a small written description of the failure: an ambiguous export, a returned message, uncertain permission, or a result file you cannot reconcile. Only some of these involve address verification. If your organisation cannot explain where a list came from, paying to inspect addresses does not repair that missing history.
Try the distinction
Fictional case: a record is marked deliverable, but its owner opted out last month. The correct outcome is still exclusion from marketing. In another case, an authorised contact returns unknown. Preserve uncertainty; do not claim the person disappeared. Write the evidence that would change each decision before selecting a vendor.
Put it into practice
A fictional club inherits a spreadsheet labelled “verified.” The file has an address column and green cells but no vendor, date, result definition or permission source. The new administrator should not treat the colour as evidence. Reconstruct the minimum record first: which input was inspected, by which process, when, and for what purpose. If those facts cannot be recovered, describe the technical state as unverified rather than guessing. Separately inspect the club's authorised communication records. Some contacts may legitimately receive operational notices but not a new promotional newsletter. Buying another verification run would answer only the technical portion. The useful deliverable is a two-part decision record with an owner for each unresolved question. This example explains the framework; it does not prescribe the club's legal obligations or establish that any real list was checked. Once the missing requirement is explicit, compare a verifier against the no-purchase alternative.
Protocol context, not certification
RFC5321 distinguishes SMTP verification responses and discusses verification-related security considerations. It is useful background for why a mail-system response should not be expanded into a promise about every downstream outcome. It does not certify Bouncer or establish permission to send a message.
Sources used for this page
These records support the facts and comparisons above. Merchant-controlled records are labelled so you can separate product claims from independent evidence.
- Bouncer verification overview — Merchant documentation · usebouncer.com · Merchant-controlled · checked 2026-09-27
- Bouncer API introduction — Merchant documentation · docs.usebouncer.com · Merchant-controlled · checked 2026-09-27
- RFC5321: SMTP specification — Standards and certification reference · rfc-editor.org · Publisher independence not verified · checked 2026-09-27