Define what the gate is allowed to accept
Separate three questions: does this address belong to the intended person, what does the verifier report about delivery, and is the contact eligible for this campaign? Passing one does not answer the others. Hunter’s verifier documentation describes verification results and separate signals such as accept-all handling. Map the selected provider’s documented fields explicitly; status names are not interchangeable across vendors.
These are example policy choices. Choose and document the exact acceptance rule for your use case, including whether role addresses are eligible. Never turn a technical error into an invalid-address label.
Put verification before expensive downstream work
Normalize and deduplicate the input, resolve identity, and check your suppression source before verification. After verification, pass only accepted rows to personalization and campaign preparation. Recheck eligibility immediately before sending because an unsubscribe or internal exclusion can arrive after a list was built. Do not remove punctuation from email local parts using a global rule. An address transformation that works for one mail provider may change the identity at another. Keep both the raw address and the normalized representation used for comparison.Worked batch: why a positive verifier result can still be held
This fictional five-record batch uses a conservative policy: current identity, acceptable mailbox evidence, and campaign eligibility must all pass. The labels below are our normalized categories, not a provider response schema.
The result is one accepted, two held, one rejected, one retry pending. A dashboard that counts three positive mailbox responses as three usable contacts would overstate the outcome.
For record E, a minimal decision record might look like this. It is an application-owned format, not an API payload:
Handle retries without making the list less trustworthy
Set a bounded retry policy for temporary failures. When the retry budget is exhausted, hold the record and retain the error. Do not call a second verifier solely until one says what you want to hear. If providers disagree, preserve both observations and apply a conflict policy. Treat freshness as a business rule. Record when verification occurred and recheck records that exceed the campaign’s chosen window. There is no universal number of days after which every email becomes stale. For recurring jobs, keep a stable row identity and input revision so replaying a completed batch does not enqueue the same contact twice. Verification and campaign enrollment are separate actions; a successful verification run must not implicitly authorize enrollment.Build a pilot from real failure categories
After the quickstart, discover the current tools:valid field.
Test with internal or authorized test records covering acceptable, invalid, catch-all, unknown, duplicate, suppressed and provider-error outcomes. Verify that held and rejected rows cannot enter the accepted export. A pilot consisting only of deliverable addresses cannot prove that the gate works.