Infrastructure Behind OTP Delivery: Engineering for Near-Zero Latency

• July 2021
• Engineering Memo · External Release

One-time password (OTP) emails — two-factor authentication codes, magic sign-in links, password reset tokens, and transaction verification codes — are the latency-critical subset of transactional email. While a promotional campaign that delivers over 4 hours is commercially acceptable, an OTP that arrives 4 minutes after the user's authentication attempt has already expired and frustrated the user. OTP delivery latency directly affects authentication success rates, user experience satisfaction scores, and in extreme cases, account security (users who give up on OTP-protected flows may disable 2FA or choose weaker authentication methods).

This note documents the infrastructure requirements for sub-60-second OTP delivery at production scale: the architecture decisions, configuration choices, and monitoring practices that ensure OTP messages reach recipients' inboxes within the latency window that the authentication flow requires.

The OTP Delivery Latency Budget

The total latency from OTP trigger (user initiates authentication) to OTP available in inbox consists of four components: application processing time (generating and storing the OTP, constructing the email message, injecting it into the MTA — typically 100–500ms for a well-optimised application), MTA processing time (accepting the injection, adding DKIM signature, entering the delivery queue — typically 50–200ms), SMTP delivery time (TCP connection to ISP MX server, SMTP session, message transfer — typically 200–800ms for a direct delivery with no greylisting), and ISP processing time (receiving ISP processes the message, routes it to the inbox, makes it available to the mail client — typically 1–10 seconds for major ISPs, occasionally longer for ISPs with content processing pipelines).

Total end-to-end OTP latency under ideal conditions: 1–12 seconds. This is well within the user experience threshold of 60 seconds that most authentication flows require before the OTP expires. The infrastructure engineering for OTP delivery focuses on preventing the conditions that push this latency to 60+ seconds: MTA queue depth, greylisting deferrals, ISP content filtering delays, and retry cycles.

Greylisting: The Primary OTP Latency Risk

Greylisting — the practice of temporarily rejecting (451) the first delivery attempt from an IP-domain-recipient combination and accepting subsequent retries — is the primary source of unexpected OTP delivery latency. A greylisting ISP that imposes a 5-minute minimum retry window converts a 6-second OTP delivery into a 5-minute+ delivery — which often exceeds the OTP's validity period and forces the user to re-request a code.

Greylisting is particularly common at EU consumer ISPs (GMX, T-Online, Free.fr, Orange) and at some corporate mail servers. Gmail does not greylist. Yahoo does not greylist systematically. Microsoft Outlook applies limited greylisting to new or low-reputation senders. The greylisting risk for OTP delivery is highest for programmes sending to EU consumer email addresses through infrastructure that has limited prior sending history to those ISPs.

The infrastructure mitigation for greylisting is warm, established IP reputation with each relevant ISP. An IP that has an established sending history with GMX — regular promotional sends over weeks and months — is typically not greylisted by GMX. The greylisting response is applied primarily to unfamiliar senders (new IPs with no prior sending history to that ISP) and to IPs with poor reputation signals. Maintaining transactional sending through the same IPs that handle promotional sends ensures that the transactional IPs have established, positive relationships with all major ISPs before the OTP delivery requirements depend on those relationships.

A second mitigation: configure PowerMTA's retry interval for OTP-specific VMTAs to use very short initial retry times (1–2 minutes) rather than the standard 5–15 minute intervals appropriate for promotional email. This allows OTP messages that are greylisted to retry more aggressively, clearing the greylist window as quickly as possible. The short retry interval for OTP VMTAs does not generate the reputation concerns that aggressive retry for promotional email would cause, because OTP volume is naturally low and the retry pattern is recognisably legitimate transactional behaviour at ISPs that observe it.

Queue Priority and Queue-Life for OTPs

OTP messages must be assigned the highest priority in the PowerMTA queue, ensuring they are processed before any promotional or cold email messages that may be competing for SMTP connection slots to the same ISP. PowerMTA's priority setting (0 = highest, configurable per virtual MTA or per message via X-Priority header) should be set to maximum for the OTP VMTA, ensuring that a high-volume promotional campaign does not delay OTP delivery by occupying all available SMTP connections to a specific ISP.

