Flush Postfix Mail Safely and Understand fast_flush
You will learn how to ask Postfix to retry deferred mail, how to retry one destination or queue ID, and what the flush(8) service actually does. The practical work takes about five minutes if Postfix is already running. You need shell access to the mail host; the queue-control commands normally need the Postfix administrator's privileges.
The route
Jump straight to the step you need, or tick off Done means at the end.
Before you start
This guide is for the Postfix package installed on this machine. Its reported version is 3.8.6. Check the active version and make sure the queue is the one you intend to operate on:
postconf mail_version
postqueue -p
The first command should report the installed Postfix version. The second lists queued mail. Read the listing before flushing it: a flush starts delivery attempts, but it does not repair DNS, authentication, routing, remote server refusal, or any other reason a message was deferred.
Checkpoint
You know whether the queue is empty, which destinations are affected, and whether a retry is safe. Do not repeatedly flush an undeliverable queue. The Postfix documentation warns that frequent flushing can harm delivery performance for other mail.
1. Flush the whole queue
To ask the queue manager to attempt delivery of all queued mail, run this as the Postfix administrator:
sudo postqueue -f
The command requests a queue scan. It does not guarantee delivery, remove messages, or bypass normal transport policy. A message that still cannot be delivered remains queued and will have another reason recorded for later inspection.
Verify the queue after allowing time for a delivery attempt:
postqueue -p
Compare the queue listing with the earlier one. A disappearing message may have been delivered, bounced, or otherwise moved by normal Postfix processing; use the Postfix log and the message's queue ID when you need to distinguish those cases.
Checkpoint
A successful postqueue -f means that Postfix accepted the request to scan the queue. It is not a delivery receipt.
2. Retry one destination
When one remote site has recovered and you do not want to provoke retries for unrelated mail, use the fast-flush destination operation:
sudo postqueue -s example.net
Replace example.net with the destination site you have verified. Postfix identifies a destination from the part after the right-most @. This operation only benefits destinations eligible for fast flush. By default on this installation, that means $relay_domains, not every possible Internet domain.
For an eligible destination, Postfix records deferred queue IDs in a per-destination logfile and uses that record to request immediate delivery. The request can cover all messages recorded for that destination, so inspect the queue first if that scope matters.
If the command reports that the site is not eligible, do not work around it by editing /var/spool/postfix/flush. Use the whole-queue operation when appropriate, or review the relay configuration with the mail administrator.
3. Retry one queue ID
For a single deferred message, first obtain its queue ID from the queue listing, then request immediate delivery:
postqueue -p
sudo postqueue -i QUEUE_ID
Replace QUEUE_ID with the exact ID shown by your listing. The -i operation has used the flush(8) service since Postfix 2.4, so it is the focused alternative to a whole-queue flush.
Queue IDs are operational identifiers, not proof that a message belongs to the recipient you expect. Confirm the sender and recipients in the listing or with your normal queue-inspection procedure before retrying. Do not guess an ID and do not paste an ID from a different Postfix instance.
Checkpoint
You have requested one message, one eligible destination, or the whole queue. These are different scopes. If a command affected the wrong scope, stop issuing retries and inspect the current queue and logs.
4. Check the fast-flush defaults
Read the active values rather than assuming the package defaults. These commands are read-only:
postconf fast_flush_domains fast_flush_refresh_time fast_flush_purge_time
postconf queue_directory
postconf -M flush
On this host the reported values are:
| Setting | Value | Meaning |
|---|---|---|
fast_flush_domains | $relay_domains | Destinations that receive per-destination fast-flush records |
fast_flush_refresh_time | 12h | Age after which a non-empty, unread record is refreshed |
fast_flush_purge_time | 7d | Age after which an empty record can be removed |
queue_directory | /var/spool/postfix | Top-level Postfix queue directory |
The final command should show a flush service managed by master. Do not start flush directly. The manpage says it expects to be run by the Postfix master process, and its requests use internal Postfix communication rather than a public network interface.
5. Let Postfix maintain the records
Fast-flush files are truncated after a send request, not necessarily when delivery completes. They can therefore contain old or redundant queue IDs. The service's refresh operation deals with stale records and purges old empty files; Postfix normally invokes that maintenance through the service configuration.
Check the configured wakeup value before changing anything:
postconf -M flush
postconf -h config_directory
If you need to change main.cf or master.cf, save a copy of the file first, edit only the intended setting, validate the configuration, and reload:
sudo cp /etc/postfix/main.cf /etc/postfix/main.cf.before-flush-change
sudo postfix check
sudo postfix reload
The copy is a recovery point for this example. To undo that specific change, restore it only after confirming that no other administrator has made later edits:
sudo cp /etc/postfix/main.cf.before-flush-change /etc/postfix/main.cf
sudo postfix check
sudo postfix reload
Changing fast-flush eligibility changes which destinations get these acceleration records. It does not make a remote server accept mail, and broadening the list can increase queue-management work. Treat it as a configuration change, not as a repair for a stuck message.
Common traps
- Running
flushas a standalone command: this is a Postfix daemon service, not the normal operator interface. Usepostqueue. - Expecting the command to fix delivery: a retry only repeats the delivery path. Check the recorded failure before retrying again.
- Assuming every domain is eligible: the default is
$relay_domains. Confirmfast_flush_domainsbefore usingpostqueue -s. - Editing the spool directory: files under
/var/spool/postfix/flushare internal state. Manual deletion can lose useful scheduling information and is not an undo for a delivery attempt. - Confusing acceptance with completion: an empty queue after a delay is useful evidence, but inspect logs when delivery, bounce, or filtering behaviour matters.
Done means
- You checked the queue and identified the exact retry scope.
- You used
postqueue -f,-s, or-iwith administrator privileges where required. - You verified the queue again and checked logs for failures that remain.
- You confirmed the active fast-flush settings instead of relying on assumed defaults.
- You left the
flushservice undermastercontrol and did not edit its spool files by hand.