If your magic link email is not working, do not keep clicking old links or requesting new ones yet. First match the email to the active sign-in attempt: use the newest message from the provider, open it on the same device, browser, and browser profile where you started login, avoid forwarded or shared links, and check whether the destination page says the link expired, was already used, or cannot match the session. If any of those are true, retire the older emails and request one fresh link through the provider's official flow.
The key rule is not "all magic links work this way." Providers decide their own expiration, one-time-use, and same-browser requirements. Your job is to preserve one clean login attempt and avoid mixing old links, profiles, and devices.
Magic-link failure decision tree
Use this before you start over. It separates delivery problems from click-and-handoff problems.
| What happened | Likely branch | What to check next | Safe next step |
|---|---|---|---|
| You never received the email | Delivery or inbox routing | Wrong address, spam, filters, aliases, or the related OTP/email checklist | Use the OTP email checklist for inbox triage before this magic-link flow. |
| The email arrived, but clicking it opens a different browser | Wrong browser or app handoff | Whether your mail app opened Safari/Edge/Chrome instead of the browser where login started | Copy nothing into shared tools; reopen the login flow in the intended browser or request one fresh link there. |
| The link opens the right browser but the wrong account state | Wrong browser profile | Whether Chrome or Edge is using a personal profile instead of the work/client profile that started login | Switch to the profile that owns the login attempt, then use the newest official link or restart once. |
| The page says expired, invalid, already used, or similar | Link freshness or one-time use | Whether you clicked an older email, previewed the link, requested a newer link, or waited too long | Stop trying older messages; request one fresh link through the provider's normal flow. |
| The email was forwarded from another inbox | Forwarded-link risk | Whether the provider expects the original browser/session, mailbox, or device | Do not rely on forwarded login links; use the account owner/provider flow instead. |
| The link opens but leaves you unauthenticated | Provider-specific session rule | Official help from that provider, especially same-browser/session notes | Follow that provider's instructions; do not assume another app's magic-link behavior applies. |
1. Confirm you are using the newest magic-link email
A magic link can fail simply because it is no longer the link attached to the current login attempt. If you requested more than one email, open the newest official message first and ignore older ones unless the provider explicitly tells you otherwise.
Do not infer a universal expiration window. Auth0 and Supabase both document passwordless email or magic-link authentication flows, but their exact behavior belongs to their implementation and settings. NIST's digital identity guidance is useful for conservative authentication framing, not for guessing every provider's link lifetime. When the login page says the link expired, invalid, already used, or not recognized, treat that message as authoritative for that provider.
A clean retry looks like this:
1. Close or ignore older magic-link emails.
2. Return to the provider's official sign-in page.
3. Start one new login attempt.
4. Wait for the newest email from the official sender.
5. Open that link in the same browser and profile that started the attempt.
2. Check the browser profile, not just the browser name
A magic link may open in Chrome and still be the wrong context. Chrome supports multiple profiles so browser data such as bookmarks, history, passwords, and settings can be separated by profile. Microsoft Edge also supports signing in and creating multiple profiles. That matters when your work login started in one browser profile but your email link opens in another.
Look for profile clues before you click again:
- the profile avatar or name in the top-right of the browser;
- whether the login page is open in a work, personal, client, or test profile;
- whether the email account that received the link belongs to the same profile context;
- whether your password manager or saved account is switching you to a different identity.
If the wrong profile owns the click, the provider may not be able to connect the link with the original browser session. Do not keep trying the same old link from different profiles. Instead, return to the intended profile, start one fresh provider login attempt, and use the newest link there.
3. Watch for mobile and email-app handoff problems
Many failures happen between the inbox and the browser. A phone email app may open links in an in-app browser, a default mobile browser, or a browser profile that is not signed in the same way as your desktop session. Desktop mail clients can also hand links to a different default browser than the one where sign-in began.
Use a simple handoff rule: start and finish the magic-link attempt in one place when possible. If you began login on desktop Chrome, use the email account there and keep the link in that same desktop Chrome profile. If you began on mobile, finish on mobile unless the provider explicitly supports another handoff.
Avoid pasting the link into team chat, a ticket, a shared doc, or another person's browser. The candidate requirement is explicit for a reason: magic links are login credentials for that attempt, not collaboration links.
4. Do not forward magic links as a workaround
Forwarding a magic-link email can create two problems at once: it moves a login credential outside the original inbox context, and it may open the link in a browser/session the provider does not recognize. Some providers may allow cross-device flows; others may not. The safe public advice is to avoid forwarding or sharing magic links and use the provider's own account access or recovery path instead.
If a team process depends on one person receiving login links for everyone, fix that ownership problem after the immediate incident. Use proper account roles, delegated access, or provider-supported team administration where available. Do not normalize shared magic links as an operating procedure.
5. When to request a fresh magic link
Request one fresh link when any of these are true:
- the page says the link expired, was already used, is invalid, or cannot be verified;
- you clicked an older email after requesting a newer one;
- the link opened in the wrong browser, profile, device, or in-app browser;
- you forwarded the link or opened it from a mailbox that is not the account's normal login inbox;
- the provider's official help says to restart the passwordless flow.
Before requesting, clear the confusion: decide which browser/profile/device will own the attempt, return to the provider's sign-in page there, and use only the newest email that arrives after that point. If the next fresh link also fails, stop guessing and use the provider's recovery or support route.
6. How this differs from an OTP code problem
An OTP-code problem is usually about finding and using the newest code. A magic-link problem includes that freshness issue, but it also adds browser handoff, profile state, device state, and link-click side effects. If your provider sent a numeric or short text code, use the related guide: [OTP Email Not Arriving? A Checklist Before You Request Another Code](/guides/otp-email-not-arriving-a-checklist-before-you-request-another-code).
If your provider sent a clickable login email, stay with this decision tree. The browser/profile branch is the part most generic "check spam and retry" advice misses.
Where MagicLess fits
MagicLess is built for a narrow login-email pain: fresh login codes and magic links across connected Gmail inboxes can interrupt work. A helper can reduce the manual inbox-search step, but it cannot make an expired link valid, force a provider to accept a different browser session, bypass provider rules, or access inboxes without authorization. Use the decision tree to finish the current login safely; if login emails regularly interrupt your work across connected Gmail inboxes, evaluate MagicLess after you understand the provider and browser-profile limits.
FAQ
Why is my magic link email not working after I click it?
Common causes include using an older email, opening the link after it expired or was already used, clicking from a different browser/device/profile than the active login attempt, or running into a provider-specific passwordless-login rule. Use the newest official email and follow that provider's flow.
Can a magic link fail because it opens the wrong browser or profile?
Yes. Browser profiles can keep separate account state, and official Chrome and Edge help both document multiple profile support. If the login attempt started in one profile but the email opens in another, restart cleanly in the intended profile instead of reusing old links.
Should I forward a magic link to another device or teammate?
No. Do not treat a magic link as a shareable URL. It is part of an authentication flow. Use the provider's supported login, account recovery, delegated access, or team-management features instead.
What should I do if the link expired or says it was already used?
Stop trying older emails. Return to the provider's official login page, start one fresh attempt, and open only the newest link that arrives for that attempt. If it still fails, use the provider's recovery or support path.
Do all magic links have the same expiration time?
No. This guide does not state a universal expiration time because providers control their own passwordless-email behavior. Check the provider's official docs or on-screen message for exact rules.
Claim ledger
| Claim | Source | Last checked | Confidence |
|---|---|---|---|
| Chrome supports multiple profiles, making profile context relevant when a login link opens in the wrong signed-in state. | Google Chrome Help | 2026-09-05 | High |
| Microsoft Edge supports signing in and creating multiple profiles, so profile switching can affect browser context. | Microsoft Support | 2026-09-05 | High |
| Auth0 documents email magic-link passwordless authentication as a provider-specific flow, including implementation-specific browser/session behavior. | Auth0 Docs | 2026-09-05 | High |
| Supabase documents passwordless email sign-in with magic links/OTPs as an implementation-specific authentication flow. | Supabase Docs | 2026-09-05 | High |
| One-time authentication behavior depends on validation rules; public advice should not invent universal link lifetimes or reuse behavior. | NIST SP 800-63B | 2026-09-05 | Medium |
Sources
- Google Chrome Help: Manage Chrome with multiple profiles
- Microsoft Support: Sign in and create multiple profiles in Microsoft Edge
- Auth0 Docs: Authenticate users with passwordless email magic links
- Supabase Docs: Passwordless email logins
- NIST: Special Publication 800-63B