Email Queue

An email queue holds messages a mail server has accepted responsibility for but has not yet delivered. Because SMTP delivery is asynchronous — the destination may be unreachable, slow, or temporarily refusing — every MTA needs somewhere to keep a message between acceptance and delivery.

Once a server has answered 250 at the end of DATA, it has promised to deliver the message or to tell the sender why it could not. The queue is where that promise lives.

Which queues does Postfix have?

Postfix splits the work across several directories under /var/spool/postfix, and knowing which one a message is in tells you what is happening to it:

deferred is the one worth watching. A handful of messages there is normal; a few thousand means something is systematically failing.

How does retrying work?

A 4xx response leaves the message queued, and Postfix retries with a growing interval — controlled by minimal_backoff_time and maximal_backoff_time — until maximal_queue_lifetime is reached, five days by default. At that point the message is returned to the sender as a bounce.

A 5xx response does not queue at all. The message bounces immediately.

The long default lifetime exists so a destination can be down for a working day without anyone losing mail. It also means a queue can hide a problem for days before anything visibly breaks.

How do you inspect the queue?

$ mailq
-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
E900C4780073     462 Wed Nov  4 13:36:46  root@mail.example.com
(Host or domain name not found. Name service error for name=gsmail.com type=MX: Host not found, try again)
                                          someone@gsmail.com

$ postqueue -p           # same output
$ postqueue -j           # JSON, for scripting
$ postcat -q <ID>        # show a single queued message
$ postsuper -d <ID>      # delete a single message
$ postqueue -f           # flush: retry everything now

The parenthesised line is the reason for the deferral, and it is usually the answer on its own — a DNS failure, a connection timeout, or a remote 4xx. The commands and their pitfalls are covered in detail in manage Postfix mail server queues like a pro.

What does a growing queue mean?

Read the deferral reasons before doing anything else. The common causes fall into three groups:

• Something is wrong locally. DNS resolution failing, a full disk, a content scanner that has stopped responding. The giveaway is that deferrals name many unrelated destinations at once.
• One destination is refusing you. Deferrals concentrated on one provider, often with a 4xx message naming a blocklist, mean a reputation problem rather than an outage — see IP blacklisting and DNS blocklists.
• You are sending mail you did not intend to. A queue full of messages to recipients nobody in your organisation knows, from one account, is a compromised mailbox pushing spam. This is frequently the first place such a compromise becomes visible.

Why is postqueue -f not the answer?

Flushing forces an immediate retry of everything deferred. When the destination was briefly unavailable and has recovered, that is useful. When the destination is rate-limiting or throttling you, repeated flushes make it worse: the remote side sees a burst of connections from an address it is already unhappy about, and reputation damage from that pattern outlasts the incident by a long way.

Fix the cause, then flush once.

Why monitor queue size?

Because it is a leading indicator. Queue growth shows up before users notice missing mail, before a blocklist entry appears, and before anyone opens a ticket. A simple threshold alert on the deferred count catches DNS failures, outbound blocks and compromised accounts alike.

Two practical approaches: a shell script on a cron job with push notifications, as in monitoring Postfix email queue and add push notifications, or a graphing plugin so you can see the shape of the growth rather than a single number.