OKKI Go research note

Email Verification Best Practices Across the Contact Lifecycle

Build an email verification workflow for capture, imports, address changes and pre-send review. Keep mailbox results, permission and suppression separate.

Check email addresses at capture, import, meaningful contact changes and before sending when their status is uncertain. Keep mailbox validity separate from marketing permission and suppression. A record can remain useful for research while being ineligible for outreach; an old successful check does not settle a new sending decision.

Define the Contact States Your Verification Process Must Produce

At capture, your contact record contains an address and a reason it was collected. By the time you select it for a campaign, it also needs a defensible sending decision. The workflow between those moments is where email verification best practices become useful.

Usable, blocked, and unresolved records

You can begin with separate answers to “What did the mailbox check establish?” and “What may happen next?” Hunter's verification guide, checked in September 2026, distinguishes valid, invalid, accept-all and blocked results. Accept-all leaves the individual mailbox uncertain. Blocked means the receiving server prevented verification, rather than proving the address invalid. For a working contact process, map these outcomes into usable, blocked-from-sending and unresolved records, while retaining the original result. In your workflow, a usable record has passed the checks required for its intended action. You can keep an unresolved record waiting for review without being admitted to a campaign. A record barred from sending may still need to exist so its exclusion survives the next import. These are proposed categories you can adapt, not replacement names for a vendor's statuses. In particular, “blocked verification” and “blocked from marketing” describe different things: one concerns a failed check, the other a decision about use.

I keep that distinction explicit when reading the documentation. The same word, blocked, can otherwise conceal the reason a contact can't move forward.

Verification is not marketing permission

Mailchimp's import documentation says updated imports don't change the marketing status of existing email contacts. An address can therefore receive a fresh mailbox result without becoming subscribed. Auth0 makes another distinction: checking access to an address isn't proof that a user is the person they claim to be. Your workflow needs separate places for these answers. Mailbox checks inform reachability; an access-confirmation flow checks access; subscription and suppression records govern the proposed marketing use. You can't let one silently substitute for the others.

Prepare Records and Status Rules Before Verification

Before you run the first batch check, preserve enough of the incoming record to understand a later change. You need the starting address when someone corrects it. You need the starting subscription state when a later file tries to overwrite it. Preserve those starting conditions before comparing incoming and existing records.

Normalize addresses without deleting provenance

Keep your supplied address, its source and the normalized working value together. As you prepare the records, remove accidental surrounding whitespace and flag malformed entries for correction. Do not invent a missing domain or silently replace an unfamiliar spelling. Record whether the value came from a form, an import or an existing contact record, and attach the date of that event. You can use this proposed recordkeeping practice; it doesn't claim that a particular CRM supplies these fields automatically. When you receive a later batch of results, associate them with the address actually checked. If the contact's address changed meanwhile, the result belongs to the earlier value. You can ask a precise question: does this result describe the address now being considered for use? A contact-level green flag without that relationship can't answer it.

For a team researching accounts in OKKI Go, the same discipline can live in its handoff notes: preserve the address being assessed and the action still awaiting clearance.

Keep suppression and consent records separate

Treat your mailbox-check result as an addition to the contact history, not permission to replace that history. Keep the relevant subscription state, objections and suppression reasons available to the system that sends. Mailchimp documents an especially useful limit: it can exclude existing bounced or unsubscribed contacts during an import into the same audience, but can't detect those conditions across independent audiences. Moving a record to another destination therefore requires its own reconciliation with the applicable suppression records. Your successfully completed import isn't evidence that every exclusion survived.

Verify at the Points Where Contact Information Changes

Your address now moves from collection toward use. At each transition you reach, the check has a different purpose. A form needs a recoverable correction path; an import needs status reconciliation; a changed address needs its own assessment; a campaign needs a current decision.

Capture and imported-list checks

As you capture the record, apply the mailbox check to the submitted address while there is still a practical route to request a correction. If the application needs confirmation that the person can access the mailbox, use a distinct access-confirmation step. Auth0 documents verification links at signup and the option to defer verification until an action requires it. That supports your choice of the moment according to the action, rather than treating all verification as a single onboarding ritual. In a proposed form workflow, a typo would return for correction; an inconclusive mailbox result would remain unresolved; completion of an access check would be recorded separately. These are design choices, not results of a test performed here.

The next boundary is import. A file arriving with a “verified” column still needs interpretation.

