Email verification test cases, past did the mail arrive

Verification exists to prove that somebody controls an address, and the token lifecycle is what makes that proof meaningful. A token that can be used twice, that never expires, or that stays valid after a newer one is issued does not prove present control: it proves someone had access to that inbox at some point, possibly years ago on a shared or recycled address. Single use, short lived, and invalidated on reissue are three separate cases and all three are commonly missing.

The enumeration case is the one teams argue about and should not. If requesting verification for a registered address produces different wording, a different status, or a measurably different response time than an unregistered one, the endpoint tells an attacker which addresses hold accounts. That list has value on its own and it is the first step in a credential stuffing campaign. The same applies to registration: attempting to register an address that already exists must not confirm that it exists, and the existing owner should be told that somebody tried.

Mail infrastructure introduces failures that have nothing to do with the application logic. Corporate scanners prefetch links, so a token consumed by an automated GET leaves the genuine user with a dead link and no idea why. Clients rewrite URLs and wrap plain text at fixed widths, which breaks tokens that are too long or not URL safe. And the link will frequently be opened in a different browser from the one used to register, because mail clients open links in their own, so any flow that requires the original session fails for a large share of real users.

Finally, the address change flow is a takeover path and needs its own care. The old address has to stay active until the new one is verified, otherwise a typo locks the user out permanently. The old address has to be notified of the request, because that notification is what surfaces a takeover in progress. Re-authentication has to be required, because changing the address is the first move an attacker makes on an unattended session. And the verification link needs its redirect target validated, or it becomes an open redirect wearing a trusted domain.