When should you re-verify an old prospect list?

Verification expires because the underlying world changes

A list verified four months ago can contain companies that changed domains, people who changed jobs, aliases that were retired, and mailboxes that now reject delivery. The old result was evidence at a point in time, not a lifetime guarantee. Before reusing 730 unsent rows, look at verification age, source, and the decay observed in your own campaigns. Older data deserves a fresh deterministic pass at minimum and mailbox-level re-verification where uncertainty could create preventable hard bounces.

Re-run the cheap checks on every reused file

Normalize addresses again, remove duplicates, confirm domains still resolve for mail, and apply the current central suppression list. These checks are fast and can catch obvious changes without contacting mailbox infrastructure. They also protect against spreadsheet drift: a previously clean export may have been merged with another file or edited manually. Never assume that “the list was verified once” means the current version is byte-for-byte the same dataset.

Use age and provenance to decide how much re-verification is needed

A list sourced yesterday from first-party signups and a four-month-old scraped business directory do not deserve the same confidence. Store `verified_at` and source, then define freshness bands that match observed decay. If older rows from one vendor consistently produce more 5.1.x address failures, shorten their usable window. The purpose of a freshness policy is not to copy an industry number; it is to prevent stale data from becoming a domain-reputation experiment.

Prior delivery can raise confidence but does not freeze state

A successful message six months ago is useful evidence that the mailbox existed then. It does not prove the person still works there now. Keep prior-delivered status as a separate signal and combine it with recency, role changes, and any new suppression events. If a later permanent failure occurs, the suppression should override historical success. Recipient state should move forward with evidence rather than being anchored permanently to the most favorable past event.

Re-verify uncertain segments before the strongest send window

When time or verification cost is limited, prioritize rows with the highest uncertainty: old catch-all addresses, generated email patterns, records from sources with poor bounce history, and contacts whose company domains changed. High-confidence recent rows can move first while the uncertain segment is cleaned. This sequencing protects sender reputation and also prevents a verification backlog from delaying an entire campaign that already contains a clean subset.

Use the first post-reverification batch as a test

Do not send all 730 rows simply because the verifier returned a high score. Start with a bounded tranche and compare hard bounces by verification state and source. If failures still cluster in one subset, stop and investigate before continuing. Verifiers have blind spots, especially around catch-all behavior and temporary server conditions. Real delivery outcomes should update the list model rather than being dismissed because the pre-send tool said “valid.”

Record the decision so the same stale export is not reused again

When a list is re-verified, persist the new timestamp and state back to a central dataset rather than creating another anonymous CSV on a desktop. Mark suppressed addresses and duplicate identities. A future campaign should be able to ask “what did we know about this address and when?” without reconstructing history from filenames. Good hygiene is largely state management: the sender gets safer as evidence accumulates only if that evidence survives between campaigns.

Set re-verification priority from age plus business change

Calendar age is only one reason an address becomes stale. Job changes, company acquisitions, domain migrations and mailbox-provider changes can make a two-month-old export riskier than a six-month-old list from a stable source. Add a simple risk score using list age, source reliability, whether the company domain still resolves, whether the person is still associated with the company, and whether the address has any prior successful or failed delivery history. Re-run deterministic checks on the entire file, then spend deeper verification effort on the oldest or most ambiguous segments. This keeps the process efficient without pretending every address has the same decay rate.

Never overwrite old verification evidence

When a list is re-verified, keep both the prior result and the new result with timestamps. A transition from valid to unknown, catch-all to normal, or clean to suppressed tells you more than the latest label alone. It can reveal a provider change, a stale data vendor or a domain that recently altered mail handling. If the first production batch after re-verification still produces permanent failures, compare those rows with the history and source. The goal is not to create an eternal database of every probe; it is to retain enough evidence to explain why the system believed an address was eligible at send time. That audit trail also prevents a later import from resurrecting a contact whose newer state is worse than the older export.

Reverify before queueing, not after the campaign is scheduled

An old export should be cleaned before thousands of send jobs are created. Re-run deterministic validation, apply global suppression, refresh the riskiest mailbox checks, then build campaign state from the resulting eligible set. If verification happens after queue creation, stale jobs can remain scheduled even when the address later becomes invalid or suppressed. Keep the original import row for traceability, but let only the current verified-and-eligible state create a sendable job. This ordering reduces wasted queue work and makes the first production batch a test of current data rather than a mixture of old assumptions and new corrections.

Create an expiry rule for verification evidence

Each verification result should carry an “observed at” timestamp and an internal expiry policy based on the source and risk level. A recent successful delivery may remain useful longer than a one-time mailbox probe on a catch-all domain. A prior hard bounce should not expire automatically at all unless there is deliberate evidence that the address changed ownership or was corrected. The expiry rule does not need to be mathematically perfect; it needs to stop a two-year-old green badge from looking as trustworthy as a result collected last week. This makes reuse decisions consistent across campaigns.

Field checklist

• Treat verification as time-bound evidence, not a permanent guarantee.
• Re-run normalization, domain checks, deduplication, and suppression on every reused list.
• Prioritize old catch-all and weak-source rows for mailbox-level re-verification.
• Let new permanent failures override prior successful-delivery history.
• Test a bounded tranche after re-verification before exposing the full old list.
• Persist updated verification and suppression state centrally.