A magic-link email promises less friction: enter an address, open the message, and sign in. The difficult part is everything hidden between those steps. The recipient may open the link on a different device, request several emails, use a security scanner that follows links automatically, or receive a sign-in message they never requested.
Emailify helps teams design responsive emails in Figma, preview mobile layouts, and export HTML for major email clients and email platforms. The authentication system still owns token scope, expiry, consumption rules, rate limits, and the final session. Design and engineering need to test the sequence together.
Write the state machine before the email
Map at least these outcomes:
- A known or unknown person submits an email address.
- The product gives a privacy-safe response.
- A single-purpose sign-in link is generated.
- The message is delivered, delayed, bounced, or requested again.
- The link opens on the same device, another device, or a security scanner.
- The token succeeds, expires, is superseded, or has already been used.
- The user lands in the intended workspace or a safe default.
Decide whether the token is single use, how long it lasts, and whether a newer request invalidates previous messages. Define what happens when the browser that initiated sign-in differs from the browser that opens the link. “Something went wrong” is not a recovery design.
Magic-link login is distinct from account verification, which proves address control during signup or a profile change, and password reset, which restores a password-based account. Passwordless login creates a session directly and needs explicit device, destination, and replay behavior.
Keep the message single-purpose
A practical content hierarchy is:
- recognizable sender and product;
- heading such as
Sign in to Acme; - one primary button labelled
Sign in; - accurate expiry guidance;
- requested workspace or destination when safe;
- calm instructions for an unexpected request;
- a legitimate support route.
Do not mix the message with a product announcement, upgrade offer, or newsletter module. The recipient is completing an identity action. Marketing content makes the email harder to scan and can make a security message feel less trustworthy.
Avoid claims the system cannot prove. “You requested this from Melbourne” may be misleading because of VPNs or imprecise IP data. If device or location context is shown, treat it as approximate and obtain security review.
Design for the inbox-to-browser handoff
Many people request the link on a laptop but read email on a phone. Decide whether cross-device sign-in is supported. If it is not, explain that before the person repeatedly requests new messages.
The primary action must be live HTML, not text embedded in an image. Keep expiry information close to it. Use a trusted HTTPS domain and avoid printing raw tokenized URLs in the visible message unless the security team has approved that fallback.
Create fixtures for long product and workspace names, narrow screens, 200% zoom, dark mode, blocked images, long localized buttons, and absent optional context. The message should remain clear without the logo. For broader responsive checks, use the mobile email QA workflow.
Define a safe placeholder contract
Agree on fields before HTML integration:
| Field | Example fixture | Rule |
|---|---|---|
| sign-in URL | test-domain token | generated server-side; never real in Figma |
| expiry | 10 minutes | matches authentication policy |
| workspace | Acme Design | escaped and optional |
| destination | Reports | describe safely; never include private content |
| support URL | approved help route | stable, non-tokenized link |
Use fake addresses, names, and tokens in design files and screenshots. Do not paste production login links into Figma, tickets, or approval documents.
Test through the real authentication path
Export the approved HTML with Emailify, integrate it in a non-production environment, and send through the actual authentication service. A generic ESP preview cannot prove token substitution or session creation.
Test these cases deliberately:
- same-device and cross-device completion;
- Gmail, Outlook, Apple Mail, and relevant mobile clients;
- security-link scanning and tracking-link rewriting;
- newest versus superseded messages;
- expired, used, malformed, and tampered tokens;
- multiple rapid requests and rate limiting;
- unknown addresses without account enumeration;
- intended destination present, missing, or no longer authorized;
- keyboard navigation, screen-reader order, visible focus, and zoom;
- images blocked and dark mode;
- unexpected-request guidance and support escalation.
Some security systems visit links before the human does. Authentication should not consume a token merely because an automated scanner fetched the URL. Validate the behavior with the actual email and security stack rather than assuming every link open represents a user gesture.
Ready-to-ship check
The workflow is ready when the sender is recognizable, the email contains one unambiguous action, expiry copy matches real behavior, no customer secrets appear in the design, and every failure state gives a safe next step. Confirm that older links behave as documented, cross-device behavior is understood, and the final HTML works without images.
The best magic-link email is short because the underlying system is well defined, not because edge cases were ignored. Keep the message calm, keep the action obvious, and prove the whole journey from request to authenticated session.
Read as Markdown Related resource index Site index for AI agents
Pro Bundle