Email Queues and Retry Logic Explained

An email queue is the holding area where a mail server keeps messages that have not yet been delivered, and retry logic is the schedule it uses to try again after a temporary failure. When a message gets a temporary 4xx response, one of the reply-code classes defined in the SMTP standard, RFC 5321, the server does not give up and does not bounce it. It keeps the message queued and retries later, waiting progressively longer between attempts. This backoff continues until the message delivers or the queue lifetime (usually around five days) runs out, at which point it hard-bounces. Queues are why a deferred email often arrives later with no action from you.

What is an email queue and what sits in it?

An email queue is the on-disk list of messages a mail server has accepted but not yet delivered. Every outbound message enters the queue the moment your server accepts it, before any delivery is attempted. Most messages pass through in milliseconds. The ones that linger are the interesting cases: messages waiting on a temporary failure to clear.

A queue entry holds the message, its recipients, and metadata: when it arrived, how many delivery attempts it has had, and when the next attempt is scheduled. You can inspect it. In Postfix, mailq or postqueue -p lists queued mail with the reason each is waiting.

Real postqueue -p output makes the deferral reason obvious:

-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
3F9A1B2C3D     2451 Mon Sep  1 10:31:04  [email protected]
(host gmail-smtp-in.l.google.com refused to talk to me:
 421 4.7.28 Gmail has detected an unusual rate of mail)
                                         [email protected]

The line in parentheses is the receiver's last reply, and it tells you exactly why this message is still sitting there: a 421 4.7.28 Gmail rate-limit deferral. That is a "slow down" signal, not a dead recipient, so the message stays queued and retries. A healthy queue is nearly empty because mail flows through fast. A queue that is filling up is a signal: either you are sending faster than receivers accept, or a destination is deferring you. Reading the deferral reasons in the queue is the first diagnostic step when delivery slows, and those reasons map directly to SMTP bounce code classes.

The mistake we field most often is a panicked operator who sees thousands of Gmail messages stuck behind 421 4.7.28 and runs postqueue -f over and over to "push them through." Each forced flush reopens connections Gmail is already rate-limiting, which deepens the deferral instead of clearing it. We have watched a queue that would have drained on its own in an hour stay jammed for most of a day because the retries were being forced. The right move was to stop touching it and let the backoff do its job.

How does retry logic and backoff work?

Retry logic governs how a server reattempts delivery after a temporary failure, and it uses backoff: each retry waits longer than the last. When delivery returns a 4xx code, the server marks the message deferred and schedules a retry. The first retry might come in a minute or two, the next in several minutes, then in increasing intervals over hours.

This backoff exists for a reason. If a receiver is rate-limiting you or temporarily down, hammering it every few seconds makes things worse and looks like abuse. Spacing out retries gives the temporary condition time to clear and signals you are a well-behaved sender. The exact intervals are configurable; in Postfix, minimal_backoff_time, maximal_backoff_time and queue_run_delay control the rhythm.

A concrete timeline makes the rhythm clear. With Postfix defaults (minimal_backoff_time = 300s, maximal_backoff_time = 4000s), a message deferred at 10:00 retries near 10:05, then around 10:15, then roughly 10:30, with each gap widening until it caps at about every 66 minutes. So a destination that stays unavailable gets perhaps 20 to 30 attempts spread across the five-day window, not thousands of rapid-fire connections. That spacing is exactly why you should not manually flush the queue (postqueue -f) repeatedly during a rate-limit deferral. Forcing retries against a 421 4.7.28 only confirms to Gmail that you are sending too fast. The key behavior to understand: a deferred message is not lost and needs no action from you. It is waiting, and most deferrals resolve on their own. Only persistent deferral, the same destination failing for hours, warrants investigation, often the cause behind why is my email deferred.

What triggers a deferral in the first place?

Deferrals come from temporary 4xx responses, and a handful of causes account for nearly all of them. Knowing which one you are hitting tells you whether to wait or act.

Greylisting is the most common and the most benign. The receiver deliberately rejects the first attempt with 451 4.7.1 to filter out spammers who never retry, then accepts the retry minutes later. That is greylisting working as designed, explained in what is greylisting. Rate-limit deferrals like Gmail's 421 4.7.28 are different: they mean you are sending too fast for your current reputation, and the fix is throttling, not just waiting. A wall of 4xx policy deferrals from one provider is a warning that your IP reputation is slipping.

When does a queued message finally bounce?

A message bounces permanently when the queue lifetime expires before delivery succeeds. Most servers default to about five days of retries (Postfix's maximal_queue_lifetime). Throughout that window the server keeps trying on its backoff schedule. If the temporary condition never clears, eventually the deadline hits and the server gives up.

At that point the server generates a permanent bounce, a Non-Delivery Report, and sends it to the Return-Path address. What was a soft 4xx deferral becomes a hard failure simply because too much time passed. This is why a "mailbox full" address that stays full for a week eventually hard-bounces. Two practical takeaways follow. First, do not panic at deferrals; the queue is doing its job and most clear long before the deadline. Second, watch for messages that sit in the queue for days, because those are about to bounce and usually point at a real problem (a dead destination, a reputation block, or a misrouted domain). Decoding the final bounce is covered in what is a bounce message.

How BulkEmailSetup helps

On a BulkEmailSetup dedicated SMTP server you get direct visibility into your own queue, so you can see deferrals, read the 4xx reasons, and tune send rates per destination instead of guessing. We help configure sensible backoff and rate limits, and because the IP is yours and warmed, you hit far fewer rate-limit deferrals in the first place. See plans on our pricing page.

Frequently asked questions