How do ESPs queue and retry messages?

You hit send on a campaign and most emails land instantly. But some don't. A receiving server might be busy, temporarily rate-limiting you, or just having a rough afternoon. So what happens to those messages? They don't disappear. They go into a queue.

Here's how the whole process works.

The queue itself

When your ESP accepts a message, it holds it in an outbound queue before attempting delivery. Think of it as a waiting room. The message sits there until the system has an available connection to the recipient's mail server, and then it tries to send. For most messages, this happens within seconds.

SMTP response codes tell the story

When the receiving server responds, it sends back a three-digit SMTP code. That code determines what the ESP does next:

• 2xx codes mean success. Message delivered, removed from queue.
• 4xx codes are temporary failures. The server is saying "not right now, try again later." The ESP keeps the message in the queue and retries.
• 5xx codes are permanent failures. The server is saying "this address doesn't exist" or "we won't accept this." The message is removed from the queue and logged as a hard bounce.

Retry logic and backoff

Still a 4xx response doesn't mean the message failed. It means the ESP will try again. Most systems use an exponential backoff schedule, meaning each retry waits longer than the last. A rough pattern looks like this:

• First retry after a few minutes
• Second retry after 30 minutes
• Third retry after a few hours
• Subsequent retries spread across the next 24 to 72 hours

This backoff approach is intentional. Hammering a server that's already struggling with repeated rapid attempts would make things worse, and aggressive retry patterns look a lot like spam behaviour.

Maximum retry window

ESPs don't retry forever. Most commercial ESPs retry for 24 to 72 hours before giving up. Self-hosted MTAs like Postfix default to a five-day retry window, which follows the original SMTP RFC recommendations. After the window closes, the message is bounced back to the sender as undeliverable.

Prioritisation inside the queue

Transactional emails (password resets, receipts, order confirmations) often get their own queue with higher priority than marketing campaigns. This is called stream separation, and it's the reason a well-configured sender won't have their password reset emails stuck behind a bulk campaign that's hitting throttling from Gmail.

What this means for you practically

So if your ESP reports a soft bounce, that's a 4xx in action. The message was retried and eventually gave up. Frequent soft bounces from the same addresses often signal a pattern worth investigating, whether that's a domain that's been abandoned or a corporate mail server that throttles aggressively. Repeated soft bounces on the same address that never resolve are a good reason to suppress that contact before they start affecting your sender reputation.

You can dig into exactly what happened to any message by reading its message ID in the delivery logs. ESPs like Postmark and Twilio SendGrid give you per-message delivery events with the actual SMTP response codes, which is genuinely useful when something goes sideways.

If your logs are showing unexplained retry patterns or messages sitting in queue longer than they should, our Email Header Analyzer can help you read what actually happened. Or if you want a human to look at it with you, the SOS hotline is free.