Fix a Zimbra Mail Queue Backlog: Safely Flush Postfix and Verify Delivery

A Zimbra mail queue flush asks Postfix to retry queued messages. It does not erase the queue, repair a DNS or network problem, or guarantee that remote servers will accept every message. A useful outcome is measurable: the queue is no longer growing, deferred messages are decreasing or changing to successful deliveries, and new mail can move through the MTA.

Use the steps below on the Zimbra server as an administrator. Commands and paths can differ between Zimbra releases. Check the executable paths on your host before running them; do not accidentally use the operating system’s separate Postfix installation.

1. Check how large the backlog is

Connect to the server and switch to the Zimbra account using your site’s approved administrative method. The queue summary utility is commonly installed at /opt/zimbra/libexec/zmqstat. Zimbra’s queue documentation shows it reporting counts for held, corrupt, deferred, active, and incoming messages.

sudo /opt/zimbra/libexec/zmqstat

Depending on sudo configuration, run the command from the Zimbra account or use the exact privilege method configured for your server. A sample summary might show deferred=240 and active=3. These are counts, not proof that 240 messages are permanently stuck. Compare them again after a few minutes and note which category changes.

Next, inspect individual queue entries. Many current installations use the common/sbin path; older installations may use postfix/sbin. Use the path that actually exists on your server.

/opt/zimbra/common/sbin/postqueue -p

If that path is absent, check whether your installation has /opt/zimbra/postfix/sbin/postqueue, then substitute that full path in the commands below. Zimbra’s documentation describes both the queue summary and the detailed postqueue -p listing. Queue IDs may have a trailing asterisk for active delivery attempts or an exclamation mark for a held message. See Zimbra’s Postfix queue reference.

2. Find the reason messages are waiting

Look at the age of the oldest messages and the delivery status recorded in the Zimbra log. A deferred message is waiting for another delivery attempt; it may be delayed by a remote server, a DNS lookup, a network timeout, TLS negotiation, or a local routing or relay configuration problem. The exact status text is more useful than the queue count by itself.

grep -E 'status=(deferred|sent|bounced)|connect to|TLS|SASL|relay=' /var/log/zimbra.log | tail -n 50

Interpret those lines in context. Repeated connection timeouts to one destination suggest a connectivity or remote-server issue. Name-resolution errors point toward DNS. A remote temporary rejection or rate limit may require waiting or contacting the recipient provider. Authentication or TLS errors may indicate a local configuration problem. A status=sent entry means the next delivery hop accepted the message; it does not establish that the recipient read it or that it reached the inbox.

If the queue is expanding quickly, look for a high-volume sender or compromised account before repeatedly retrying. Zimbra’s anti-spam troubleshooting guidance recommends correlating queue contents with sender and authentication activity, then containing the source before clearing unwanted mail. Review Zimbra’s queue and spam investigation steps.

3. Fix the cause before asking Postfix to retry

Use the log evidence to decide whether the issue is transient or local. Verify that the server has working name resolution and outbound network access to the affected mail destinations. If the log points to a remote throttling response, avoid firing repeated flushes at that provider; retries cannot override its policy. If several domains fail with the same local error, inspect the relevant Zimbra MTA configuration and service health before changing settings.

Messages marked held need special attention: a normal flush is not a command to release held mail. Review why they were held and whether they are legitimate before releasing any. Messages marked corrupt or bounced also need separate handling; retrying does not turn a permanent rejection into a successful delivery. Preserve queue IDs and relevant log entries while investigating.

Zimbra’s troubleshooting material identifies /var/log/zimbra.log as a primary place to investigate MTA problems, and lists queue utilities such as postqueue and zmqstat. Exact service layout and executable locations are version-dependent, so check your installed release’s documentation before restarting services or editing configuration. See Zimbra’s MTA troubleshooting tools.

4. Flush the Postfix queue

When you have confirmed that the queued mail is legitimate and corrected or understood the blocking condition, request a queue run. Substitute the path that exists on your server:

/opt/zimbra/common/sbin/postqueue -f

For an installation using the older path, use /opt/zimbra/postfix/sbin/postqueue -f instead. The Zimbra queue reference documents postqueue -f as the flush command. The request prompts Postfix to try queued mail; it is not a delete operation. It may return without a dramatic success message, so judge the result from later queue counts and delivery logs rather than from the command’s brief output.

A flush is reasonable after a short network interruption or after a temporary configuration issue has been corrected. It is unlikely to help while DNS, routing, relay, TLS, or a remote receiving server remains unavailable. Repeating the command rapidly can create noise and additional retry traffic without addressing the fault.

5. Verify the result and choose the next step

After allowing a short interval for delivery attempts, repeat the queue summary and inspect recent log entries:

sudo /opt/zimbra/libexec/zmqstat
tail -n 100 /var/log/zimbra.log

Look for several signs together: deferred counts trending down, older queue entries disappearing, new status=sent records for the affected destinations, and fewer newly deferred messages. A queue may remain nonempty during normal operation. A single successful delivery does not show that every recipient domain is healthy.

• If the count falls and delivery logs show acceptance: keep monitoring until the backlog returns to its normal level.
• If the same messages defer again: follow the repeated error text and repair the underlying DNS, network, TLS, relay, or recipient-side issue.
• If the count keeps rising: investigate a sending loop, bulk mail, or compromised account and contain new unwanted mail before retrying.
• If held or corrupt counts remain: review those messages separately; a general flush is not a cleanup action for those categories.

Do not delete all messages simply to make the queue display empty. If a specific message is confirmed to be unwanted or undeliverable and policy allows removal, preserve its queue ID and review it before using the matching queue-management procedure. Zimbra explicitly warns that deletion can affect users and recommends recording queue details before removing messages. Avoid deleting files directly from the Postfix spool directories; that bypasses queue management and can damage mail state.

What a successful flush can and cannot tell you

A successful recovery is a sustained improvement in message flow, not merely a zero count at one instant. Postfix may continue to queue mail for remote destinations that are unavailable or temporarily rejecting connections. The flush command initiates retries; it cannot guarantee delivery, release intentionally held messages, correct malformed configuration, or determine whether a recipient’s system accepted a message beyond the SMTP handoff.

As of October 6, 2026, the cited Zimbra Tech Center pages document the queue and troubleshooting commands used here, but they do not provide a single current path guaranteed across every Zimbra release. Confirm binary locations and privilege behavior on your own server before executing commands, especially on older or customized deployments.