Queue-life for OTP messages should be very short — 15–30 minutes maximum. An OTP that has been in the delivery queue for 30 minutes has almost certainly expired from the authentication perspective; continuing to retry delivery for 3–5 days (as a promotional message might) wastes infrastructure resources and delivers a useless message to the recipient. Configuring a 15-minute queue-life for the OTP VMTA ensures that undelivered OTPs expire cleanly rather than cluttering the queue with messages whose delivery is no longer useful.

The short queue-life requires that the application layer is notified when OTP messages expire without delivery, so it can communicate the delivery failure to the user (allowing them to re-request an OTP) rather than leaving the user waiting for a code that has been silently discarded. The delivery callback mechanism in PowerMTA (configured via the accounting log bounce handler) should trigger an application webhook for expired OTP messages, allowing the application to present a "code not received — please re-request" UI state rather than leaving the user in a waiting state.

IP Reputation Requirements for OTP Delivery

OTP delivery requires High IP reputation at all major ISPs where users hold accounts. A Low or Bad IP reputation at Gmail produces aggressive spam filtering that places OTP emails in the spam folder — where they may go unnoticed by users who don't think to check spam for authentication codes. A single OTP delivered to spam rather than inbox is a support event; a pattern of OTP spam delivery is an authentication infrastructure failure that degrades account security across the programme.

The IP reputation requirement for OTP delivery is more demanding than for promotional delivery because OTP messages cannot be unsent or remediated. A promotional campaign that experiences spam folder placement produces lower engagement than expected — a recoverable commercial impact. An OTP that experiences spam folder placement produces a failed authentication attempt — an immediate user experience failure with potential security implications. The operational standard for OTP IP reputation is therefore High reputation at all major ISPs, maintained as a business continuity requirement rather than a deliverability best practice.

The dedicated transactional IP pool (described in the traffic separation note) provides the isolation that enables High OTP delivery reputation independently of promotional email quality signals. When the OTP IP pool's reputation is exclusively determined by OTP delivery signals — near-zero bounce rates, near-zero complaint rates, high positive engagement from expected transactional messages — the reputation naturally reaches and maintains High without the contamination from promotional or cold email signals that co-mingled infrastructure would introduce.

OTP delivery is the highest-consequence email infrastructure use case because its failure is immediately visible and immediately impactful: users cannot authenticate, cannot reset passwords, cannot complete transactions. Building the infrastructure that delivers OTPs reliably within the authentication window — dedicated IPs with High reputation, maximum queue priority, short queue-life, aggressive retry for greylist clearance, and application-layer delivery confirmation — is the technical foundation of account security and authentication user experience. It is infrastructure investment with direct, immediate user impact on every authentication event the programme handles.

Monitoring OTP Delivery Latency

Standard email deliverability monitoring measures delivery rate — the proportion of messages that receive a 250 OK response. For OTP messages, the more operationally relevant metric is delivery latency — the time from injection to 250 OK. A message that delivers 45 minutes after injection has a 100% delivery rate but a 0% successful authentication rate (because the OTP expired). Standard monitoring does not capture this latency-specific failure mode.

OTP delivery latency monitoring requires instrumenting the accounting log to record the time between message injection (queue entry timestamp) and delivery (250 OK timestamp). This per-message latency calculation can be computed from the accounting log fields: delivery_time - queue_entry_time = latency_seconds. The median and 95th percentile latency for OTP messages should be reported in the daily monitoring review.

Alert thresholds for OTP latency: median latency above 30 seconds warrants investigation (something is adding unexpected delay to the typical delivery path); 95th percentile latency above 60 seconds warrants immediate investigation (a significant fraction of OTPs are being delayed past the typical validity window). The 95th percentile threshold is the more important operational metric — it captures the tail of the distribution where users are actually experiencing authentication failures, which the median hides.

The application-layer complement to accounting log monitoring: log the time between OTP email trigger and the user's successful authentication (if it occurs) in the application's analytics. This end-to-end latency measurement — from OTP send to authentication success — captures the full delivery experience including ISP processing time, mail client sync time, and user response time. A rising 95th percentile in this application-layer metric that correlates with rising accounting log delivery latency confirms that infrastructure latency is driving authentication latency, making the infrastructure investigation clearly the correct response.

