Password reset emails: what actually needs to be in them

A password reset email gets more scrutiny than almost any other transactional message, both from the user (are they expecting it?) and from mailbox providers (it's a common phishing target, so filters watch this category closely). The actual requirements are short.

What actually matters

• A time-limited link, not a permanent one. Expire it, typically within an hour, and say so in the email
• Never include the user's actual password, current or new, in the email body, even partially
• A clear, recognizable from address and subject line, since this is exactly the kind of email a phishing attempt mimics, and an unfamiliar sender pattern trains users to distrust legitimate ones
• A note that says what to do if the user didn't request this, since a reset request they didn't make is a signal worth surfacing to them

Single-use tokens, not just time-limited ones

Expiry alone isn't enough: the reset token should also be invalidated the moment it's used once, so a link sitting in an inbox or forwarded accidentally can't be reused later within its expiry window. Generate a cryptographically random token, store a hash of it (not the raw token) server-side, and mark it consumed on first successful use, the same one-time-use discipline as the underlying idea behind magic-link login.

Rate-limiting reset requests

Without a limit, an attacker can trigger repeated reset emails to a target's inbox as a low-grade harassment or distraction tactic, or to probe which email addresses are registered accounts at all. Rate-limit reset requests per account (a handful per hour is usually generous enough for a legitimate user who fat-fingered a request) and return the same response whether or not the address exists, so the endpoint doesn't leak which emails are registered.

What's decoration, not a requirement

Elaborate branding, marketing content, or unrelated account information don't belong in this email. It's a single-purpose, high-trust message. The more it looks like every other marketing email your product sends, the harder it is for a user to distinguish it from an actual phishing attempt spoofing your brand.

Mobile app deep linking

If the reset flow needs to open directly in a mobile app rather than a browser, use a universal link (iOS) or app link (Android) with a web fallback, not a custom URL scheme alone, since custom schemes are easier to spoof by a malicious app registering the same scheme. Test the fallback path explicitly: a user opening the email on a device without the app installed should land on a working web version of the reset flow, not a broken deep link.

The deliverability angle

Password reset emails are pure transactional mail, sent one-to-one, time-sensitive, and expected by the recipient. They should never be batched with marketing content or sent through a bulk-marketing path, both because it's the wrong tool (marketing tools optimize for throughput, not per-message latency) and because mixing transactional and marketing traffic on the same sending reputation is exactly the pattern that gets flagged by spam filters.