The user types their email; the platform emails them a 6-digit code; they type the code; they're in. No password to remember.
Enable
Authentication → Email OTP. Toggle on.
Configuration knobs:
Code length — 6 digits (default). 4 is too easy to brute-force. 8 reduces type errors at the cost of typing friction. 6 is the sweet spot.
Code TTL — 5 minutes (default). Long enough for the user to switch to their email tab; short enough that a stolen code is useless.
Send rate — max 3 codes per user per 15 minutes (default). Catches accidental double-click + brute-force from the same user.
Verification attempts — max 5 attempts per code (default). Then the code is burned; the user requests a new one.
Save.
What the user sees
Sign-in page → "Continue with email" → enter email. Click. Email arrives with the code (and a magic-link if you also have that enabled — same email; one or the other).
Your sign-in code is 482917
This code expires in 5 minutes.
Didn't request this? Ignore this email.
The code is typed into a 6-digit input on the sign-in page. On verify, they're in.
When to enable email OTP
Consumer apps where users sign up casually and won't remember a password.
B2C marketplaces where reducing first-sign-in friction is more important than a per-sign-in friction reduction.
As a recovery path when password is the primary but the user has forgotten.
When NOT to enable it:
High-security tenants where every sign-in must be MFA-gated. OTP can be MFA-gated too, but it's less common.
B2B internal-tools where SSO is the right path.
The email itself
The OTP email uses the platform's standard email template. Customise the copy in Branding → Email templates.
The default copy is intentionally short:
Your sign-in code is
XXXXXX.Expires in N minutes.
Brief "didn't request this?" footer with a support link.
Don't go long; users glance at the email, take the code, go back to your app.
Phishing risk
Email OTP is more phishable than WebAuthn. The user could be tricked into entering the code on an attacker's site. Two mitigations:
The email's copy should say "this code lets you sign into ". If the user reads it, the phishing context is broken.
Combine email OTP with MFA. A user signing in via email OTP still completes MFA; the attacker who phished the OTP would need the second factor too.
If your threat model warrants stronger primary authentication, prefer WebAuthn (passkey) primary. Email OTP is good but not as strong.
Rate limits + abuse defence
The default rate limits (above) are the abuse-defence baseline. The platform also:
Captcha after N requests from the same IP — kicks in for suspicious patterns; the user solves a captcha before another code is sent.
Reputation-based scoring — the platform's risk engine boosts the suspicion score for sign-ins from known-bad IPs; the rate limits tighten dynamically.
These run by default; you don't configure them.
Email deliverability
The user's email arriving promptly is the whole UX. Things that hurt deliverability:
Unconfigured SMTP. The platform ships a default SMTP provider for prototypes; switch to your own (or a transactional provider like SendGrid / Postmark) for production. See Email SMTP integration.
SPF / DKIM / DMARC misconfiguration. If your sending domain isn't authenticated, Gmail / Outlook silently drop the email. Check at mxtoolbox.com and similar.
Aggressive corporate filters. Some enterprise tenants strip 6-digit codes from emails (paranoid mail filters). Mitigation: keep the code in the email body (text), not in the subject line.
Common questions
"Can users sign up via Email OTP?"
Yes — the same flow handles new-user sign-up. Email OTP arrives → user verifies → if no user record exists, one is created automatically. Enable / disable this auto-create-on-OTP-signup in Authentication → Email OTP → Auto-provision new users.
"What if someone enters the wrong email?"
The platform sends the OTP to whatever they typed. If it's a typo for someone else's email, that person ignores the unsolicited code (and may report it). No account exists at the wrong address, so the typer can't sign in there anyway.
"Can I send the OTP via SMS instead?"
That's a different method — SMS OTP exists separately, but it's not exposed as a primary sign-in method (only as MFA). SMS as primary auth is meaningfully weaker than email (SIM swap attacks), and we don't recommend it.