What is a good retry schedule (e.g., increasing intervals)?
Still have a question, spotted an error, or have a better explanation or a source we should cite?
You send an email, the receiving server hiccups, and the message bounces back with a 4xx code. That's not a permanent rejection. It's a "try again later." So how long should you wait before trying again, and when do you finally give up?
The standard approach is exponential backoff. Each retry waits longer than the last. A typical schedule looks like this:
- Retry 1: 5 minutes after the first failure
- Retry 2: 15 minutes
- Retry 3: 30 minutes
- Retry 4: 1 hour
- Retry 5: 2 hours
- Retry 6: 4 hours
- Retry 7: 8 hours
- Retry 8 onward: every 12 hours
The first few quick retries exist to catch brief outages, like a server that was overloaded for 90 seconds. Longer gaps give the receiving side time to sort out bigger problems without your system hammering them over and over.
The total retry window is usually 48 to 72 hours. If an email still hasn't delivered after three days, the issue is very likely not temporary anymore. Most receiving servers expect you to give up around that point anyway. Time-sensitive messages (like a one-time passcode) can use a much shorter window, sometimes just 30 minutes total.
Now one important distinction worth knowing: retry logic only applies to temporary failures (4xx codes). A 5xx response is a permanent rejection. The receiving server is telling you flat out that this address doesn't exist or the message isn't wanted. You don't retry those. You suppress the address and move on.
There's also a special case worth knowing: greylisting. Some servers temporarily reject the very first delivery attempt from an unknown sender, on purpose, expecting a legitimate mail server to try again. Your first retry can come fairly quickly in that case (5 to 10 minutes). Most modern sending infrastructure handles this automatically.
If you're building retry logic yourself, add a small random offset to each retry time (sometimes called jitter). It prevents multiple queued messages from all retrying at exactly the same second, which can spike load on both sides.
Not sure whether your current setup handles retries correctly? Our SOS hotline is free if you're debugging something that's breaking right now.
Contributors
Who worked on this answer
Every name links to their profile. Every company links to their site. Real people, real accountability.