Verify an email list again when the last result is too old for the decision you are about to make, or when a new signal calls that result into question. For a campaign, make that decision before the send. For a CRM record you are not using yet, keep the last result and its date so you can decide later. There is no interval that makes every address safe for a month or unsafe on day 31.
Set the maximum age of verification evidence for each use case. Check it when the address is about to be used, and bring the next check forward after a bounce, address change or long pause in sending. The interval is your operating policy, not an expiry date supplied by Emvero.
Decide at the point of use
Ask three questions about the segment you plan to use:
- When was the evidence gathered? Keep the last status and observation times with the address. The date you imported a CSV or fetched a cached response is not the date of the underlying check.
- What has changed since then? A corrected address needs its own check. A bounce, new domain, or resumed campaign after a long pause makes earlier evidence less useful. An unsubscribe or suppression is a separate sending decision; a fresh
deliverableresult does not cancel it. - What will you do next? A welcome message during signup, a campaign to an old segment and a dormant CRM record do not have the same deadline or cost of a wrong decision. Choose an evidence-age limit for each workflow and review it against your own bounce and response data.
For example, a team could require evidence gathered within 14 days of approving a campaign. That is an illustrative local rule, not a recommended validity period or a claim about how quickly mailboxes change. An address checked three days before approval passes the age rule; one checked five weeks earlier needs another check. Both still need the other sending permissions and suppressions to be satisfied.
| What you know before the next use | Timing decision |
|---|---|
| The segment was checked recently under your own rule, and no new negative signal appeared | Keep the recorded result for this decision; review again at the next point of use. |
| The list has been idle or imported without a trustworthy check date | Verify before the next send rather than treating the import date as evidence. |
| An address changed, or a delivery report shows a bounce | Review the cause and keep the affected address out of the send while you investigate. Check the corrected address as a new address; do not use a new result to erase a known opt-out or sending failure. |
The last attempt returned unknown or is still pending |
Keep it out of a decision that needs a settled answer. Retry or retrieve the same pending verification as appropriate; neither state means undeliverable. |
The guide to cleaning a list before a send covers what to do with a current deliverable, risky, undeliverable or unknown result. This timing rule decides when to ask for that result again.
Read the observation times, not the retrieval time
Emvero returns freshness.dns_checked_at and freshness.smtp_checked_at where those checks produced evidence. DNS routing and SMTP recipient observations can have different timestamps. A cached response retains the time the evidence was gathered; fetching it again does not renew either observation. The article on reading a verification result explains the fields and their limits.
Record the result, its observation times and the decision made from it. If a new check is inconclusive, keep the earlier observation and its original date for audit history, while treating the new unknown as the latest inconclusive attempt. Do not silently label the old deliverable result as fresh. If the response is pending, retrieve that same verification after the returned retry interval before making a terminal decision.
A full check may gather recipient evidence without sending a message. The receiving server can still hide the answer, and even an accepted recipient is no promise of future delivery or proof that the person controls the mailbox. Choose a fresh-evidence window for the decision you face, then leave room for those limits.
Keep permission separate from address evidence
Verification helps you judge whether mail may reach an address. It does not establish that someone asked to receive your campaign. A contact who unsubscribed stays suppressed even if a later check returns deliverable. For messages to personal Gmail accounts, Google’s sender guidance asks senders to confirm each recipient’s email address before subscribing them and make unsubscribing easy.
Likewise, a bounce report is a new event to investigate, not a reason to run the same address through verification indefinitely until it returns a favourable result. Keep the sending event, the verification result and the consent record as separate pieces of evidence.
If you need to recheck a list you manage yourself, the CSV-to-API workflow shows how to send one server-side request per address, resume pending work and write each result back to its source row. Set the timing rule first so the job checks the addresses whose evidence is actually due for review.