Retry policies for outbound mail: backoff and give-up times

import random

def next_delay(attempt: int, base: float = 30.0, cap: float = 3600.0) -> float:
    """Full-jitter exponential backoff, in seconds."""
    exp = min(cap, base * (2 ** attempt))
    return random.uniform(0, exp)

How long to keep trying#

RFC 5321 suggests that SMTP retry intervals should generally be at least 30 minutes and that senders should keep trying for at least four to five days before giving up. That guidance reflects the protocol's store-and-forward heritage, and it remains a sensible default for ordinary mail.

But for many transactional messages, late delivery is worse than no delivery. Match the give-up time to the message's useful life:

Attach an expiry to each message when it is created, and have workers drop messages past their expiry instead of delivering them. A sign-in code that arrives two hours late only confuses the user.

Respect the receiver's signals#

Large mailbox providers use temporary failures to slow senders down. A 421 response with text like "try again later" or a reference to rate limits is a request to reduce throughput, not just to retry one message.

• Back off per destination. If one provider is deferring you, slow all traffic to that provider, not just the deferred message.
• Reduce concurrency to that destination: fewer simultaneous connections and fewer messages per connection.
• Avoid retrying from many IPs at once, which can look like evasion and may defeat greylisting.
• Increase gradually once deferrals subside.

This adaptive behavior matters more than the exact backoff formula.

Tell users what is happening#

When a message is in retry, the application should know. Expose a status such as "delayed, retrying" so support can answer questions, and consider product affordances for time-sensitive mail: a "resend code" button that issues a fresh code rather than retrying a stale one, or a note that delivery may take a few minutes.

When a message finally gives up, record why. "Gave up after 5 days; last response 452 4.2.2 mailbox full" is actionable. "Failed" is not.

Avoid retry amplification#

Retries multiply load. If your application retries five times, your queue library retries three times per attempt, and your HTTP client retries twice per call, a single failure can generate thirty requests. Pick one layer to own retries, usually the queue worker, and set the others to fail fast.

Similarly, always retry with the same idempotency key, so a request that actually succeeded before timing out is not sent again.

Policy checklist#

• Classify responses: retry 4xx SMTP, 429, 5xx HTTP and network errors; never retry permanent failures.
• Use exponential backoff with jitter.
• Honor Retry-After.
• Set give-up times per message type based on useful life.
• Back off per destination when a receiver defers broadly.
• Retry in one layer only, with the same idempotency key.
• Record the final response and reason for every give-up.

Key takeaways#

• There are two retry loops, app-to-provider and provider-to-recipient, and each needs a policy.
• Retry temporary failures with exponential backoff and jitter; never retry permanent ones.
• RFC 5321's multi-day retry guidance suits ordinary mail, but time-sensitive messages should expire much sooner.
• Deferrals from big providers are a signal to slow down overall, not just to retry.