How to Handle Email API Rate Limits in Password Reset Flows Without Duplicate Sends

When an email provider returns a 429 (rate limit) response during a password reset flow, treating it as backpressure rather than a failure prevents duplicate messages and broken user experiences. The recommended approach separates three distinct clocks: the reset token's security lifetime, the user-facing cooldown period, and the provider-facing retry delay. A durable delivery job should be created within the same database transaction as the reset token, ensuring no valid reset state exists without a corresponding delivery task. Workers, not web processes or users, should handle retry scheduling by honoring the provider's Retry-After header or applying capped exponential backoff with jitter. Public endpoints should always return a neutral response regardless of account existence or provider status, and sensitive token strings must never be used as idempotency keys or appear in structured logs.