Why 2FA email codes need faster delivery than you'd think

A one-time code for 2FA is one of the few transactional email types where users are actively staring at their inbox, refreshing, waiting. A password reset email arriving 90 seconds late is mildly annoying. A 2FA code arriving 90 seconds late, after the user has already given up and hit "resend," is a support ticket and a bad first impression.

What actually determines delivery speed

The API call itself is nearly instant; the variable is everything downstream. Recipient mailbox provider load, whether your sending domain has an established reputation, and whether the message triggers extra scrutiny (a brand-new sending pattern looks different to a spam filter than an established one) all affect how fast a message actually lands in the inbox versus sitting in a queue.

Where email genuinely struggles against SMS for this use case

Being honest about the tradeoff: SMS delivery for OTP codes is typically faster and more predictable than email, since it doesn't pass through the same spam-filtering layers. If your 2FA flow is latency-critical and you're seeing users complain about delay, that's a real signal to at least offer SMS as an alternative, not just a reason to blame the email provider.

The resend problem

A user who doesn't see the code within 20-30 seconds often hits "resend" before the first code has actually finished delivering, which now means two codes are in flight and the user doesn't know which one is current. Design around this: invalidate the previous code the moment a new one is requested, and rate-limit resend requests (a short cooldown, a few seconds) so a user can't accidentally generate a queue of five codes by repeatedly tapping resend while impatiently waiting.

Code expiry and single-use enforcement

OTP codes should expire quickly, 5-10 minutes is typical, and be invalidated immediately after one successful use, the same single-use discipline that applies to password reset tokens. A code that stays valid for hours, or that can be reused after a successful login, is a meaningfully weaker security control than the 2FA flow is supposed to provide in the first place.

What you can actually control

• Keep OTP emails on a well-established sending domain with real history, not a brand-new subdomain nobody's mailbox provider has seen before
• Don't batch OTP sends with anything else, they should be a single, immediate, isolated send
• Set a realistic expectation in your UI ("this can take up to a minute") rather than implying instant delivery you can't fully guarantee
• Monitor actual delivery times through your provider's logs, not just "the API call succeeded", a successful API response only means the message was accepted, not that it landed

A hybrid approach worth considering

Rather than choosing email or SMS exclusively, some products offer email as the default (cheaper, no per-message carrier cost) with SMS available as a fallback if a user hasn't received their code within a set window, or as a user preference for accounts that specifically need faster guaranteed delivery. This keeps the cost profile of email for the common case while giving latency-sensitive users a real alternative rather than a support ticket.