Home / Alt manpages / flush(8postfix)

  • flush(8postfix)
  • Postfix admin command
  • linux

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.

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:

SettingValueMeaning
fast_flush_domains$relay_domainsDestinations that receive per-destination fast-flush records
fast_flush_refresh_time12hAge after which a non-empty, unread record is refreshed
fast_flush_purge_time7dAge after which an empty record can be removed
queue_directory/var/spool/postfixTop-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 flush as a standalone command: this is a Postfix daemon service, not the normal operator interface. Use postqueue.
  • 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. Confirm fast_flush_domains before using postqueue -s.
  • Editing the spool directory: files under /var/spool/postfix/flush are 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 -i with 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 flush service under master control and did not edit its spool files by hand.