How do retries work when a message can’t be delivered?

When an email can't be delivered right away, the sending mail server doesn't give up instantly. It parks the message in a retry queue and tries again later. These retry attempts happen on a schedule that stretches out over time: maybe 5 minutes after the first failure, then 15 minutes, then an hour, and so on.

The most common reason for retries is temporary failures. The receiving server might be overloaded, doing maintenance, or rate-limiting incoming connections. As long as the failure is temporary ("try again later" instead of "this address doesn't exist"), the sending server keeps the message in queue and retries until it either succeeds or hits the maximum retry window.

That maximum window varies by ESP. SendGrid retries for 72 hours. Postmark also uses 72 hours for transactional email. AWS SES defaults to 24 hours but you can configure it. After that window closes, the sending server gives up and sends a bounce notification to the Return-Path address (the technical "from" that receives delivery failures).

Retry intervals typically follow an exponential backoff pattern: short gaps at first (when the issue is likely temporary and quick to resolve), then longer gaps as time goes on (when it's looking more like a persistent problem). A typical schedule might look like: 5 min, 15 min, 30 min, 1 hour, 2 hours, 4 hours, 8 hours, and so on until the retry window expires.

Why the increasing intervals? Bombarding a server that's already struggling doesn't help anyone. If the receiving server is overloaded or rate-limiting, repeated rapid retry attempts just add to the load. Spreading out the retries gives the issue time to resolve without adding pressure.

This is all automatic. You don't control the retry schedule directly (that's managed by your ESP or mail server software). What you DO control is the Return-Path address where bounce notifications land. If that address isn't monitored, you'll never know when messages fail permanently after retries expire. Most ESPs handle this automatically, but if you're running your own mail server or using a custom SMTP setup, setting up proper bounce handling is on you.

Now one edge case worth knowing: some receiving servers respond with temporary failures when they actually mean permanent failures. A server might say "try again later" for a mailbox that doesn't exist, hoping the sender will retry a few times and then give up (rather than immediately bouncing and tipping off spammers that the address is invalid). That's why you'll sometimes see messages bounce after 24-72 hours even though the address never existed in the first place.

And if you're seeing a lot of retries in your queue management dashboard, it usually means one of two things: either the receiving servers are temporarily overwhelmed (common during high-traffic periods), or your sending reputation is triggering rate limits and you need to adjust your sending speed.