The magic link: when the inbox is the login.

Most transactional email is a message about something that has already happened or can happen another way. A receipt confirms a purchase that went through regardless; a password-reset email offers one route back in while the old password still works as another. Magic links remove the other route. The user typed their address, you promised to send the way in, and that email is now the single point through which authentication passes. Nothing else will let them in.

That changes what a deliverability problem means. When a magic link lands in spam, the user has not received a delayed convenience — they have hit a locked door with the key on the wrong side of it. And users do not behave like testers: they do not check spam, inspect headers, or open a support ticket about inbox placement. They try once, maybe twice, and then they leave, reading the silence as the product being broken. A measurable share of failed sign-ins on magic-link systems are not forgotten anything; they are emails that never arrived.

So the standard a magic link has to meet is not the one a newsletter is judged by. It is closer to the standard you would apply to a load balancer or an auth server: this is part of the login path, and its uptime is the uptime of your front door. Treating the email that carries it as ordinary marketing-adjacent mail — same stream, same reputation, same tolerance for a few minutes' delay — is treating a critical-path dependency as a nice-to-have. The asymmetry is what makes it dangerous: the cost of getting it right is some infrastructure discipline you pay once, while the cost of getting it wrong is paid continuously, in users who reached the very last step of signing in and were turned away by the one part of the system most teams never instrument. A login page gets monitored to the millisecond; the email that is half of a passwordless login often gets no monitoring at all.

It helps to place magic links next to the methods they replace, because each one leans on email differently, and the difference is exactly the deliverability exposure. A password barely touches email on the critical path: the user signs in with something they already know, and email only appears if they forget it. A one-time passcode leans harder — the code arrives by email or SMS and the login waits on it — but the user copies a short string rather than following a link, which quietly sidesteps the scanner problem entirely, since there is no URL for a gateway to pre-fetch.

A magic link leans hardest of all. It folds the whole login into a single clicked URL delivered by email, which is what makes it feel effortless — one tap and you are in — and also what concentrates every deliverability risk onto one message. It inherits the passcode's dependence on the mail arriving fast and on time, and then adds a vulnerability the passcode does not have: a clickable, single-use URL is precisely the thing automated security scanners exist to visit. The convenience and the fragility come from the same property.

None of this argues against magic links — the experience is genuinely excellent and many products are right to choose it. It argues that the choice carries an infrastructure obligation. Moving authentication into the inbox is a reasonable design decision; treating the inbox as a best-effort channel afterwards is not. The further toward magic links you go, the more the email behind them has to be engineered like the load-bearing component it has become.

This is the failure that bewilders teams the first time it appears, because it looks impossible: the user swears they clicked the link exactly once, yet the system reports the token as already spent. The culprit is not the user and not a bug in your code. It is a security scanner doing its job. Corporate mail gateways and link-protection systems routinely pre-fetch every URL in an incoming message — they visit the link automatically to check whether it leads somewhere malicious before the recipient is allowed near it. If your magic link logs the user in, or burns its one-time token, simply on being visited, that automated check spends the token, and the human arrives second to a door that has already closed behind a machine.

It is maddening precisely because the email was delivered perfectly. Placement was fine, speed was fine, the user did everything right — and the authentication still failed, inside the recipient's own security infrastructure, somewhere you cannot see. Teams chase it as a delivery bug for weeks before realising the click that consumed the token came from a data centre, not a person.

The fix is in how the link behaves, not only in how it is sent. A magic link should not complete the login on a bare visit. The durable patterns are to land on a lightweight confirmation page that asks for a deliberate action — a button the human presses to finish signing in — and to make the token-consuming step a form submission rather than a plain link-follow, since scanners overwhelmingly follow the latter and rarely submit the former. Re-requestable links and sensible expiry windows soften the rest. Infrastructure still plays its part: clean authentication and strong reputation reduce how often your mail is routed through the most aggressive scanning paths, but the structural protection lives in the link design, and it is the part most teams discover only after it has bitten them. The tell is a support report that makes no sense — a user adamant they clicked once, logs that show the token consumed seconds before their click, and an IP on that first request belonging to a security vendor rather than a person. Once you have seen it, you recognise it instantly; before you have, it can swallow a week of debugging the wrong layer.

The infrastructure for a magic link is the infrastructure for any high-stakes transactional message, turned up to the standard a critical path deserves. Speed comes first: the mail has to leave and land in seconds, which means sending on a system tuned for low-latency transactional delivery rather than one where authentication mail waits in the same queue as a marketing blast. That alone rules out a surprising number of setups where login emails share a path with bulk.

Isolation comes next. Authentication mail belongs on its own stream — a dedicated IP or subdomain whose reputation is built only by this kind of fast, expected, rarely-complained-about traffic — so it can never be dragged toward spam by a promotional campaign that drew complaints. Authentication is the other pillar: SPF, DKIM, and DMARC correct and aligned, so mailbox providers trust the mail on sight and route it the fast way rather than the suspicious way. And reputation underneath it all, kept healthy by operations that warm IPs properly and watch for trouble, because a login email that is right in every other respect still fails if it is sent from an address mailbox providers have learned to distrust.

This is the case EDP is built for. Magic links run on dedicated IPs you own, on its own PowerMTA and KumoMTA tuned for fast transactional delivery, separated from any bulk or marketing stream, with authentication and reputation operated as a managed service rather than left for you to maintain. None of it is exotic — it is simply the difference between treating the login email as ordinary mail and treating it as the front door it actually is. The pieces are individually unremarkable — speed, isolation, authentication, reputation — and that is the point: there is no clever trick that rescues a magic link sent on the wrong foundation, only the unglamorous discipline of running each of those well and together, which is exactly the work a managed service exists to take off your plate.

The silent lockout. The characteristic way magic links fail is invisibly. There is no error, no bounce the user sees, no obvious break — just a person who asked to sign in, waited, and quietly gave up because the email never showed or the link was dead when it did. Because the failure produces no signal on the user's side, teams routinely under-count it: the support queue stays quiet, the dashboards look fine, and the only trace is a sign-in funnel that leaks more than it should at the email step. The mail that fails most expensively is the mail nobody complains about, because the people it failed are gone.

Everything on this page is aimed at that one outcome. Fast, isolated, authenticated sending keeps the link arriving inside its window; link design that resists automated visits keeps the token alive for the human; and managed reputation keeps the whole thing landing in the inbox where the user is looking. A magic link is a small email with an outsized job — it is the only thing standing between a user and your product — and the infrastructure under it should be sized for that job, not for the few bytes it weighs. Sized correctly, it disappears — users sign in, the funnel holds, and nobody thinks about the email at all, which is the only state in which a login email is doing its job. The goal is not a magic link anyone notices; it is one that is simply always there when someone asks to come in.