A 4xx response means the receiver could not take the message now and you should try again. A 5xx means it will not take it at all. Treating either as the other causes distinct and avoidable damage.

The default is wrong for transactional mail

Traditional MTA defaults retry for several days — five is common. That made sense for general correspondence, where a message delivered on Thursday is still useful.

It makes much less sense for a password reset. A reset link delivered two days later is worse than a bounce, because the user has already asked for another one, and now two links exist with unclear validity.

Match the window to the message. Something like:

Password resets, verification codes — one hour, then fail
Receipts, confirmations — four to eight hours
Notifications, digests — a day
Newsletters — the traditional multi-day window is fine

The shape of the schedule

Exponential with jitter. Immediately at first, then widening gaps — one minute, two, five, fifteen, thirty, an hour, capped.

The jitter matters more than it looks. Without it, a batch of a thousand messages deferred at the same moment retries at the same moment, hits the same limit, and defers again. Randomising the interval by twenty percent or so spreads them.

Per destination, not global

Back off per recipient domain. One provider deferring is no reason to slow delivery to the others, and a global backoff converts one provider's busy hour into an outage.

This also means the queue needs to be groupable by destination, which is the main structural difference between a real MTA and a worker pool pulling from a list.

Reading the deferral

Not all 4xx are equal:

Greylisting — a deliberate delay on first contact from an unknown sender. Retry after a few minutes and it goes through. Nothing is wrong.
Rate limiting — slow down. Retrying at the same rate is pointless.
Reputation deferral — the receiver is unsure about you. Retrying delivers eventually; the real fix is elsewhere.
Over quota — the mailbox is full. Retry for a while, then treat repeated occurrences as a dead address.

The response text usually distinguishes these. Logging it and nothing else is a waste of the one diagnostic the receiver gave you.

When to stop

At the window, or when a 4xx becomes a 5xx, or when the same address has soft-bounced enough times to be treated as dead. Five consecutive soft bounces is a common threshold for moving an address to suppression.

Tell the sender

A message that exhausts its retries should surface as an event your application can act on, not a line in a log. The application knows whether to show the user a different route, and it cannot do that if the failure is invisible.

Retry schedules: how long to keep trying