Password Reset Email Template: Copy, Examples & Best Practices
Copy a password reset email template, adapt it for your product, and apply practical security, UX, deliverability, and automation guidance for SaaS teams.
In this guide
A password reset email template gives locked-out users a clear, secure path back into their account with a prominent reset link, an expiration notice, and a way to report suspicious activity. This guide gives you a ready-to-copy template, a breakdown of every element to include, safe automation practices, and examples for different account-recovery scenarios.
For a SaaS founder, developer, or info-product creator sending your own transactional messages, a solid password reset email template is one of the highest-leverage pieces of copy in your whole product. It is short, it is read almost instantly, and if it fails, the next thing that happens is a support ticket (or a churned user). Below you'll find a template you can paste directly into your email tool, a checklist of what each section needs, guidance on automating the flow securely, and a set of examples adapted to common account-recovery situations.
Password Reset Email Template to Copy and Customize
Use this template as your starting point. It works for SaaS apps, info-product membership sites, and any platform where users log in with an email and password. Replace every bracketed placeholder with your own copy before sending; never leave a placeholder in a live email.
Subject: Reset your password for [Product/Company Name] Preheader: This link expires in [expiration time, e.g., 30 minutes]
Hi [User's First Name or "there"],
We received a request to reset the password for your [Product/Company Name] account associated with [user's email address].
Click the button below to choose a new password. This link will expire in [expiration time].
[Reset Password Button / Link]
If you didn't request this change, you can safely ignore this email, your password will not be changed. If you're concerned about your account's security, contact us at [support email or help center link].
Thanks, The [Product/Company Name] Team
Here is how to fill each part:
- Subject line: state the action plainly ("Reset your password"), include your product name so it's recognizable in a crowded inbox.
- Preheader: surface the expiration window immediately; it reduces the chance a user opens the email too late and has to request a new one.
- Greeting: use the user's first name when you have it; fall back to a neutral greeting rather than inventing a name.
- Reset link or button: this should be the single, obvious call to action on the page. Avoid competing links or unrelated promotions in the same message.
- Expiration notice: repeat the time window in the body, not just the preheader, so it's visible even if the client strips preview text.
- Fallback instruction: tell users what to do if they didn't request the reset. This single line prevents a lot of confused support emails.
- Sign-off: keep it short and consistent with the rest of your lifecycle emails so the message feels like it genuinely came from your product.
Completed example for a project-management SaaS tool:
Subject: Reset your password for Flowtrack Preheader: This link expires in 30 minutes
Hi Maria,
We received a request to reset the password for your Flowtrack account associated with [email protected].
Click the button below to choose a new password. This link will expire in 30 minutes.
[Reset Password Button]
If you didn't request this change, you can safely ignore this email, your password will not be changed. If you're concerned about your account's security, contact us at [email protected].
Thanks, The Flowtrack Team
What to Include in a Password Reset Email
A password reset email is a transactional email, not a marketing message, so it should be judged on clarity and speed, not persuasion. The table below summarizes the elements every template needs and why each one matters.
| Element | Purpose | Common mistake to avoid |
|---|---|---|
| Clear subject and sender name | Lets the user instantly recognize and trust the message in a busy inbox | Using a generic "no-reply" sender with no product name |
| Single reset link or button | Removes any ambiguity about what action to take | Adding multiple links or unrelated CTAs in the same email |
| Expiration time | Limits the window during which a stolen link could be used | Omitting the expiration or burying it in fine print |
| Fallback instruction | Reassures users who did not request the reset | Leaving no explanation for an unexpected email |
| Support contact | Gives users a path to help without guessing | Pointing to a generic contact page instead of a direct channel |
A few additional details are worth calling out explicitly, since they're frequently skipped:
- Original URL as plain text: alongside the button, include the raw reset URL as visible text. If a user forwards the email, replies to it, or their client strips HTML buttons, the link still works and remains traceable to the right request.
- Consistent "from" address: use the same sending domain and display name across every transactional email so spam filters and users alike learn to trust it.
- No sensitive data in the email: never include the user's current password, security questions, or full account details, the email should only ever grant access to a secure reset page, never expose information directly.
- Mobile-first layout: most password reset emails are opened on a phone, in a moment of friction, so the button needs to be tappable and the copy needs to be scannable in a few seconds.
How to Automate Password Reset Emails Safely
Automation is what makes a password reset email arrive within seconds of the request, which is exactly when users expect it. But speed without security creates risk, so the automation logic matters as much as the copy. Here is a practical sequence to follow:
- Generate a single-use, time-limited token on the backend the moment a user requests a reset, rather than reusing any existing credential.
- Trigger the email through your transactional sending pipeline, separate from your marketing campaigns, so deliverability and reputation for account-recovery messages stay isolated from promotional sends.
- Embed the token in the reset link and populate the rest of the template programmatically (user's first name, expiration time, support contact).
- Send immediately, since every extra minute of delay increases the chance the user gives up and opens a support ticket instead.
- Invalidate the token as soon as it's used once, or as soon as its expiration window passes, whichever happens first.
- Log and rate-limit reset requests per account to prevent automated abuse, such as repeated reset attempts used to probe for valid email addresses.
For teams building this flow themselves, the practical choice is usually between a visual workflow builder and a direct integration. If your app already has a backend, calling a transactional email API from your signup and authentication service gives you full control over when the token is generated, how it's validated, and exactly what data gets passed into the template, without relying on a separate no-code tool for a security-sensitive flow.
Whichever path you choose, test the full loop end to end before shipping it: request a reset, confirm the email arrives promptly, click the link, confirm the token is invalidated after use, and confirm an expired or reused link fails gracefully with a clear message rather than a broken page.
Password Reset Email Examples for Different Use Cases
Not every account-recovery moment is the same. A simple "I forgot my password" click calls for a different tone than a security alert about a suspicious login. The table below outlines how to adapt the base template to common scenarios.
| Use case | Trigger | Tone and key addition |
|---|---|---|
| Standard forgotten password | User clicks "Forgot password" on the login screen | Neutral and brief, exactly as in the base template above |
| Suspicious login alert | Login attempt from a new device or location | Slightly more cautious tone, mention the detected activity, and offer a reset as a precaution rather than a demand |
| Mandatory credential update | Admin-enforced password policy change or expiration | Explain the reason briefly (policy update, scheduled rotation) and the deadline for compliance, if one applies to your product |
| Post-incident notification | A security event affecting multiple accounts | Direct and transparent language, clear next step (reset now), and a visible support contact for follow-up questions |
A couple of adaptation examples, built on the same base structure:
Suspicious login variant:
Subject: New sign-in detected on your [Product Name] account Hi [First Name], we noticed a sign-in attempt from a device or location we haven't seen before. If this was you, no action is needed. If you don't recognize this activity, reset your password now using the link below. This link expires in [expiration time].
Mandatory update variant:
Subject: Please update your [Product Name] password Hi [First Name], as part of our account security policy, we're asking you to set a new password. Use the link below to choose a new one before [deadline, if applicable]. This link expires in [expiration time].
Both variants keep the same backbone as the original template: one clear action, a visible expiration window, and a fallback instruction, only the opening line and context change. This consistency matters for recognition: a user who has seen your standard reset email before will immediately understand the alert version, because the layout and sender feel familiar.
If you're building out a broader set of account and lifecycle messages (welcome emails, password-change confirmations, account-update notices), it's worth keeping all of them visually and structurally consistent with your reset flow. Browsing a set of lifecycle email templates can help you match the tone and layout across the full account journey, rather than designing each transactional message in isolation.
Whatever variant you ship, the core discipline stays the same: one action, one link, a visible expiration, and a clear way to get help. Get those four things right in your password reset email template, and you've handled one of the most important, if least glamorous, moments in your product.
Frequently asked questions
When should you use a password reset email template?
Use a password reset email template whenever a user requests help recovering access to an account. It provides a consistent structure for the subject line, explanation, reset button, fallback URL, expiration notice, and support guidance. Customize the wording, branding, sender details, and security instructions to match your product. Keep a separate version for unusual cases, such as administrator-assisted recovery, social login accounts, or situations where users cannot reset their password through the standard flow.
How should you fill in the placeholders in a password reset email template?
Replace each placeholder with verified product data before sending the message. Typical fields include the recipient’s name, product name, reset URL, expiration information, support contact, and sender name. Generate the reset URL dynamically for the specific request, and never reuse a static link. Use a fallback URL that users can recognize, but avoid placing passwords, security answers, or other sensitive information in the email. Test rendered values and missing-field behavior before activating the template.
What should the subject line say in a password reset email?
Use a clear, recognizable subject such as “Reset your password” or “Password reset request for [Product].” The wording should tell recipients what happened without creating unnecessary urgency or revealing sensitive account details. Keep the product or company name visible so users can identify the sender. If your system sends a message after a password change, use a different subject, such as “Your password was changed,” to distinguish confirmation emails from reset requests.
Should a password reset email include the original reset URL?
Include a reset URL only when it is the secure, user-specific link generated for that request. A prominent button can improve usability, while a visible plain-text fallback URL helps recipients whose email client does not render HTML correctly. Do not include the user’s current password, reusable credentials, or a generic reset page that exposes unnecessary account information. If the link is copied into another message or support ticket, treat it as sensitive and design it to expire after use.
How long should a password reset link remain valid?
A reset link should remain valid only long enough for a legitimate user to complete the process, according to your security policy and risk level. Configure it to expire after a short period, make it single-use, and invalidate earlier links when a newer request is issued when practical. Show the expiration behavior clearly in the email and provide a safe way to request another link. Avoid promising an exact validity period unless your product consistently enforces it.
Can a password reset email be sent as plain text?
Yes. A plain-text password reset email can be accessible, reliable, and easier to inspect, provided it contains the essential information in a logical order. Include the product name, reason for the message, reset URL, link-expiration guidance, security advice, and a support path. Many teams send multipart email with both HTML and plain-text versions, allowing the recipient’s email client to choose the appropriate format. Keep both versions consistent and test links, line wrapping, and readability.