Short answer: use an emailed, single-use reset link as the default for most SaaS login recovery, and add SMS OTP only where users may genuinely lack email access or the product already maintains verified phone numbers.
Email is usually the simpler system because the login identifier, recovery destination, and support workflow can remain in one channel.
SMS can shorten the interaction, but it adds phone-number lifecycle, message segmentation, regional consent, and delivery-state work. “Cheaper” depends on your traffic and failure rates, so model completed recoveries rather than message sends.
This is a recovery decision, not a notification preference.
The goal is to return the right person to an account without turning a delayed message, an expired credential, or a recycled phone number into an account takeover or a support queue.
I've worked around enough spam filtering, rate limiting, and OTP delivery gaps to treat the channel as one component of that system — never as the system itself.
What should a SaaS password recovery flow use: email API or SMS OTP?
Start with the account data you can already trust.
If every user signs in with an email address and changing that address is a controlled operation, an email reset link creates the smaller data surface.
The service generates a high-entropy, single-use token, stores only a protected representation of it, sends a link, and accepts that token once before a short expiry.
The browser then moves the user into a password-change session.
An SMS OTP flow looks compact on screen, yet the backend has more questions to answer.
Was the phone number verified recently?
Can the user update it without being signed in?
How are country codes normalized?
What happens when a number is reassigned?
Does the support team have a safe path for a person who lost the device?
A six-digit form doesn't make those policy decisions disappear.
So the default is straightforward.
Choose email first when email is the stable account identifier and recovery is occasional.
Consider SMS as an additional path when the service has a legitimate reason to collect and continuously verify phone numbers, or when an email-only path would strand a meaningful user group.
Don't add SMS merely because entering a short code feels faster in a demo.
The catch is that email is not suitable when users routinely lose access to the mailbox that identifies them.
In that case, a separately verified recovery factor or a support-assisted process may be necessary.
SMS is also not suitable when phone ownership is weak evidence in the product's environment, when regional messaging operations are not staffed, or when collecting phone numbers would create disproportionate privacy and compliance work.
Neither channel is a universal fallback.
The delivery constraint comes before the screen For email, delivery begins with domain alignment and message integrity.
DKIM lets a signing domain take responsibility for a message and lets a receiver detect changes to signed content in transit.
That is useful infrastructure, but a valid signature is not a promise that the message will reach the inbox or that the sender is trustworthy.
Recovery design still needs stable sending identity, conservative content, bounce handling, suppression, and monitoring around the entire path.
Password-reset mail should also be boring.
Keep the purpose obvious, avoid unnecessary tracking, don't include the current password, and make expiration clear without exposing account state.
The request endpoint should give the same public response for an existing and a nonexistent account.
Otherwise the recovery form becomes an email-address discovery tool.
SMS has a different physical constraint: encoding changes capacity.
A single GSM-7 message can contain up to 160 characters, while UCS-2 reduces that to
70.
Concatenated messages reserve characters for segmentation, leaving 153 GSM-7 or 67 UCS-2 characters per segment.
A curly quote, non-Latin name, or translated sentence can the