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.

Ask an AI · tailored to your setup

Review my retry logic

I'm building or reviewing email retry logic for my sending infrastructure. Based on my setup, help me decide: 1. How many retries make sense for my use case (transactional vs. marketing)? 2. Should I use a shorter retry window for time-sensitive emails like OTPs or password resets? 3. How should I handle 4xx vs. 5xx errors differently in my queue? 4. At what point should I suppress an address after repeated failures?

Edit the yellow boxes, then send to the AI of your choice.