Before you accept the file, identify which address was checked, when it was checked and what the original status meant. If you can't find that information, preserve the uncertainty instead of converting the label into clearance. Hunter recommends verifying addresses with unknown status before outreach. Where your imported verification remains relevant to the unchanged address and planned use, review and retain it; a redundant paid check isn't the objective. Where the address or its status can't be established, run the needed check before allowing a send. Reconcile the imported result with existing suppression information independently. A mailbox pass updates one part of the record. It doesn't erase an unsubscribe.

Employer changes, stale records, and pre-send review

If you learn of an employer change, it calls the contact-address relationship into question, even if the stored mailbox result looks acceptable. Mark that relationship for review, confirm the intended current address and check any replacement before using it. An old result must remain attached to the old address. Mailchimp's cleaned-contact documentation offers a concrete example of keeping an address change distinct: a corrected address must be added as a new contact because the cleaned address can't be edited. What you retain matters: the recommendation is to preserve history instead of giving the replacement the old record's apparent clearance. For records you have left unused, inspect the age and basis of the check in relation to the next action. Hunter documents re-verification within stored lead lists, which makes clear that verification needn't end when a contact enters storage. That doesn't establish a universal cleaning interval for every list.

Before sending, resolve the remaining question: does the intended address have an acceptable result and remain eligible for this particular message?

Choose your review cadence from the list's actual use and known changes, then supplement it with event-triggered checks. Address corrections, a newly imported batch and a return to long-unused contacts are reasons to revisit the decision. A name-formatting edit alone needn't trigger a mailbox check. Keep the pre-send review close enough to use that it can catch changes introduced after the import, including newly recorded exclusions. You can't derive a fixed number of days from the documents reviewed here. Your policy needs an owner who can explain when existing evidence remains sufficient and when a fresh check is required.

  • Capture: retain the submitted address and request correction when needed.
  • Import: establish the result’s meaning, age and address association; reconcile exclusions.
  • Contact change: assess the replacement address without transferring old clearance.
  • Pre-send: review uncertainty and confirm the applicable suppression decision.

Check That Verification Changes the Next Action Correctly

Your last step is to inspect what the process permits. A completed verification job is only useful if its results change the contact's next action correctly. These are suggested acceptance checks, not reported test results. Run them against a controlled set of records before relying on the workflow for a live campaign.

Invalid, catch-all, unknown, and retry outcomes

Trace your invalid record through to the send selection and confirm that it is excluded. Then trace your accept-all record and confirm that it retains its uncertainty rather than inheriting the treatment of a confirmed mailbox. Hunter explicitly says accept-all can't fully guarantee deliverability. For an unknown or blocked-verification outcome, give a named owner responsibility for review or another check; don't let the unfinished decision age into automatic approval. A later attempt may supply new evidence, but repeating the check isn't itself a successful result. If the outcome remains inconclusive, the proposed workflow leaves the contact out of ordinary automated sending until its handling is decided. What you are defining is a lifecycle rule, not a prescription for API timeouts or retry code.

Can a result change while its old sending permission remains cached elsewhere? That is the handoff worth checking.

Confirm that blocked records stay blocked

Use your unsubscribed test record in a controlled import check and trace its final eligibility. In Mailchimp, the documented expectation is that an import doesn't change an existing contact's marketing status. If you move it to a different audience or system, verify the transfer of the exclusion explicitly; Mailchimp's same-audience behavior doesn't cover that move. Then follow your cleaned record and a corrected address separately. Mailchimp excludes cleaned addresses from future audience emails and treats the correction as a new contact. The proposed check passes only when the sending decision uses the right address, current evidence and applicable exclusions together. At capture there was a record with an address. At send time you also need a reason that this address, in this state, may move forward.

Frequently asked questions

Should imported addresses be verified again?

Review the original address, verification date and result first. Recheck when the status is unknown, the address has changed or the evidence no longer supports the planned use. Keep subscription and suppression information separate; a new mailbox result does not authorize a send.

Should catch-all results be handled like confirmed valid addresses?

No. Hunter documents that accept-all behavior prevents full confirmation of the individual mailbox. Preserve that uncertainty and apply a separate review decision before ordinary automated sending.

Does a verified address prove that someone owns the mailbox?

A mailbox check and an access-confirmation flow answer different questions. Auth0 describes verifying access to an email and cautions against treating the address as validation of the user’s claimed identity. Record which check was actually performed.