KoltrixMagic links vs email OTP codes: speed and security
Passwordless login lives or dies on email delivery. Compare magic links and one-time codes on security, link scanners, latency and cross-device use.
On this page(8 sections)
Passwordless login by email moves the whole sign-in experience onto your email delivery. If the message is slow, filtered or consumed by a scanner, the user cannot log in.
Choosing between a magic link and a one-time code is therefore as much a deliverability decision as a security one.
The two patterns
Magic link: the user enters their email address, and you send a message containing a URL with a single-use token. Clicking it signs them in.
Email OTP: the user enters their email address, and you send a short numeric or alphanumeric code. They type it into the waiting login page.
Both prove the same thing: the person signing in can read mail sent to that address. They differ in where the proof is completed, which turns out to matter a great deal.
Security comparison
Token strength
A magic link can carry a long random token, 128 bits or more, which makes guessing impossible. An OTP has to be short enough to type, typically six digits, which is only a million possibilities. OTPs are therefore only safe with strict attempt limits: a handful of tries per code, and rate limits per account and per IP, after which the code is invalidated.
Phishing
Both are phishable in real time. An attacker's fake login page can ask for the user's email, trigger a real login on your site, and ask the victim to paste the code they receive. Magic links resist this slightly better, because the link completes sign-in in whatever browser opens it, which is the victim's, not the attacker's. But attackers adapt, for example by asking victims to paste the link. Neither method is phishing-resistant in the way passkeys are.
Session binding
A useful hardening for magic links is binding the link to the browser that requested it: set a short-lived cookie or nonce when the user submits their email, and require it when the link is opened. That prevents a leaked or forwarded link from signing in someone else. It also breaks the cross-device case, discussed below, so many products offer a fallback.
For OTPs, binding is natural: the code is entered on the page that requested it.
Leakage
Magic link tokens are URLs, so they can leak through browser history, logs, proxies and Referer headers. Keep them out of server logs, apply a strict Referrer-Policy on the landing page, and exchange the token for a session immediately, redirecting to a URL without it.
The link scanner problem
Many corporate email security products fetch every URL in incoming mail to check it for malware or phishing. Some do it on delivery, some when the user clicks, and some do both.
If simply loading your magic link URL consumes the token and creates a session, a scanner will use up the link before the user ever sees it. The user then clicks a dead link and assumes your product is broken.
Fixes:
- Make the GET request show a confirmation page with a "Sign in" button, and complete sign-in on a POST from that page.
- Or validate the token on GET without consuming it, and consume it only when the page's JavaScript or a form submission confirms a human interaction.
OTPs avoid this entirely, because there is nothing to fetch.
Cross-device use
A very common scenario: the user starts signing in on a laptop, but reads email on their phone.
- With a magic link, clicking on the phone signs in the phone, not the laptop. The user is confused, or has to forward the email to themselves. Some products solve this by having the laptop poll and complete the sign-in when the link is clicked anywhere, which reintroduces risk if the link is clicked by someone else.
- With an OTP, the user reads the code on their phone and types it on the laptop. It works naturally.
This alone is why many products offer codes, or send both a link and a code in the same email.
Delivery speed is the real constraint
Users wait on the login screen. Every second of delivery latency is felt directly.
| Factor | Effect on latency | What to do |
|---|---|---|
| Queueing behind bulk mail | Minutes of delay | Separate high-priority queue for auth mail |
| Greylisting at the receiver | First message to a new receiver can be deferred | Retry quickly; consistent sending IPs |
| Spam filtering | Message lands in junk; user never finds it | Full SPF, DKIM, DMARC alignment; plain, consistent content |
| Expiry too short | Code expires before arrival | Allow enough time, often 10 to 15 minutes for codes |
| Rate limits at your provider | Bursts during peak signups delayed | Size limits for auth traffic separately |
Measure the time from login request to acceptance by the receiving server, and alert when it rises. Delivery acceptance is not inbox arrival, but it is the part you control.
Writing the email
Keep authentication emails short, plain and predictable:
- A subject that says exactly what it is, such as "Your sign-in code" or "Sign in to Example." Some products put the code in the subject so users can read it from a notification; that is convenient, but it exposes the code on lock screens, so weigh it for your audience.
- The code or button near the top, with the expiry time.
- A plain-text alternative containing the same link or code.
- A line saying what to do if the user did not request it.
- No marketing content, tracking-heavy templates or extra links that make filters or scanners suspicious.
Choosing
| Consideration | Magic link | Email OTP |
|---|---|---|
| Token entropy | High | Low; needs strict attempt limits |
| Cross-device | Awkward | Natural |
| Link scanners | Need a confirm step | Not affected |
| Typing required | None | Six or so characters |
| Mobile app sign-in | Needs deep links | Simple |
| Real-time phishing | Somewhat resistant | Easier to relay |
A pragmatic default for many SaaS products is to send both: a magic link for users reading mail on the same device, and a code for everyone else, sharing one expiry and invalidated together.
Key takeaways
- Both methods prove control of a mailbox; neither is phishing-resistant like passkeys.
- Magic links carry strong tokens but need a confirmation step to survive link scanners.
- OTPs handle cross-device sign-in well but need strict attempt limits.
- Delivery latency decides the user experience, so give authentication mail its own fast, well-authenticated path.
- Sending both a link and a code covers the most users with the fewest support tickets.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