ISP-Specific OTP Delivery Considerations

Gmail: OTP delivery to Gmail is typically fast (1–5 seconds) for High-reputation senders. Gmail does not apply greylisting to established senders. Content filtering for clearly transactional messages (short messages with one-time codes, no promotional content, expected From: address) is minimal. The primary risk for Gmail OTP delivery is IP reputation — a Low or Bad reputation IP produces spam folder placement that users miss. Maintain High IP reputation on the OTP pool and Gmail OTP delivery will be consistently fast and reliable.

Yahoo: Yahoo applies light greylisting to some senders; established IPs with good reputation are typically not greylisted. Yahoo's content processing for transactional messages is fast — OTP delivery within 5–10 seconds is typical for High-reputation senders. The same IP reputation maintenance practices that ensure Gmail OTP reliability apply to Yahoo.

Microsoft (Outlook/Hotmail): Microsoft has more aggressive content filtering than Gmail or Yahoo for some message categories. OTP messages from known-good senders (High SNDS status, Green SNDS complaint rate) typically deliver within 10–20 seconds. OTP messages from IPs with Yellow or Red SNDS status may experience more aggressive content filtering — a yellow SNDS status on the OTP pool warrants immediate investigation and remediation to prevent OTP reliability degradation.

Corporate email (Microsoft 365, Google Workspace): Corporate email environments may have additional spam filtering layers (Microsoft Exchange Online Protection, third-party cloud email security solutions) that add latency to OTP delivery. These layers can add 10–60 seconds to delivery for messages that pass content inspection, or much more for messages that are held for quarantine review. OTP messages from clearly established transactional sending infrastructure (well-maintained IP reputation, correct authentication, clear transactional message format) typically bypass quarantine review — but programmes sending OTPs to corporate email environments should monitor delivery latency for corporate domains specifically to detect when content security layers are adding unexpected latency.

Fallback Mechanisms: SMS and TOTP

Infrastructure engineering for email OTP delivery must acknowledge that no email infrastructure produces 100% delivery within 60 seconds at all ISPs under all conditions. Some users will experience delayed OTP delivery due to factors outside the infrastructure's control: ISP temporary processing delays, corporate email security scanning, aggressive spam filtering for recipients who have previously marked similar messages as spam, or mobile mail client sync delays.

The most robust authentication architecture therefore includes fallback mechanisms: SMS OTP delivery for users whose email OTP has not arrived within 60 seconds, or time-based OTP (TOTP) authenticator app support that removes email delivery entirely from the authentication path. These fallbacks should be presented to users automatically when email OTP delivery latency exceeds the programme's threshold — "Haven't received your code? Get a new one" or "Use your authenticator app instead" presented at the 60-second mark reduces user frustration and authentication abandonment without requiring manual support intervention.

The infrastructure engineering for email OTP delivery is not about achieving perfect reliability in isolation — it is about achieving reliability that is high enough that fallback mechanisms are rarely needed, while ensuring that fallback mechanisms are in place for the cases where email infrastructure limitations make perfect reliability impossible. The combination of excellent infrastructure (for the common case) and reliable fallbacks (for the edge cases) produces the authentication user experience that both security requirements and user satisfaction demand.

OTP delivery is the email infrastructure use case where latency matters more than volume, where reputation is a security requirement rather than just a deliverability metric, and where the infrastructure investment is justified directly by authentication success rates rather than indirectly through revenue attribution models. Understanding these specific requirements and building infrastructure that meets them — with dedicated IPs, maximum queue priority, short queue-life, aggressive retry, and latency-specific monitoring — is the engineering work that makes OTP delivery reliable enough to trust as an authentication mechanism at scale.

Message Format for OTP Deliverability

OTP message format affects deliverability through content filtering. ISPs that apply content-based spam filtering evaluate message content signals including message size, text-to-HTML ratio, URL count, and content patterns that match known spam fingerprints. OTP messages that include excessive HTML formatting, multiple links, marketing language, or promotional content alongside the OTP code produce higher false-positive spam filter rates than minimal, clearly transactional messages.

