What is standard retry timing (RFC 5321)?
Still have a question, spotted an error, or have a better explanation or a source we should cite?
Your email hits a temporary wall. The receiving server sends back a 4xx code that says, essentially, "not right now." What happens next? Your sending server doesn't give up. It queues the message and tries again. That retry behavior is what RFC 5321 defines.
RFC 5321 recommends that sending systems keep trying for at least 4 to 5 days before giving up on a message. The first retry shouldn't happen immediately. There should be a delay, and then subsequent attempts should space out even further over time. The exact intervals aren't prescribed by the spec. That part is left to the sender's implementation.
In practice, a typical retry sequence might look like this: first retry after 5 minutes, then 30 minutes, then a few hours, then once or twice a day until the 4-to-5-day window closes. Some ESPs use exponential backoff, where the gap between retries doubles each time. The idea is to avoid hammering a struggling server while still giving the message a fair shot at delivery.
Why does this matter for your retry count? Because repeated failed attempts at a server that's actually down aren't the same as spammy behavior. Receiving servers and reputation systems understand the difference between a legitimate retry queue and a flood. Spacing your retries correctly signals that you're a well-configured sender, not someone blasting blindly.
That said, modern practice does diverge from RFC 5321 for one category of email. Marketing messages are time-sensitive. If a promotional email about a 24-hour sale is still bouncing around your queue four days later, delivering it on day five doesn't help anyone. Most senders shorten the retry window for marketing to 24 to 48 hours. Transactional messages (password resets, order confirmations, shipping alerts) usually keep the longer window because they still matter days later.
The 4xx response that triggers all this is a soft bounce. If the same address keeps returning 4xx codes over multiple retry cycles, at some point you need to decide whether it's ever going to deliver. That's when a soft bounce graduates to a hard bounce in your suppression list.
If you're unsure how your ESP handles retry timing or whether it's configured well for your sending mix, that's worth a quick look. It's one of those settings that's easy to miss and surprisingly easy to get wrong.
Contributors
Who worked on this answer
Every name links to their profile. Every company links to their site. Real people, real accountability.
