Quick answer
Use the newest link in the browser state that requested it
A magic link can fail because it expired, was already used, belongs to an earlier request, opened in a different browser context, was delayed, or was fetched by a security scanner. Request one fresh link only after confirming the address and current session.
- Links are usually single use
- Expiry is sender-controlled
- Scanners can affect one-time URLs
Best first move
Return to the original sign-in screen
- Confirm the account and address.
- Keep the browser tab open.
- Use the newest link once.
Avoid
Opening every old link
- Old links may be invalid.
- Different devices may not share state.
- Repeated requests can trigger limits.
Process
Recover from a failed magic link
A clean retry is safer than cycling through a crowded inbox.
Close or ignore older link messages
Identify the newest request and do not test previous links against the current sign-in state.
Return to the service directly
Open the official site or app yourself, confirm the address, and use its resend or sign-in control rather than an unexpected email.
Keep the intended browser context
If the flow depends on a cookie or local session, request and open the link in the browser where the sign-in began.
Request one new link
Wait for any rate limit, request a fresh message, and use it promptly without forwarding it to another person or system.
Escalate through official support
If every new link fails, report the timestamp and redacted error. Do not send the full URL because it contains an authentication token.
Decision guide
Common magic-link failures
| Failure | What may have happened | What to do |
|---|---|---|
| Expired | The link exceeded the sender’s validity window. | Request one fresh link from the official screen. |
| Already used | The token was consumed by an earlier click or fetch. | Generate a new link; do not reuse the old URL. |
| Works on one device only | The flow is bound to browser state. | Request and open it in the intended browser. |
| Arrived too late | Delivery delay outlasted the token window. | Confirm the address, then request a fresh link once. |
| Fails immediately in a corporate inbox | A security gateway may have inspected the URL. | Use the provider’s documented recovery path or ask authorised IT/support. |
Practical details
What makes magic links different from ordinary links
The URL carries temporary authority
A magic link does more than navigate. It normally includes a random token that proves access to the requested inbox for one action. That is why the link needs a short lifetime, single-use behavior, and an HTTPS destination.
Browser state can be part of the proof
Some implementations remember where sign-in started and expect the link to return to that context. Opening it on another device, in an in-app browser, or after clearing cookies can lose that state.
This behavior is implementation-specific, so the service’s own instructions take priority.
Security scanners create a design challenge
Corporate and mail-security systems may fetch links to assess risk. A robust application should consider that possibility and avoid giving an automated preview the same effect as a deliberate user action.
As a user, repeated failures from a work inbox are a reason to use official IT or product support—not to bypass organisational security controls.
Checklist
Safe retry checklist
- The message was expected from the service you opened.
- The destination domain matches the official service.
- You are using the newest link only.
- The link has not been forwarded or pasted elsewhere.
- The browser context matches the sign-in attempt when required.
- The account is appropriate for the address type and future access.
Use a permanent protected mailbox for important accounts, recovery, work, health, finance, or identity.
Related reading
Continue with the right next step
If the message itself is missing, use the verification delivery checklist. For numeric tokens, read why verification codes fail. Developers should use the authorised scenarios in safe signup-flow testing.
Sources
Authoritative references
These references support the technical and privacy details above. Product-specific limits are described separately in our own guides.
FAQ
Frequently asked questions
Can I reuse a magic link after it worked?
A secure one-time link should be invalid after use. Return to the service and begin a new official sign-in if needed.
Why does a fresh link say it was already used?
A mail-security scanner or another browser may have fetched it, or the message may belong to an older request.
Is it safe to copy the full link into a support ticket?
No. The URL may contain a live authentication token. Share only redacted error details and timestamps.
Should I use temporary email for a passwordless account?
Only if the account is genuinely disposable. A durable account needs an address you can recover later.