Click a link in an email and you're logged in — no username, no password, no account to remember. That's a magic link: one of the most common patterns in web authentication, and one of the most quietly misunderstood.
How a magic link actually works
A magic link is a unique, single-purpose URL, generated on a server and delivered through some channel — almost always email, sometimes text message. Embedded in it is a token: a long, unguessable string tied to a specific account, a specific action, and a specific expiry window. Clicking the link sends that token back to the server, which checks it and, if it's valid, treats the click itself as sufficient proof. There's no separate password step. Authentication happens at the moment of the click, not before it.
That's a real but different claim from what a password makes. A password proves you know a secret. A magic link proves you had access to a particular inbox, or phone, at a particular moment. The two overlap most of the time — but they aren't the same guarantee, and the difference is exactly where the tradeoffs below come from.
Where magic links show up
Three uses cover most of what you'll run into:
- Email confirmation — proving an address is real and belongs to you, typically at signup.
- Password reset — inbox ownership stands in for the password you forgot.
- One-off access — viewing a single invoice, RSVPing to an event, approving a request, replying to one message.
That last category is the interesting one, because it doesn't require an account to exist at all. A magic link can authenticate a single action for someone who has never signed up for anything, which is exactly why it shows up so often at the edges of a product — wherever the person on the other end is a guest or a recipient rather than a registered user.
What it trades away
The convenience is real: nothing to create, nothing to remember, nothing to type wrong. That convenience has a cost, worth stating plainly rather than glossing over.
A magic link is only as secure as the channel that delivered it. Email is the usual channel, and an inbox is not a vault — it can be forwarded, left open on a shared device, cached by a client, or compromised outright. Whoever controls the inbox controls the link. If the channel is compromised, so is anything gated only by a link sent through it.
The other honest tradeoff is scope. A magic link typically authenticates one action, once, inside a limited window — not a full standing login the way an ordinary account session does. That isn't really a limitation; it's the correct shape for what the link is proving. A token built to show "this person had access to this inbox a minute ago" shouldn't also be trusted to mean "this person is the account holder, indefinitely, for everything."
Right-sized for one job, wrong for many
That scope is exactly why magic links fit narrow, self-contained actions well — reply to this message, confirm this address, view this one document — and fit broad or sensitive actions poorly, like managing account settings, changing billing details, or reviewing a full order history. A link that leaks or gets forwarded should have a small, contained blast radius. Handing it the keys to an entire account defeats the point of scoping it in the first place.
The same instinct — narrow, time-limited access instead of broad standing access — comes up any time you connect an app to an existing account; a magic link is just one common, concrete shape that question takes.
RelayLink's version of the pattern
RelayLink's reply path is a magic link. A briefing arrives by email with a private link to a web view and a reply box; replying there, or replying to the email directly, authenticates the reply with that token rather than a login, and lands it on the sender's thread. In the provenance vocabulary that runs through every package, that reply is labeled typed via magic link — not because the words are any less genuine than a reply typed inside a full account session, but because a link click is honestly a lower authentication tier than one, and the label says so instead of rounding up.
The full send-and-reply flow uses both tiers deliberately: a real account authenticates the sender's side, where a draft becomes a released message, and a magic link authenticates the reply from someone who may never have an account at all. Different jobs, different tiers — which is the whole pattern, applied to one thread.