Why do my magic link logins fail?

The failure that looks like a user error

The symptom is always the same and always confusing. Someone asks for a login link, the link arrives, they click it, and your app tells them it is invalid or already used. Nothing in your logs looks broken: the mail was accepted, the token was created, and the token was verified. It was verified — just not by the person you sent it to. Between your send and their click there is a queue of machines reading that message: the recipient's mail-security product rewriting and following links to check them, the mail client prefetching so a preview renders instantly, corporate gateways detonating URLs in a sandbox, and sometimes a filter doing the same on the way in.

We hit this in our own production signup flow in August 2026, and the shape of it is worth repeating because it looked like nothing. One signup requested three links in a single sitting. All three were verified server-side within 16 to 23 seconds of being sent — far too fast to be a person reading an inbox — and every human click after that was rejected as already used. They only got in by starting again with a social sign-in. Two ordinary habits make it worse and produce the identical log line: people request a link on their phone and open it on their laptop, and people forward a login mail to a colleague or to their own second address. If your design assumes the first request for a token is the human's browser, all three of these read as an attack when they are the normal case.

Work out which one is yours

Before changing anything, find out what actually spent the token. The timestamp is the tell: a scanner or a prefetcher lands within seconds of the send, a person lands in tens of seconds to minutes. Log the time, user agent and IP of every verification next to the time of the send, then read them together.

The fix, in the order that matters

The order is load-bearing, because two of these steps are safe on their own and dangerous in the wrong sequence.

1. Check expiry before you consume An expired token must never be able to open a session, whatever else you change. Putting the expiry check first is what makes the next step safe — without it, tolerating a repeat open would extend a link's life instead of merely surviving an extra visit.
2. Let an unexpired link be opened more than one time Accept a token that has already been verified but is still inside its lifetime, and return a flag saying so rather than an error. A link should die when it expires, not when the first machine touches it.
3. Keep the first verification timestamp When you accept a repeat open, do not overwrite the original consumed-at time. It is the only record of which visit actually won, and it is the first thing you will want the next time somebody reports this.
4. Shorten the window instead of narrowing the opens A short-lived link that tolerates several visits is safer in practice than a long-lived one that dies on first touch. The short lifetime is doing the security work; single use was only ever a proxy for it.
5. Always leave a second door Offer one other way in — a password, a passkey, or a social sign-in — and show it on the failure screen itself, not three clicks away. The signup we lost to this recovered through social sign-in; without that door it would have been gone at the threshold.
6. Say something useful when it does fail "Invalid link" tells someone they did something wrong. "This link has expired — here is a fresh one", with a one-tap resend on the same screen, keeps them inside the flow instead of sending them to your support inbox.

The part that never shows up as a bug

The login failure is visible. The measurement damage is not, and it outlives the bug. If your signup conversion event fires on the first request that reaches your verification endpoint, then whenever a scanner gets there first the conversion rides a redirect that no browser ever executes. That is exactly what happened to us: the brand-new-registration flag travelled with the scanner's request, so the ad-platform signup conversion for that person was never recorded. Anyone bidding on that data is bidding on a number quietly missing some of its hardest-won conversions.

The habit that catches it is dull but reliable: count the completed session, not the link click, and treat the gap between "link requested" and "session created" as its own funnel step. If a real share of requests never becomes a session, no amount of landing-page work will fix it — that is a mechanism failure, not a persuasion failure. See how to turn website visitors into signups for the step before this one and activation rate for the step after. If the mail is not arriving at all, the domain-authentication ladder in how to write cold emails that don't get marked spam applies to transactional mail too. And if you are deciding where that mail should be sent from in the first place, Notifuse is one self-hosted option.