---
title: "How Often Should You Verify an Email List? | Emvero"
description: "Choose when to reverify an email list using the age of its evidence, your next send and new bounce or address-change signals."
url: https://emvero.io/blog/when-to-reverify-email-list/
language: en
updated: 2026-10-07
---

Blog

# When to verify an email list again

Use the next send and the age of your last check to decide when a list needs new evidence. A calendar reminder alone cannot make an old result current.

Published 2026-09-24

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:

1. **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.
2. **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 `deliverable` result does not cancel it.
3. **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](https://emvero.io/guides/cleaning-an-email-list/) 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](https://emvero.io/blog/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](https://support.google.com/mail/answer/81126?hl=en) 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](https://emvero.io/blog/validate-email-list-csv-api/) 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.

## Terms used here

### Hard bounce and soft bounce

Common labels for permanent and temporary delivery failures; neither label alone explains the cause.

### Greylisting

A receiving-server policy that temporarily defers an unfamiliar SMTP attempt; a later attempt may pass.

## Situations this applies to

### Cleaning a list before a send

You are protecting the reputation of the sending domain, so the question is not which addresses are bad but which ones this send can afford.

### Cleaning a CRM without deleting good records

A CRM record is a history, not an address, so nothing here deletes anything - verification decides what you may send, never what you may keep.

[All articles](https://emvero.io/blog/)

## Choose what to check next.

Run a check from your account and inspect the evidence in its result.

Start for free