What are expected delivery times for one-time password (OTP) emails and how can they be measured?
Updated on 13 Oct 2026: We clarified OTP timing targets and measurement limits, tightened resend rules, and added steps to prevent bulk queues from delaying verification emails.
There is no universal standard for OTP email delivery latency. A practical starting target for request-to-success is under 15 seconds at P50 for excellent performance, under 60 seconds at P95 for a healthy service, and under 2 minutes at P99 when users have a retry or fallback path. Treat these as proposed service-level objectives (SLOs) for verified sessions and check completion rates alongside them. Recurring sessions that take more than 5 minutes need investigation.
Exact time-to-inbox is difficult to measure for production users. Mailbox providers do not expose a consistent inbox-arrival timestamp for real users at scale. Measure request-to-success as the user experience metric: the time between the user's first OTP request and successful server-side code verification. Then use MTA logs, bounces, deferrals, image load timestamps, and controlled inbox probes to explain the outliers.
Illustrative completion targets
A five-second target is useful for request-to-remote-acceptance on healthy routes, but it should not be the service promise for inbox arrival or user completion. Email is store-and-forward infrastructure. The targets below describe verified-session completion time, with unsuccessful sessions reported separately.
- Excellent: P50 request-to-success is under 15 seconds and P95 is under 45 seconds.
- Healthy: P50 is under 30 seconds, P95 is under 60 seconds, and second-code requests are rare.
- Problematic: Provider-specific delays create repeat sends, support tickets, or failed logins.
- Critical: Deferrals, bounces, or spam placement affect a provider or domain group.
Expected OTP email delivery times
Do not report one average delivery time for OTP email. Report P50, P90, P95, and P99 completion times alongside success rate, resend rate, and provider-specific failure rate. State whether percentiles cover verified sessions or all eligible sessions. Average delivery time hides the cases that hurt login and checkout flows, especially when a small provider segment sits behind temporary deferrals.
Illustrative OTP completion thresholds
These thresholds describe request-to-success for verified sessions. Set your own SLOs and report incomplete sessions alongside the percentiles.
Excellent
P50 < 15s
Most users receive and enter the code without noticing delay.
Healthy
P95 < 60s
A small tail exists, but the resend flow does not dominate.
Watch
P99 > 2m
Check provider segments, bounces, throttling, and template filtering.
Act
Recurring > 5m
Repeated long delays point to queueing, deferrals, or filtering.
For a login or account recovery flow, the user experience threshold matters more than the pure mail transport threshold. A user who enters the code in 20 seconds had a successful experience even if the mailbox provider took 12 seconds to show the message. A user who requests three codes in two minutes had a bad experience even if the first message technically arrived.
- P50: The median completion time; half of the measured sessions complete within this time.
- P95: The time within which 95% of the measured sessions complete; use transport events to identify the cause of delays.
- P99: The time within which 99% of the measured sessions complete; compare this tail with failures and abandonment.
- Success rate: The share of eligible sessions verified within the validity window; report first-send and fallback success separately.
- Resend rate: The share of sessions with another code request; investigate delays, non-arrival, and interface confusion.
Why SMTP acceptance is not inbox arrival
Exact inbox arrival is hard because SMTP proves handoff between servers. Your application can record when it generated the OTP. Your email provider can record when it accepted the message for sending. Your outbound MTA can record the receiving server's final 250 response after message data is accepted, as specified in RFC 5321. None of those events prove the message appeared in the primary inbox on the user's device. A "delivered" webhook commonly reports this server handoff, so check its documented meaning.
Mailbox providers can defer messages, throttle senders, scan content, classify mail into folders, cache images, and sync mobile clients on their own schedule. That means a delivery-time benchmark only has meaning when the measurement method is stated clearly.
What you control
- Generation: How quickly the app creates the code and queues the message.
- Queueing: How quickly the sender accepts and attempts delivery.
- Authentication: Whether SPF or DKIM passes and has the required domain match with the visible From domain for DMARC.
- Retry rules: How the MTA handles temporary failures and provider throttling.
What you observe
- Bounces: Hard and soft failures that explain non-arrival.
- Deferrals: Temporary rejections that stretch the delivery tail.
- Image load: The first time the message content is fetched by a client or proxy.
- Code verification: The server timestamp that confirms a valid, unexpired code completed the session.
Provider-specific problems are common. If the pain is concentrated at Gmail, the fixes differ from those for a general queueing problem, and the symptoms often show up as repeated resends or slow code entry. A deeper treatment of Gmail OTP delays is useful when that provider is the main outlier.
Gmail inbox search showing OTP test messages with different received times.
Record OTP events and timestamps
Instrument each verification journey as a session, with a separate attempt ID for each OTP send. The session joins application timestamps, email provider events, MTA events, user actions, and support outcomes. That gives a view of the actual authentication experience.
The minimum viable event model needs one opaque, immutable OTP event ID, one user session ID, a code sequence number, the sender's message ID, and a mailbox-provider label derived from recipient-domain and MX routing data. Keep the OTP value and full recipient address out of analytics. Synchronize source clocks and store timestamps in UTC. Use the provider's event timestamp rather than webhook arrival time, and deduplicate events by ID so delayed or repeated callbacks do not inflate latency or send counts.
OTP timing eventstext
otp_requested 2026-05-27T10:00:00Z otp_created 2026-05-27T10:00:00Z mail_accepted 2026-05-27T10:00:01Z mail_first_attempt 2026-05-27T10:00:02Z remote_accepted 2026-05-27T10:00:04Z first_image_load 2026-05-27T10:00:19Z otp_verified 2026-05-27T10:00:24Z resend_requested null bounce_received null
|
|
|
|
|---|---|---|---|
Request to accept | Request | Sender accept | Application and submission delay |
Sender queue delay | Sender accept | First delivery attempt | Sending backlog |
Request to remote | Request | Remote accept | SMTP handoff |
Request to image load | Request | Image load | Client or proxy content access |
Request to success | Request | Successful server verification | Core KPI |
Attempt to remote acceptance | First try | Remote accept | Transport and retry delay |
Operational metrics for OTP timing.
These events separate application delay, sender queueing, provider deferrals, mailbox visibility clues, and user behavior without treating one timestamp as proof of inbox arrival.
Measure request-to-success
Request-to-success measures the OTP user experience. It reflects whether a valid code was usable quickly enough to complete the task, including time spent finding the email and entering the code. Pair it with request-to-remote-acceptance to separate transport delays from user interaction time.
Keep delivery-side signals in the diagnostic layer. A slow request-to-success metric shows a slow user journey. Delivery-side signals show whether the delay occurred before server handoff, after acceptance, or during user interaction.
Example cumulative OTP completion
Illustrative values, not observed benchmarks. Each bar is the share of all eligible requested sessions verified by that deadline.
5s
42%15s
68%30s
81%60s
90%5m
97%For a live sample, send the OTP template through Suped's email tester and compare headers, authentication results, and rendering with your application timestamps. That does not replace production measurement, but it catches obvious template and authentication issues before users feel them.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
A useful production report combines cumulative completion curves with provider segmentation. Report what share of all eligible sessions succeeds in 5 seconds, 15 seconds, 30 seconds, 60 seconds, and 5 minutes, split by mailbox provider and sending route. In the illustrative chart, 90% complete within 60 seconds, so this cohort misses a 95%-within-60-seconds SLO even if percentiles among successful sessions look healthy.
Count incomplete and expired sessions
Latency percentiles calculated only from successful OTP entries have survivorship bias. Fast completions remain in the dataset while messages that never arrive, expire, or lead to abandonment disappear. Build request-time cohorts and keep every eligible session in the completion-rate denominator. Label successful-session percentiles explicitly. If fewer than 99% of all requested sessions complete within the observation window, an all-session P99 completion time has not been reached.
- Session denominator: Count each initial eligible OTP request once per session, including sessions with no later mail event; track resends as attempts within that session.
- Deadline completion: Report the share verified within 30 seconds, 60 seconds, 2 minutes, and the OTP validity window.
- Unfinished outcomes: Keep expired, bounced, abandoned, and fallback sessions visible beside the latency percentiles.
- Resend handling: Measure user latency from the first request, then measure transport latency for each send separately.
- Observation window: Set a fixed session deadline that resends cannot extend indefinitely, then allow a fixed buffer for late events before closing the cohort.
Give each resend a sequence number while retaining the original session ID. This exposes delayed old-code races, where the first code arrives after a newer code has invalidated it, and stops repeated sends from looking like separate successful journeys.
Segment by provider and domain
A single global OTP timing chart is a starting point, not a diagnosis. If the median is fast but one provider has a long tail, the average still looks fine while real users struggle. Break the data down before drawing conclusions about performance.
- Provider: Group Gmail, Outlook, Yahoo, and iCloud recipients by mailbox provider; use MX routing for custom domains and identify inbound security gateways separately.
- Route: Separate each sending stream, source IP pool, and email provider account.
- Template: Compare OTP, password reset, magic link, and account confirmation mail.
- Outcome: Track success, resend, fallback, bounce, and abandoned session rates.
- Time band: Report P50, P90, P95, and P99 with sample counts and observation windows; avoid drawing conclusions from small provider samples.
Bounce data beats guesses
When one provider has unusually slow OTP completion, check bounces and deferrals before changing template copy. High average delivery times often occur with temporary failures or reputation throttling.
- Soft bounces: Provider terminology varies; separate temporary delivery-delay events from a final bounce after retries are exhausted.
- Hard bounces: Inspect the permanent rejection reason; an invalid address and a policy rejection need different fixes.
- Deferrals: Point to throttling, reputation, or provider-side filtering.
- Resends: Point to user impatience, non-arrival, or a confusing UI state.
Before blaming a mailbox provider, verify the sending domain. Suped's domain health checker checks the published configuration, and ongoing DMARC monitoring helps catch authentication drift before it affects OTP reliability.
Authentication and reputation checks
Authentication does not guarantee rapid inbox placement, but broken authentication can make OTP mail easier to filter, defer, or reject. Configure SPF for the envelope sender, sign with DKIM, and ensure at least one passing identifier has the required domain match with the visible From domain so DMARC passes consistently.
Suped is our DMARC reporting and email authentication platform. Use Suped to review SPF, DKIM, and DMARC results by OTP sending source, then compare authentication changes with timing outliers in your application logs. DMARC aggregate reports usually arrive daily, so they provide historical authentication evidence rather than live OTP delivery timestamps. Alerts and guided issue steps help investigate sender or DNS changes as reports arrive.
Suped DMARC dashboard showing email volume, authentication health, and source breakdown
Suped's blocklist monitoring tracks supported blacklist listings. Compare a listing with the affected route's SMTP rejection or deferral evidence before attributing an OTP delay to it.
Authentication issue
- SPF fail: The envelope sender is not authorized by the published policy.
- DKIM fail: The signature fails validation or references an unavailable selector.
- DMARC fail: Neither a passing SPF nor DKIM identifier has the required domain match with the visible From domain.
- DNS drift: A record change removes a trusted transactional sender.
Likely OTP symptom
- Foldering: The message arrives but is harder for the user to find.
- Deferral: A receiving provider temporarily rejects the message; the sending MTA schedules a retry.
- Rejection: The user never receives a usable code.
- Resend spike: Users request more codes because the first one feels missing.
Keep OTP emails out of bulk sending queues
Treat OTP emails as a time-sensitive transactional email stream. An API can accept a message quickly while a shared worker queue leaves it behind a marketing campaign.
- Use a separate application queue and reserve worker capacity for OTP messages so bulk campaigns do not consume every send slot.
- Use a consistent transactional sending subdomain with authenticated DNS, and keep promotional content out of the OTP template.
- Track the oldest queued OTP and sender queue delay, especially during traffic spikes and campaign launches.
- Load-test application queues and sending limits with controlled recipients. Increase volume gradually and respect mailbox-provider throttling.
Queue separation controls your own backlog. A separate subdomain does not guarantee reputation isolation when streams share an IP pool. Gmail sender guidance recommends separate IPs by message type when multiple sending IPs are used.
Inbox probes and pixels
Controlled inbox probes measure how fast a test message appears in inboxes you own. Send the production OTP template through the same sending route and check both inbox and spam placement across major mailbox providers at different traffic levels. Record the last poll without the message and the first poll with it: a 10-second polling interval gives an arrival window up to 10 seconds wide. Use trusted Received headers to diagnose server hops; the sender-controlled Date header does not prove arrival time.
Tracking pixels help in one specific way. A first image load timestamp can prove that a client or proxy accessed the message content. It cannot prove the exact inbox arrival time, and it can be distorted by image proxying, prefetching, blocked images, and user privacy settings.
OTP email timing flowchart showing request, SMTP acceptance, inbox probes, image loads, and code entry.
Do not over-read seed data
Seed inboxes are useful for controlled monitoring, but they have sampling limits. They do not reflect every recipient, every device sync pattern, or every reputation decision made against real traffic.
- Good use: Catch sudden routing, authentication, or template regressions.
- Bad use: Declare a universal inbox delivery benchmark from a small panel.
- Best use: Pair probe results with production completion and bounce data.
Set expiry and retry rules
OTP expiry should not be based on median delivery time. Even when the median is fast, users in the long tail still need enough time to receive the message, find it, switch apps, and type the code. For email OTP, 5 to 10 minutes is a practical starting expiry window, with a resend option after 30 to 60 seconds. Start validity at server-side code creation, enforce expiry on the server, and accept each code only once. Choose the window for the action's risk and measured completion times.
The retry flow needs to protect users from code confusion. If a new code invalidates the old one, say so clearly in the interface. If multiple codes remain valid, bind them to the same session and invalidate all of them after successful verification. Rate-limit sends and failed verification attempts at account level as well as within the session; requesting another code must not reset the failure count. Show the masked destination, resend countdown, and a reminder to check spam or junk folders.
Example OTP retry policyyaml
otp_ttl_minutes: 10 resend_cooldown_seconds: 45 max_resends_per_session: 3 max_attempts_per_code: 5 max_failed_attempts_per_account_window: 5 attempt_window_minutes: 10 reset_failed_attempts_on_resend: false single_use: true invalidate_previous_code: true bind_code_to_session: true
These example delivery settings do not establish an authentication assurance level. NIST SP 800-63B-4 excludes email as an out-of-band authentication channel; email address confirmation and recovery codes have separate rules. Use an appropriate authenticator for flows that must meet those assurance requirements.
If you are also sending magic links or account confirmation links, the expiry decision has different risk tradeoffs. The same timing logic applies, but the token grants a different kind of access. The related topic of verification link expiry needs its own policy.
When delays need action
Treat OTP delay as an incident when it affects a provider segment, increases abandoned sessions or resend requests, or produces user complaints. The fix path depends on where the delay appears in the event chain.
- Confirm generation: Check that the app creates the code and queues mail immediately.
- Check sender queue: Look for backlog, rate limits, or slow API acceptance.
- Review MTA logs: Separate final remote acceptance from temporary 4xx SMTP deferrals, including greylisting, and permanent 5xx rejections; retain enhanced status codes.
- Split providers: Find whether the delay is general or concentrated.
- Verify auth: Confirm SPF, DKIM, DMARC, TLS policy, and DNS health.
- Read bounces: Map bounce and deferral codes to the slow segments.
- Offer fallback: Use an already enrolled authenticator or an approved account-recovery path; verify any SMS destination before using it and track fallback success separately.
Healthy program signal
If authenticated delivery is stable, bounces are low, and first-send completion meets your agreed SLO, investigate slow provider segments and the remaining failed sessions. Alert on sustained breaches with enough traffic to distinguish an incident from a small-sample fluctuation.
Views from the trenches
Best practices
Measure request-to-success first, then use transport logs to explain the slow tail.
Break OTP timing by mailbox provider so one slow domain group cannot hide in totals.
Track resends beside bounces because both can reveal timing pain before tickets rise.
Common pitfalls
Treating image loads as inbox arrival creates false precision in timing dashboards.
Averaging all OTP sends hides provider deferrals that only affect a small user group.
Setting expiry from median timing alone punishes users caught in normal email delays.
Expert tips
Compare P95 timing with bounce changes before rewriting an otherwise clear template.
Keep email OTP and SMS fallback separate because each channel fails in different ways.
Use seed inboxes for regression checks, not as proof of real user inbox placement.
Marketer view
Marketer from Email Geeks says email is not instant messaging, so OTP benchmarks only make sense when the exact measurement point is defined.
2025-04-10 - Email Geeks
Marketer view
Marketer from Email Geeks says request-to-code-entry is more useful than a claimed inbox timestamp because it measures the user outcome.
2025-04-10 - Email Geeks
Compare Suped reports with OTP timing logs
When OTP timing worsens after a sender or DNS change, compare the affected route and time window in your application and MTA logs with sending-source authentication results in Suped. Use the reports to identify authentication changes, then confirm their effect through delivery events and subsequent completion rates.