Best practice OTP message format: plain text or minimal HTML with a clear message structure (the OTP code prominently displayed, a brief explanation of why the message was sent, and a single support link if needed). Message size under 5KB. No tracking pixels or URL shorteners. Sending From: address that clearly identifies the programme (noreply@company.com rather than a generic or obscured address). Subject line that clearly identifies the content (Your verification code, Sign-in code for [Programme], etc.) without urgency language that spam filters associate with phishing.

The From: address for OTP messages should be stable and consistent — changing the From: address breaks the ISP's recognition of the sender, potentially triggering additional content filtering for unfamiliar senders at ISPs that track From: address reputation. A consistent From: address for OTP sends builds the sender recognition that reduces content filtering latency over time, as ISPs learn to route messages from that address quickly based on its established positive reputation.

Shared vs Dedicated OTP Infrastructure

Some programmes attempt to deliver OTPs through shared transactional email providers (Sendgrid, Mailgun, Amazon SES) rather than dedicated infrastructure. Shared transactional providers offer fast time-to-production and no infrastructure management overhead, but they introduce a fundamental reliability risk for OTP delivery: reputation sharing with other customers on the same sending pool.

A shared provider whose IP pool is used by a customer generating spam or complaint spikes may show degraded reputation at specific ISPs during or after the incident — and OTP messages from all customers sharing that pool are affected simultaneously. For programmes where OTP delivery is a security-critical function (authentication depends on it), the shared reputation risk of shared providers is a business continuity risk that dedicated infrastructure eliminates.

Dedicated infrastructure for OTP delivery — a small dedicated IP pool (2-4 IPs) with dedicated VMTA, running on a managed PowerMTA instance — costs substantially less than the SLA cost of OTP delivery failures that shared provider reputation incidents produce. The infrastructure cost is fixed; the incident cost is variable and unbounded. For authentication-critical OTP delivery, dedicated infrastructure is the correct risk management decision even at programme scales where shared providers would otherwise be adequate.

The infrastructure behind OTP delivery is the engineering foundation of account security and authentication reliability. Invest in it proportionally to the importance of authentication to the programme's security model and user experience. For programmes where failed authentication produces significant user impact or security risk, dedicated OTP infrastructure with the configuration described in this note is not an engineering nicety -- it is the operational standard that the authentication use case requires.

OTP Delivery SLA Definition and Measurement

Programmes that depend on OTP delivery for authentication should define and measure an explicit OTP delivery SLA: a specific latency target (e.g., 95% of OTPs delivered within 30 seconds) measured against specific ISP destinations (Gmail, Yahoo, Microsoft, and any other major ISPs that account for more than 5% of user base email addresses). This SLA definition converts OTP delivery from an informal expectation into a measurable operational target.

Measuring the SLA requires the accounting log latency measurement described earlier, segmented by destination ISP. A weekly SLA report showing the 50th and 95th percentile delivery latency per major ISP, compared against the target thresholds, provides the visibility needed to identify when OTP delivery performance is approaching or breaching SLA targets before user-facing authentication failures confirm the degradation.

When the SLA is breached -- 95th percentile latency exceeding the target threshold at a specific ISP -- the investigation protocol mirrors the reputation event investigation from the IP protocols note: identify which ISP is generating the elevated latency, check that ISP's reputation metrics (Postmaster Tools, SNDS) for the OTP IP pool, review the accounting log SMTP response codes for OTP messages to that ISP, and trace the elevated latency to its specific infrastructure cause (greylisting, content filtering delay, or IP reputation change). The SLA breach is the alert; the investigation identifies the cause; the protocol determines the response.

OTP delivery SLA management transforms authentication reliability from an aspiration into an operational commitment. Define the SLA based on the authentication flow's actual OTP validity window and user experience requirements. Measure it consistently from the infrastructure data. Investigate breaches promptly. This discipline is what makes OTP delivery infrastructure professionally managed rather than informally maintained -- and the difference matters at the moment when a user's authentication depends on the infrastructure delivering correctly within the required window.