Email OTP vs SMS OTP: which should you use?

Both send a short code to something the user owns and ask them to type it back. The difference is the channel, and the channel decides cost, speed, reach and the ways it can be attacked.

Side by side

| | Email OTP | SMS OTP | |---|---|---| | Cost per code | Very low | Higher, and varies by country | | Delivery speed | Usually seconds, occasionally minutes | Usually seconds | | Works without a phone number | Yes | No | | Works abroad or on Wi-Fi only | Yes | Needs mobile coverage | | Main attack | Mailbox takeover | SIM swap, number recycling, interception | | Phishing | Fake "verify" emails | Fake texts with links | | User already has it | Almost always, they signed up with it | Only if you collected it | | Leaves a record | Yes, searchable | Limited |

Security in practice

Neither channel is strong against a determined attacker, and both are far better than no second factor on top of a weak password. The attacks that matter most differ:

• Email: if an attacker controls the inbox, they receive every code and every reset. A user with a strong mailbox password and its own second factor is well protected.
• SMS: a SIM swap sends codes to the attacker. Phone numbers are recycled to new owners. SMS can also be intercepted on weak networks.

For high-value accounts, an authenticator app or passkey beats both.

What matters more than the channel

The code design is the same for both and it is where most real failures live:

1. Generate with a secure random source.
2. Store a hash, not the code.
3. Expire in minutes.
4. Cap attempts per code and per account.
5. Rate-limit requests so your product cannot be used to flood someone with codes.

All of this is in the OTP email workflow.

Cost and delivery

SMS bills per message and per destination country, and some countries add registration requirements. Email costs a fraction. On the other side, an email code depends on the mailbox provider accepting it quickly, so keep the message plain and send from a verified domain with SPF, DKIM and DMARC in place. See the deliverability checklist.

A reasonable recommendation

• Signup verification: email. The user just gave you the address, and you need it anyway.
• Sign-in second factor: an authenticator app or passkey if you can, SMS or email if you cannot.
• Account recovery: email, with the extra checks you would apply to any reset.
• Global audience, or users without reliable mobile coverage: email first.
• Mobile-first product with phone numbers already on file: offer SMS as an option, not the only path.

If you would rather skip codes, a magic link removes the typing, at the cost of requiring the user to open the email on the same device.