How Often Should You Reverify Email Addresses?

Short answer: there is no universal number of days after which every email address must be verified again. Reverify when the address changes, when an earlier check was inconclusive and its retry window has passed, or when old evidence is about to support a higher-risk decision.

A fixed 30-, 60-, or 90-day rule looks tidy. It also ignores the evidence you already have. An address that received a message yesterday is different from an address that has been dormant for two years, even if both were last checked on the same date.

I would treat verification as a timestamped observation, not a permanent property of a contact.

Use events before you use a calendar

The best recheck trigger is usually a change in context. The calendar is a fallback for records that have gone quiet.

This distinction matters because a verification result and a delivery event answer different questions. A check estimates whether an address appears reachable at that moment. A delivery response reports what happened to a particular message. Neither proves that the person currently controls the inbox.

What does “stale” mean for an email result?

A result is stale when it is too old for the decision you are about to make, not merely when it crosses an arbitrary birthday.

That makes freshness a policy decision with three inputs:

1. Evidence age: when was the address last checked, delivered to, or rejected?
2. Evidence quality: was the result deliverable, risky, undeliverable, or unknown, and what reason supported it?
3. Decision cost: are you sending one expected account message or reactivating a large dormant segment?

EmailVerifier.dev keeps confirmed outcomes, risk signals, and unknown results distinct. Preserve that distinction in your own database. Turning every non-deliverable result into one boolean destroys the information you need to schedule a sensible retry.

For example, the email standards distinguish temporary failures from permanent ones. RFC 3463 says a 4.x.x status may succeed in the future, while a 5.x.x status is unlikely to succeed without changing the message or destination. Your recheck policy should not treat those classes alike.

A worked lifecycle is more useful than a fixed interval

Consider this hypothetical SaaS account:

1. Signup: alex@example.com returns deliverable. Store the result, reason, and checked_at time.
2. Normal use: account emails continue to reach the address. Keep the latest successful delivery event. Do not spend a verification credit just because 30 days passed.
3. Dormancy: the account goes quiet for a long period. Before a reactivation campaign, compare the latest evidence with the age limit your team chose for that type of send. Reverify if it is too old.
4. Address change: Alex enters alex@new-example.com. Treat it as a new identity claim. Verify the address as input, then send a confirmation link to establish control. OWASP recommends keeping a proposed new address pending until the change is confirmed.
5. Later permanent failure: a real send returns a recipient-address failure such as 5.1.1. Apply the relevant suppression. Do not keep rechecking until a service happens to return a more convenient answer.

This sequence avoids two common mistakes: paying to recheck an address when fresh delivery evidence already exists, and using verification to overrule consent or bounce handling.

Store evidence, not just the latest verdict

A production record needs enough history to explain why the next action is allowed. At minimum, I would keep:

• the normalized address and a stable contact or account ID
• the verification status, reason, provider, and checked_at time
• the latest successful delivery time
• the latest SMTP or DSN failure class and time
• the ownership-confirmation state
• the consent state and any unsubscribe, complaint, or bounce suppression

Do not collapse those fields into email_valid = true. A single boolean cannot tell you whether the evidence is old, inconclusive, superseded by a bounce, or irrelevant because the recipient opted out.

If you operate a suppression list, make its precedence explicit. Our event-driven suppression model separates contact-, list-, message-, and global-scoped decisions. Reverification can add new reachability evidence, but it must not silently delete those events.

When should an unknown result be retried?

Retry an unknown result only after the condition that made it unknown could plausibly have changed. Use backoff, cap the number of attempts, and preserve the last reason.

That may mean waiting after a timeout, greylisting response, DNS failure, or provider policy block. The exact cooldown depends on the failure and your workload. RFC 5321 requires mail senders to retry transient delivery failures with delay, and our greylisting walkthrough shows why an immediate repeat can return the same 451 response.

The fair objection is that a simple 90-day cron job is easier to operate. It is. But simple does not have to mean blind. Keep a default maximum age for dormant records, then let stronger events override it: a recent delivery can postpone a check, an address edit can force one, and a suppression can block sending regardless of the latest verification result.

The policy I would ship

Start with one rule: reverify only when the current evidence is insufficient for the next decision.

Then encode four precedence levels:

1. Consent, complaint, and suppression rules decide whether you may send.
2. Permanent delivery evidence can stop sending to a destination.
3. Recent successful delivery can refresh confidence without another verification call.
4. Verification age and status decide whether a dormant or newly changed address needs another check.

That policy is cheaper than checking every record on a timer, and more honest than pretending one age threshold fits every workflow. Most importantly, it keeps verification in its proper role: one piece of time-bound evidence, not a permanent promise about an inbox.