A password reset email is only a few lines long, yet it sits in one of the most stressful product moments. The recipient may be locked out, worried about an unexpected request, switching between devices, or racing an expiring link. A polished hero image will not rescue vague identity details or a button that fails in Outlook.
Treat the email as one state in an account-recovery system, not an isolated template. Emailify lets teams design responsive emails in Figma, preview mobile layouts, and export production-ready HTML for major email clients and email platforms. Product and security teams still need to define the trigger, token behavior, safe content, and recovery path.
Map the complete recovery sequence
Start with the system events, because the HTML cannot fix confused logic later:
- a person requests a reset;
- the product responds without exposing whether an account exists;
- an email is sent to an eligible address;
- the recipient opens a single-purpose link;
- the token is accepted, expired, already used, or superseded;
- the password changes successfully or the user needs another route;
- the account receives a security confirmation if policy requires it.
Document token lifetime, whether a newer request invalidates older links, and what happens when the email is opened on a different device. Decide which support path is safe for people who no longer control the address.
This differs from an account verification email. Verification proves control during signup or an identity change. Password reset restores access to an existing account and needs stronger treatment of unexpected requests, expiring tokens, and post-reset security.
Write for urgency without creating panic
The subject and opening should name the event plainly. For example:
- Subject:
Reset your Acme password - Preheader:
Use this secure link within 30 minutes. - Heading:
Choose a new password
Avoid alarming claims such as “Your account has been hacked” unless the system actually detected compromise. Also avoid cheerful marketing language. The reader needs a trustworthy route back into the product.
The body should answer:
- which product or workspace the request concerns;
- when the link expires;
- what the primary action does;
- what to do if the request was unexpected;
- where to get legitimate support;
- whether the message is automated and replies are monitored.
Do not include the recipient’s current password, secret recovery answers, sensitive account data, or a raw token in visible copy. Be cautious with IP addresses and location guesses: they can reassure some users but create false certainty when networks, VPNs, or geolocation data are imprecise.
Make the primary action unmistakable
Use one dominant button, such as “Reset password.” Keep secondary help links visually separate. The button label should describe the next action, not say “Continue.”
The destination should be HTTPS, use the intended trusted domain, and perform one recovery job. If a security gateway rewrites links, test the real sending path. Never print a long tokenized URL as fallback copy unless the security team has explicitly approved that pattern; forwarded emails and screenshots can expose it.
Link expiry belongs near the button, not hidden in a footer. Use an absolute duration that matches system behavior. If tokens can expire early after another request, explain that the newest email should be used.
Design hostile but realistic content states
Create Figma fixtures for:
- a short and very long product or workspace name;
- a long localized button label;
- light and dark mode;
- images blocked;
- narrow mobile width;
- 200% text zoom;
- support link present and absent;
- a security notice with two lines and with six lines.
The reset action cannot depend on an image. Use live HTML text for the product name and instructions. Add meaningful alt text only where an image conveys information; decorative logos should not make a screen reader repeat the brand unnecessarily.
For broader layout checks, use the mobile email QA workflow. The password reset template should remain deliberately simple: clarity, link reliability, and recognizable identity matter more than campaign-style modules.
Keep production data out of the design
Define placeholders with engineering and email operations before export. A small contract might include:
| Placeholder | Example fixture | Required behavior |
|---|---|---|
| product name | Acme Cloud | escaped text, controlled length |
| reset URL | test-domain link | generated server-side, single purpose |
| expiry | 30 minutes | matches token policy |
| support URL | help center route | approved, non-tokenized destination |
Use obvious fake values in Figma and test sends. Never paste a live reset token or customer email address into design layers, tickets, or screenshots.
Export and test the actual HTML
After the design is approved, export from Emailify and connect the placeholders using the platform’s supported workflow. Then send through the real authentication system in a non-production environment. A generic preview send does not prove that token substitution, link rewriting, tracking policy, and expiry handling work together.
Test:
- Gmail, Outlook, Apple Mail, and the mobile clients your users rely on;
- button and text-link behavior with tracking and security scanning enabled;
- dark mode and images-off rendering;
- keyboard navigation and visible focus;
- screen-reader order and link purpose;
- the newest and an older superseded email;
- expired, already-used, and malformed tokens;
- cross-device completion;
- the confirmation message after a successful change.
The Outlook rendering checklist can help with client-specific HTML problems, but functional token testing must happen in the application stack.
Security and launch checklist
Before release, confirm that:
- the response to an unknown address does not reveal account existence;
- the subject, sender name, and sending domain are recognizable;
- the email contains one clear recovery action;
- expiry copy matches real token policy;
- unexpected-request guidance is calm and actionable;
- no secret or customer data appears in design fixtures;
- reset links are generated, scoped, and invalidated as intended;
- HTML works with images blocked and at narrow widths;
- accessible names, focus order, contrast, and zoom have been checked;
- security, product, support, and email operations agree on escalation paths;
- real client tests and end-to-end recovery tests both pass.
The best password reset email feels almost boring: recognizable, specific, and dependable. That restraint is a feature. Design it in Figma, export robust HTML with Emailify, and prove the entire recovery path before someone needs it during a genuine lockout.
Read as Markdown Related resource index Site index for AI agents
Pro Bundle