---
title: "Email Queue"
description: "A mail queue holds messages a server has accepted but not yet delivered. Its size and composition are one of the most useful health signals a mail server has."
url: "https://mailmum.io/glossary/email-queue/"
---

# 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](https://mailmum.io/glossary/mail-transfer-agent-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:

| Queue | Contents |
| --- | --- |
| `incoming` | newly accepted, not yet processed |
| `active` | currently being delivered; deliberately kept small |
| `deferred` | delivery failed temporarily, waiting for a retry |
| `hold` | placed aside by an administrator, never retried automatically |
| `corrupt` | unreadable files, kept for inspection |

`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](https://mailmum.io/glossary/bounce-message/).

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?

```sh
$ 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 &mdash; 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](https://mailmum.io/posts/manage-postfix-mail-server-queues/).

## 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 &mdash; see
  [IP blacklisting](https://mailmum.io/glossary/ip-blacklisting/) and
  [DNS blocklists](https://mailmum.io/glossary/dns-blocklist-dnsbl/).
* **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](https://mailmum.io/glossary/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](https://mailmum.io/posts/monitoring-postfix-email-queue-with-push-notifications/),
or a graphing plugin so you can see the shape of the growth rather than a single
number.