Magic Link Email Template for Passwordless Sign-In
A magic link is both a login action and a security signal. The email must be short enough to use under pressure while giving the recipient enough context to reject an unexpected request.
Event contract
| Field | Example | Rule |
|---|---|---|
| Product | Sequenzy | Name the service |
| Requested address | maya@example.com | Show a masked or full address according to policy |
| Requested time | 14:05 UTC | Localize for the recipient when useful |
| Device or location | Chrome on macOS | Include only if reliable |
| Link | One-time authenticated URL | Single-use and short-lived |
| Expiry | 15 minutes | State the real server expiry |
| Security contact | Support or security address | Provide for unexpected requests |
Never include a reusable password or secret in the message.
Template
Subject: Sign in to {{product_name}}
Preheader: This secure link expires in {{expiration_minutes}} minutes.
Hello,
You requested a sign-in link for {{product_name}}.
[Sign in securely]
This link expires in {{expiration_minutes}} minutes and can be used once. If you did not request it, you can ignore this email. If you think someone is trying to access your account, contact {{security_email}}.
Request details: {{request_context}}
{{company_name}}
Wrong-device and expired-link paths
A user may request the link on a laptop and open it on a phone. Decide whether the product supports cross-device completion. If it does, bind the token to the account and session policy rather than a fragile browser cookie. If it does not, explain how to request a new link without leaking account existence.
For an expired or already-used link, show a generic recovery page with a “send a new link” action. Do not reveal whether an email address is registered to an attacker.
Security rules
- Generate a cryptographically random, single-use token.
- Expire it server-side, not only in the UI.
- Rate-limit requests and delivery.
- Invalidate older links according to the product’s session policy.
- Do not log the full token.
- Use an authenticated, HTTPS destination.
- Send from a stable security identity.
Suppress duplicate sends only when the product intentionally groups requests. Otherwise, make each request visible and ensure only the valid token policy controls access.
QA checklist
- Link expires when the copy says it does.
- Used links cannot be replayed.
- The wrong account cannot consume the token.
- Multiple requests do not expose account existence.
- The message works in plain text and mobile mail clients.
- Unexpected-login copy has a real support path.
For numeric authentication, use the 2FA email template or verification code template.
Product decisions to document
Passwordless sign-in has two competing goals: a fast login and a safe response to an unexpected request. Decide before launch:
| Decision | Options |
|---|---|
| Link lifetime | Short-lived token with resend, or a longer session handoff |
| Token reuse | Single-use only, or a documented multi-device policy |
| Existing sessions | Sign in the current browser, or require explicit confirmation |
| Unexpected request | Ignore, secure account, or contact support |
| Forwarded email | Allow with account binding, or require a new request |
Put the detailed explanation in the sign-in screen so the email remains scannable. The support team should be able to identify the request time and event ID without seeing the token.
Deliverability checklist
Send from a stable security address, keep the subject recognizable, and include a plain-text version. If links are rewritten by a tracking system, exclude authentication URLs from marketing tracking and make sure the final destination remains HTTPS and single-use.
Make the request recognizable
Show enough context for the recipient to distinguish a real request from a phishing attempt: product name, approximate request time, and a masked address or device description when reliable. Avoid putting a full sensitive address, location, or token in the subject line. The link label should describe the action, such as “Sign in securely,” rather than a raw URL.
The server must check token expiry, account binding, intended action, and replay state after the link is opened. If a user opens the link on a different device, follow the product’s documented handoff policy; do not weaken the token simply to make a support case easier.
Test the complete request lifecycle
Cover a normal request, several requests in succession, an expired token, a used token, a forwarded message, an unrecognized request, a wrong account, a delayed delivery, and a provider that rewrites links. Confirm that error pages do not reveal account existence and that the support team can identify the request without seeing the token. Track successful sign-in, expiry, resend, recovery, and suspicious-request rates.