Day-to-day Postfix operation is mostly about inspecting and, occasionally, directly manipulating the mail queue.

Viewing the queue¶

postqueue -p

-Queue ID-  --Size--  ----Arrival Time----  -Sender/Recipient-------
05AC71CC67      987   Tue Mar  9 02:47:59   someone@example.com
    (host mx.example.org[203.0.113.5] said: 450 4.7.1 <mx.example.org>:
    Helo command rejected: Host not found (in reply to RCPT TO command))
                                             recipient@example.org
-- 1 Kbytes in 1 Request.

(mailq is the traditional/portable alias for the same thing, if you're used to that from Sendmail.)

Reading a stuck-queue entry like this: the queue ID (05AC71CC67) is the key you need for anything else you want to do with this specific message. The indented line under it is the last delivery attempt's response — here, a 450 4.7.1 temporary failure because the receiving server couldn't resolve/validate the HELO hostname, which is a receiving-side DNS/reverse-DNS issue on their end, not something fixable from your side beyond retrying.

Deleting queued messages¶

A single message, once you have its queue ID from postqueue -p:

postsuper -d 05AC71CC67

postsuper: 05AC71CC67: removed
postsuper: Deleted: 1 message

Everything in the queue (use with real caution — this is unrecoverable and indiscriminate; only reach for it if you're certain the entire queue is junk, e.g. after discovering a misconfiguration caused a flood of bad mail):

postsuper -d ALL

postsuper can also hold a message (-h <queue_id>, preventing delivery attempts without deleting it) and later release it (-r <queue_id>) — useful for pausing a specific problematic message while you investigate, rather than immediately deleting or letting it keep retrying.

Re-processing aliases¶

Any time /etc/aliases is edited, the compiled database needs regenerating:

postalias /etc/aliases

newaliases is the traditional Sendmail-compatible command that does the same thing on most distributions — either works; postalias /etc/aliases is the more explicitly-Postfix-native spelling.

Auto-reply / vacation responder¶

Covered in detail in the virtual domains doc's final section — noted here because it's also an administrative pattern worth remembering exists: a transport_maps entry routes a specific address through a pipe(8) service defined in master.cf, which hands the message to a small script. Good for a lightweight, address-specific automated response without pulling in dedicated mailing-list or ticketing software.

Log locations¶

• RHEL/CentOS/Fedora family: /var/log/maillog
• Debian/Ubuntu family: /var/log/mail.log

The exact path is ultimately whatever your syslog daemon's configuration (/etc/syslog.conf, rsyslog.conf, or systemd-journald's mail facility) says it is — the two paths above are just the near-universal per-distribution-family defaults.

Live-tailing while testing is the standard workflow used throughout this whole guide:

tail -F /var/log/maillog

(-F, not -f — -F keeps following even if the log file gets rotated out from under you, which -f doesn't handle as gracefully.)

See the troubleshooting doc for how to systematically scan these logs for problems rather than just eyeballing a live tail.