A password reset email should identify the app, explain the requested action, offer one clear reset link, state the actual expiry, and explain what to do if the recipient did not request it. The template presents the flow; the server must enforce it.
Start with the template, then match your actual behavior
Our password reset template includes a descriptive subject, a visible button, a plain-text fallback URL, and a concise explanation for an unexpected request. Download both HTML and text versions without an account. The preview uses synthetic details.
Replace the application name, reset URL, expiry description, and support contact. Do not ship a claim that a link expires in 30 minutes if your backend uses a different duration. Do not say that a password has changed when this email only offers a reset.
Make the subject and first sentence do the work
Keep promotional content out of this flow. A person trying to recover access needs one decision. A receipt, release announcement, and reset request have different jobs; combining them makes the important action harder to find.
| Element | Suggested copy | Why it helps |
|---|---|---|
| Subject | Reset your {{app_name}} password | Names the action and the app without invented urgency. |
| Opening | We received a request to reset your password. | Explains why the message exists. |
| Button | Reset password | Describes the destination instead of “Click here.” |
| Expiry | This link expires in {{expiry_minutes}} minutes. | Sets an expectation tied to the real token lifetime. |
| Unexpected request | If you did not request this, you can ignore this email. | Avoids asking an uninvolved person to act. |
The server owns the security properties
Use cryptographically random, single-use tokens with a bounded lifetime. Store tokens securely and validate them on the server. Return a consistent reset-request response whether or not an account exists, and apply abuse controls to the request endpoint.
Construct reset URLs from a trusted configured origin, not an arbitrary Host header. Complete the change only after the user submits the reset form. A link scanner may visit the URL before the person does, so merely opening a link should not change the password or consume the reset action.
Keep tokens out of analytics URLs, application logs, and third-party page assets. Decide how existing sessions are handled after a successful reset and communicate that behavior accurately. These controls belong in the account system; changing an email template does not implement them.
Design for the email that actually reaches the reader
A conservative table layout and inline styles make a useful starting point. Use readable body text, sufficient contrast, meaningful link text, and a comfortable touch target. Keep essential instructions in text so they remain visible when images do not load.
Include the same action and expiry information in the plain-text version. Test long app names, unusually long URLs, localization, narrow screens, and a reader with images disabled. A layout that looks good with “Acme” can break with a real organization name.
The library previews are browser previews. They are not a claim of coverage across Outlook, Gmail, Apple Mail, or every dark-mode implementation. Test the final rendered message in the clients your users actually use.
Treat delayed delivery as part of the reset experience
A reset email arriving after its link expires creates a frustrating loop. Track queue age separately from server acceptance and decide what the application should show when a previous request is still pending.
For a new user-requested reset, define whether previous tokens remain valid or are invalidated. Reusing a delivery idempotency key for a genuinely new reset request can suppress the new message; generating a new key for a network retry can duplicate the old one. Use the reset request’s own stable ID.
When a user reports a missing reset, collect the specific request time and message identifier rather than asking them to request repeatedly. The delivery troubleshooting guide shows how to work through the handoffs.
Before putting the template into production
- Render with realistic long values and verify no unresolved placeholders remain.
- Check that the URL uses your approved HTTPS origin and includes only the intended token.
- Confirm one successful reset, an expired token, a reused token, and an unsolicited request.
- Inspect HTML and plain text; verify that both describe the same action.
- Run a controlled delivery check and record authentication results without exposing the token.
Sources and further reading
Written for Stampwing with AI assistance and checked against the linked documentation. Examples are educational; simulated results are labelled. How these resources are maintained.