Email list verification: a practical release checklist

Start with one named list version, one intended audience and one destination campaign or workspace. Record the source, extraction date and person responsible for the release. A file called final-list can become ambiguous as soon as somebody copies it, adds rows or imports it elsewhere.

Separate three questions. Is this a relevant person for the offer? What does the address check establish? Is this person eligible for this contact now? The prospecting guide handles account and role relevance. This workflow handles the technical evidence and the controls that connect a researched list to an actual import.

Choose the record you will count. In the worked example, one record means one unique address within the intended operation. Two addresses may still belong to one person, and two people at one company may require an account-level contact decision. Keep those relationships visible rather than assuming unique addresses mean unique opportunities.

Keep an unchanged source copy in your controlled workspace, subject to your retention rules. Work on a versioned copy that retains a stable row identifier and the source of each contact detail. This lets you trace a correction and explain why two exports differ.

Check the columns before checking the addresses. An email field containing a person's name, a company URL or several addresses separated by punctuation is an input problem. Trim accidental surrounding spaces and review obvious transcription errors against the source. Do not guess a missing address or silently rewrite one because it resembles a familiar naming pattern.

Treat identity changes as research, not formatting. If the person has moved companies, an old address that still passes a check does not establish that the person receives it. Keep the uncertain record on hold while the role and appropriate contact detail are reviewed. Record what was corrected, by whom and from which evidence.

Check both within the incoming file and against the operation that will receive it. A clean CSV can still contain people already active in another campaign, assigned to an account owner or excluded from further contact. Decide the matching rules and scope before accepting the tool's import total.

Instantly documents an always-on file-level duplicate check and a separate workspace-level option covering campaigns and lists. The workspace option can be disabled. That distinction matters: a unique import does not by itself demonstrate that overlapping campaign records were checked.

When records conflict, preserve the relationship and review the evidence. A newer source row should not erase an older stop request. Keep the retained record ID, linked duplicate IDs and the reason for consolidation. For multiple people at the same business, make a deliberate account-contact decision instead of applying a blanket rule that one company always equals one prospect.

Save the checker's original label, any explanatory result and the time checked. Map those values into your release process without replacing the original evidence. Tools may use different labels or tests; an unknown result should remain unknown unless a later check supplies new evidence.

Instantly's verification guide describes results including Verified, Invalid and Risky, with Invalid and Risky excluded from campaign sending by default. Check the actual result and current campaign settings; do not assume every tool uses those labels or that an operator has retained the default.

A catch-all arrangement can accept misaddressed mail without confirming the intended individual. Google's Workspace documentation, for example, describes routing messages for incorrect or non-existent addresses to a catch-all mailbox. The practical inference is narrow: acceptance at a domain is not proof that your named person owns a mailbox there.

Check the current preference and exclusion record before spending effort on a release candidate, and check it again immediately before import or activation. A stop request can arrive while the list is being prepared. Record the relevant scope: person, address, account, client or operation, according to the actual request and your established rules.

Keep permanent exclusion, temporary pause and missing information distinguishable. A contact awaiting a role check is different from someone who asked not to be contacted. Fresh verification must not turn either record into an automatic release. A person requesting deletion of their data also needs the appropriate data-handling process; do not treat that request as merely a sales-status change.

Check how exclusions operate in the sending tool. Instantly documents that its native Blocklist is checked during import and ongoing campaigns, whereas its Google Sheets blocklist is checked only during import. A spreadsheet entry therefore does not demonstrate that an already-running sequence has stopped.

Document the connection between your source of truth and each sending destination. If the same list reaches several workspaces, clients or tools, confirm the relevant controls in each. Use records and accounts you control to test expected behaviour; do not test an exclusion by attempting another message to the person who opted out.

Consider an invented batch of 100 source rows. Eight are duplicate rows, leaving 92 unique address records. Twelve unique records match current exclusions, leaving 80 for address verification. The check returns 52 acceptable results, 16 invalid results and 12 unresolved results. The unresolved group remains on hold.

During the final context review, three of the 52 passing records have outdated role evidence. Hold those three, leaving 49 records approved for this example release. This is a workflow illustration, not a benchmark for expected verification results, campaign performance or Inbox Leads customer data.

The table assigns each source row one primary disposition, using the order above. A duplicate may also match an exclusion; it is counted once as a duplicate row while its linked retained record keeps the exclusion. Additional reasons remain available without being added again to the totals.

Make the release record short enough to complete and specific enough for another operator to use. Store record-level evidence in the controlled system; the summary below points to it. Avoid spreading full prospect lists through unrelated documents or support tickets.

Before activation, compare the approved records with the import result and destination settings. Confirm field mapping, template previews and the actual eligible queue. Record skipped or changed records as decisions. A successful upload confirms ingestion, not that every row should be sent or that the campaign has launched.

Set review triggers around the way you obtain and use data. A long delay before activation, a known role change, a changed source, an updated exclusion or a new technical failure can justify another check. This guide does not prescribe a universal expiry date: the useful interval depends on your evidence, operating conditions and checker.

When an outcome conflicts with a prior result, preserve both with dates. A later failure does not make every earlier row invalid. Review the actual failure, its scope and the relevant record; use the troubleshooting guide when the issue concerns sending rather than list preparation. Pause the affected release where the remaining evidence is insufficient.

At the next handover, confirm that held records stayed held, exclusion updates reached the appropriate destinations and the same source file was not reintroduced under a new name. Improve the rule that allowed a discrepancy. The aim is a repeatable release decision whose reasoning remains clear when the list changes hands.