Password reset not working: find the cause

The user asks for a reset, gets the email within moments, and taps the link. The page says the link is invalid or expired, and a second request gives the same result. Some of these links are opened first by a mail gateway that scans links in incoming mail, and a one-time token can be spent by that scan. Others are cut by an email client that wraps a long address, or built with a staging host the phone cannot reach. An owner who tests from a laptop, in the browser that asked for the reset, usually sees it work.

• Does the link show as expired within moments of the email arriving, before anyone tapped it?
• Does the link in the email start with your live address and run to the end without a line break?
• Does the reset page work in the browser that asked for the reset, and fail in a different one?
• Does the form reject a new password with a message that names the rule it broke?
• Does a second request send no email and show a too many attempts message?

Mail gateways and some security tools open the links in an incoming message to check them. A reset link that is valid for one use is spent on that first visit. When the person taps the link, the page finds a used token and says the link has expired. The server log can show it: a request from an unfamiliar browser or a data center address arrives moments after the email was sent, and the person's own visit comes second and fails.

The fix is to stop spending the token on a page load. Check the token when the page opens, then spend it only when the new password is submitted. A prefetch reads the page and leaves the token alone, and a real tap still works. Test that by opening the link once without submitting, then completing the reset from the same link.

A long link can break in the mail client. A line wrap can insert a space, a full stop can attach itself to the token, or a copied link can lose its last characters. The page then receives a token one character short and reports it as invalid, which looks the same as an expired link. Open the email's link text and compare its length and its last characters with the link the app generated.

The host is the other common break. A reset link built from a staging address or localhost opens nothing on a phone, while a link that starts with your live address works. Read the start of the link in the message. It should match the address your users type, with no preview name in front. The setting that builds it is usually a base address in the app's configuration, and that value often differs between environments.

Some apps tie the reset form to a cookie set when the reset was requested. If the link opens in a different browser, such as a phone when the request came from a laptop, the form sees no matching cookie and rejects the submit, sometimes with a message that never mentions cookies. The person then assumes the link is broken. Test both places: request the reset on a laptop, open the email on a phone, and submit the form.

A new password can also fail quietly. A form that checks length, a symbol and repeated characters may show its rule under the field, out of view on a phone. A password manager can generate a password that breaks one rule, and the person sees only a field that will not save. Show each rule beside the field, and name the one that failed.

A changed login rule, a new email template or a move to a different mail service can break resets again, while sign in and signup still work. Rerun the reset from a new account after each change, from a laptop and a phone, and read the link before tapping it. Owners also test a web app behind a site password and check each preview deploy first.