Mail queue: the MTA buffer for undelivered messages

A mail queue is the internal buffer inside a Mail Transfer Agent (MTA) where messages wait until delivery succeeds. When the MTA cannot reach the recipient server right away, because it is down, overloaded, or temporarily rejecting connections, the message goes into the queue for a later retry.

Each MTA manages its own queue. Postfix keeps it under /var/spool/postfix, Exim under /var/spool/exim. Cloud providers like SendGrid and Amazon SES run the queue on their own infrastructure; you only see the delivery statistics they expose.

How the queue is structured

Each queued message is stored as a separate file (or database record) with a set of metadata: message ID, sender address, recipient, time of entry, delivery attempt count, and the scheduled time of the next attempt.

In Postfix the queue is split into several subdirectories:

• incoming — messages just accepted by the server.
• active — messages the MTA is actively trying to deliver right now.
• deferred — messages where delivery failed; next attempt is scheduled.
• bounce — non-delivery notifications the MTA generates and sends back to the sender.
• corrupt — messages with data errors the MTA cannot process.

Retry algorithm

Once a message lands in deferred, the MTA does not retry every few seconds. It uses exponential backoff: the first retry comes after 5 minutes, then 10, 20, 40, and so on. The exact intervals depend on the MTA configuration.

In Postfix, two parameters control this: minimal_backoff_time and maximal_backoff_time. The defaults are 300 seconds and 4000 seconds respectively. A third parameter, maximal_queue_lifetime, sets the upper bound on how long the MTA keeps trying. The default is 5 days. After that, the sender receives a DSN bounce notification.

Why queues grow

A growing queue is a symptom, not a normal state. Common causes:

• Recipient server is unreachable. DNS failures, outages, or maintenance windows cause all messages to that domain to pile up in deferred.
• Greylisting. The recipient server returns a 450 temporary rejection on the first connection from an unknown IP. The message goes into deferred and is delivered on the second attempt.
• Rate limiting. The receiving provider caps connections or messages per hour. Once the limit is hit, excess messages sit in the queue.
• IP on a blocklist. A DNSBL listing causes the recipient server to reject every connection from that IP.
• Sending to invalid addresses. A list with many non-existent addresses generates a flood of bounces, which fills the bounce queue and adds load to the MTA.

Monitoring and managing the queue

Watching queue size is part of routine mail server administration. Useful Postfix commands:

• mailq or postqueue -p — show the current queue.
• postqueue -f — flush: attempt to deliver all deferred messages immediately.
• postsuper -d ALL — delete all queued messages (a last resort).

For Exim, the equivalent tools are exim -bp and exim -qf.

Connection to email validation

Verifying addresses before you send has a direct effect on queue health. A clean list with no non-existent mailboxes and no spam traps keeps bounce volume low. The deferred queue stays small, the MTA runs without strain, and sending IP reputation is not dragged down by excessive bounces.

Without validation the picture reverses: thousands of bounces, a bloated queue, heavier MTA load, and longer delivery delays for all outgoing mail, including transactional messages.