Magic links are passwordless login URLs sent by email: you enter your address, the service emails a unique, time-limited link, and clicking it signs you in. The link contains a secret token that proves control of the inbox. The main risks are that anyone with access to that inbox can log in, links can be forwarded or leak through referrers, and expiry windows are short. For throwaway addresses, magic links work for one-off signups but break when you need later access.
What is a magic link and how does it work?
A magic link is a URL that contains a one-time token. When you request a login, the server generates a random token, stores it against your account with an expiry time, and emails you a link like https://example.com/auth?token=abc123. Clicking the link sends the token back to the server, which checks it is valid, unused and unexpired, then creates a session.
The token is usually a long random string (often 128 bits or more, encoded as hex or base64url). It is not your password; it is a bearer credential — whoever holds it can use it until it expires or is used once. Good implementations bind the token to the email address and may also bind it to the browser session that requested it, so a link opened in a different browser fails.
Unlike a password, there is nothing to remember. But the security model shifts: the email inbox becomes the authentication factor. If someone can read your email, they can request a magic link and log in as you.
How long do magic links last and why do they expire?
Expiry windows vary by service and change often; common ranges are 5 to 15 minutes, sometimes up to an hour. The link usually becomes invalid after first use. Expiry limits the window in which a leaked link can be exploited — for example, if the email is forwarded, archived in a shared inbox, or intercepted.
Expiry also reduces the value of old emails: a link found in a months-old mailbox export should not work. Some services allow a slightly longer window for usability, but shorter is safer. If a link expires, you simply request a new one; the old token should be invalidated.
There is a trade-off: too short and users on slow connections or with email delays get frustrated; too long and the risk grows. The right window depends on the service's threat model.
Why your inbox becomes the master key
With passwords, an attacker needs your password (and ideally a second factor). With magic links, an attacker needs access to your email. That access can come from many places: a compromised email password, a session left open on a shared computer, a malicious browser extension, or an email account that never had a strong password.
This is why email providers push two-factor authentication and passkeys. If your email account is protected only by a password, a magic-link login to another service is only as strong as that password. In practice, many people protect their email better than other accounts, but not always.
There are also forward-and-leak risks: if you forward a magic-link email to someone else (for example, to a colleague to 'check something'), they can use the link. Link scanners in corporate email security products may prefetch URLs, which can consume one-time tokens before the user clicks. Some services handle this by requiring a click on a confirmation page, but not all do.
Another risk is shared or public inboxes: a magic link sent to a shared team address can be used by anyone with access. For personal accounts, use a private inbox.
Magic links vs passwords: which is more secure?
Neither is universally more secure; they fail differently. Passwords can be reused, phished, or cracked if weak. Magic links cannot be phished in the traditional sense (there is no password to steal), but they can be intercepted if the email is read by an attacker, and they depend on the security of the email account.
Magic links also remove the risk of password reuse across sites. But they add a dependency on email deliverability: if the email goes to spam or is delayed, you cannot log in. And if you lose access to the email account, you lose access to every service that uses magic links to that address.
Many services now offer magic links alongside passwords or passkeys, letting users choose. For low-risk accounts, magic links are convenient. For high-value accounts (banking, primary email, work systems), a password plus a strong second factor, or a passkey, is usually stronger because it does not reduce security to a single bearer token in an inbox.
What are the practical limits of magic links?
Magic links are not a replacement for all authentication. They struggle with:
- Shared devices: signing in on a public computer leaves a session that may persist; magic links do not inherently log you out.
- Email delays: if the email is slow, the link may expire before it arrives.
- Link scanners: security products that prefetch links can invalidate one-time tokens.
- Account recovery: if you lose email access, recovery may be impossible without a backup method.
- Automation: scripts and CI systems cannot easily click a link; they need API tokens or app passwords.
Developers should also consider accessibility: some users cannot easily click links in email, or use email clients that strip HTML. Always provide a fallback code or password option.
When should you use a disposable address for magic-link signups?
A disposable address is suitable when you need to receive a single magic link for a one-off action and do not intend to return to the account. Examples: downloading a gated resource, testing a service, or entering a contest. In those cases, the inbox is temporary and the link is used immediately.
But magic links are often used for ongoing login. If you plan to return to the service, a disposable address is a poor fit: the inbox expires (MailboxTemp free inboxes last 60 minutes, extendable; Pro 24 hours), and you will be locked out. You also cannot receive later links or password resets.
For services you will use again, use a real address or an email alias that forwards to your main inbox. Aliases give you separation without losing access. See our guide to temp mail vs VPN vs alias for the trade-offs.
If you are testing magic-link flows as a developer, a disposable inbox is useful for automation. You can use the MailboxTemp API to create inboxes and poll for messages. But be aware that some services block disposable domains; check our post on why websites block disposable emails.
How do magic links interact with two-factor authentication?
Magic links are sometimes described as 'something you have' (access to the inbox) rather than 'something you know'. If the email account itself is protected by two-factor authentication, the magic link inherits that protection. But if the email account has only a password, the magic link is single-factor.
Some services combine magic links with a second factor, such as a code sent by SMS. This adds friction but improves security. For a deeper look, see our two-factor authentication explained.
If you use magic links, protect your email account with a strong, unique password and two-factor authentication. Consider a passkey for your email provider if available.
Sources
- RFC 6750: The OAuth 2.0 Authorization Framework: Bearer Token Usage — explains bearer token security, relevant to magic-link tokens.
- NIST SP 800-63B: Digital Identity Guidelines — Authentication and Lifecycle Management — covers authenticator types and out-of-band verification.
- RFC 5321: Simple Mail Transfer Protocol — the email delivery foundation magic links depend on.
In short
Magic links trade a password for a click in your inbox. They are convenient and avoid password reuse, but they make your email account the master key. Use them for low-risk, one-off signups with a disposable address only if you do not need to return; for anything you will use again, use a real or alias address and protect your inbox with two-factor authentication.