Password reset, magic link, and OTP emails done properly

The expiry column reflects a real trade-off rather than a convention. A short window limits the damage if a mailbox is later compromised, but it also means a message delayed in transit can expire before the user acts on it. Fifteen minutes is comfortable when your p95 delivery is under ten seconds; it is hostile when delivery is unpredictable. The security posture you can afford is a function of the delivery reliability you actually have.

A magic link email is a one-time sign-in URL delivered to the user’s inbox. The user proves mailbox control by opening the link; your app redeems a short-lived token and creates a session. It is the same credential pattern as a password reset — with a tighter expiry, because a successful click is a full login.

Email OTP (one-time password / one-time code) sends a short numeric or alphanumeric code the user types into the app. It is still passwordless proof of mailbox control — without requiring the click to happen on the same device as the browser.

Magic links are a strong default for many consumer and SMB products. They are the wrong sole factor in some environments.

A reset token is a credential that grants account access. It deserves the same handling as a password, and the common shortcuts — predictable values, indefinite validity, plaintext storage — turn a convenience feature into an account takeover path.

A reset form that says "no account with that email" is an account enumeration oracle: an attacker can test addresses against your user base at leisure. The response — status code, body, and visible timing — must be identical whether or not the address is registered. Say "if an account exists for that address, we have sent a reset link" and mean it.

Timing counts. If the known-account path sends an email and the unknown path returns immediately, the difference is measurable. Do the send asynchronously so both paths return at the same speed.

The last row is the one that turns a six-digit code from weak to adequate. A million possibilities is trivially brute-forceable given unlimited attempts and entirely adequate given five. The attempt cap, not the code length, is doing the security work.

A security-relevant email should tell the recipient what was requested, roughly when, and from where, plus what to do if it was not them. That is the difference between a message that helps someone notice a compromise and one that they ignore. Keep it proportionate — an approximate location and a time is useful; a full user-agent string is noise.

Auth mail should reach the inbox in under ten seconds. That budget is spent across several stages, and the one teams forget is usually their own.

The queue row is the most common self-inflicted delay. If password resets are enqueued behind a nightly digest job, the delivery time is however long the digest takes — and the provider’s metrics will look perfect throughout, because from their perspective the message arrived promptly after you sent it. Give auth mail its own priority queue, and measure from the user action so that time is visible.

Greylisting is the stage you cannot control directly. Some receivers defer the first message from an unfamiliar sender and accept the retry a few minutes later, which is precisely long enough to make a fifteen-minute magic link uncomfortable. Established sender reputation is what makes greylisting stop happening, which is another way of saying that auth mail latency is partly a deliverability problem.

Docs copies of these patterns (plus verification) live in the password reset and auth email guide. Prefer plain html / text for critical auth mail so content review stays obvious; if you author with React Email, use the Send React Email guide and keep the rendered body free of trackers and shorteners.

Two details in the password-reset example are deliberate. The from address is on a transactional subdomain rather than the root domain, so auth mail reputation is scored separately from anything marketing sends. And the message carries no unsubscribe link, because this is genuine transactional mail — the RFC 8058 one-click requirement applies to marketing and subscribed messages, and offering to unsubscribe someone from password resets is not a feature.

The shortener rule deserves emphasis. Link shorteners and unnecessary redirect hops are strongly associated with abuse and are routinely penalised by filters — and in a security email they also make the destination unverifiable to a cautious recipient, which is precisely the wrong signal to send in a message about account security.

Most products do not hand-roll authentication anymore. The hosted providers all send mail themselves by default, on their own domains and shared infrastructure, which is fine for a prototype and wrong for production — your users receive account mail from a domain that is not yours, and you have no visibility into whether it arrived.

There are two integration shapes, and the choice is mostly about how much control over the message you want.

Auth mail should be measured on its own, not folded into an overall email dashboard. It is a small fraction of volume and an enormous fraction of the consequences, so aggregate metrics will hide a problem in it completely.

Reset completion rate is the most useful signal on that list because it is measured in your own product rather than in email metrics. It captures the whole path end to end, including the failure modes email metrics cannot see — a message that was delivered to the spam folder counts as delivered but never gets clicked. A sudden fall in the proportion of reset requests that end in a completed reset is a deliverability alarm, and often the earliest one you will get.