$ guides / postfix / postfix-how-it-works-in-production ▌

Operations Guides

How Postfix actually works in production: a mental model for operators

Postfix is not a monolith. It is a collection of small, specialized programs that a supervisor process spawns on demand, coordinated by a single-threaded queue manager, with all durable state living as files on disk. Every operational failure in Postfix, from queue gridlock to inode exhaustion to silent DNS degradation, traces back to how these pieces interact.

The specific symptom matters less than the architecture underneath it. The same model that explains why one slow destination stalls all outbound mail also explains why a burst of inbound traffic degrades delivery performance, and why a restart on a large queue looks like recovery before it looks like failure again.

Core abstractions

Postfix is a modular, queue-based MTA. Four abstractions underpin every operational behavior.

The master supervisor. A single resident process (path is distribution-specific: /usr/lib/postfix/sbin/master on Debian/Ubuntu, /usr/libexec/postfix/master on RHEL - check postconf -h daemon_directory) reads master.cf for service definitions, holds the process table, and spawns daemons on demand. It never handles mail directly. It manages subprocess lifecycles: how many smtpd processes can run, how many smtp delivery agents, how many cleanup instances. When a service hits its maxproc limit, new connections queue or fail.

Stateless daemons spawned on demand. Every Postfix daemon (smtpd, smtp, cleanup, local, virtual, pipe, bounce, pickup) is spawned by master when work appears, does its job, and exits. They hold no durable state across invocations. All state, every message, every retry timer, every delivery status, lives as a queue file on disk. This is why a daemon crash rarely loses mail, and why the queue filesystem is the critical resource.

The queue manager (qmgr). This is the brain of mail flow. It is single-threaded. It reads from the incoming queue, schedules messages into the active queue, manages per-destination concurrency, and decides when deferred messages get retried. Because it is single-threaded, it competes for disk I/O with every front-end process simultaneously writing to the incoming queue. The qmgr man page documents this explicitly: a sudden burst of inbound mail can negatively impact outbound delivery rates because one process handles all scheduling.

Disk-backed durability. Every queue file write is fsynced before the operation returns. This is a deliberate durability guarantee, not a tunable behavior. Postfix is fsync-heavy by design, and disk I/O characteristics, especially fsync latency, directly affect throughput. SSDs help significantly. RAM disks are generally not recommended because Postfix already relies on kernel page cache for reads and needs the durability guarantees that fsync provides on real storage.

How it works

Mail enters Postfix through one of two paths. Network mail arrives via smtpd on port 25 (or submission on 587). Local mail arrives via the sendmail command, which deposits messages into the maildrop/ queue directory via postdrop.

From both entry points, mail flows through a fixed pipeline:

flowchart TD
    ENTRY["smtpd / pickup"] --> cleanup["cleanup: sanitize + rewrite"]
    cleanup -->|fsync write| INCOMING["incoming/"]
    INCOMING --> QMGR["qmgr (single-threaded, fair queueing)"]
    QMGR --> ACTIVE["active/ (limit 20,000)"]
    ACTIVE --> AGENTS["delivery agents: smtp, local, virtual, pipe"]
    AGENTS -->|4xx temp fail| DEFERRED["deferred/"]
    AGENTS -->|success| DONE["delivered"]
    DEFERRED -->|retry after backoff| QMGR

cleanup sanitizes every message. The cleanup daemon runs once per message. It adds missing headers (Date, Message-Id), rewrites addresses according to canonical and virtual mappings, applies header_checks and body_checks, and writes the result as a single file into the incoming/ queue. On large messages or complex regex patterns in header_checks, cleanup can become CPU-bound.

qmgr controls the active queue. The queue manager reads from incoming/, selects messages eligible for delivery, and moves them into active/. The active queue is capped at qmgr_message_active_limit, which defaults to 20,000 messages. When the active queue is full, no new messages can enter delivery, regardless of how healthy the destinations are.

Within the active queue, qmgr implements fair queueing by destination, not priority queueing. There are no explicit priority classes. Instead, qmgr uses several scheduling mechanisms working together:

Round-robin by destination. qmgr cycles through destinations so that no single domain monopolizes delivery slots. This is the core fairness mechanism.
Per-destination concurrency with slow start. Each destination gets its own concurrency limit. qmgr uses slow start: initial_destination_concurrency defaults to 5, and concurrency grows with positive feedback from successful deliveries, up to default_destination_concurrency_limit (default 20).
Exponential backoff for deferred mail. Messages that fail with a 4xx temporary error go to deferred/. The retry schedule uses exponential backoff between minimal_backoff_time (default 300s) and maximal_backoff_time (default 4000s). A deferred message may not be retried for over an hour, and old deferred messages create long-tail delivery latency.
Preemptive scheduling. Within the active queue, the scheduler uses slot accounting to prevent large messages from blocking small ones indefinitely. This is not the same as priority classes, but it does mean the scheduler reorders work under certain conditions rather than strictly FIFO.
Fairness between incoming and deferred. When the active queue has room, qmgr alternates: one message from incoming, one from deferred. This prevents deferred mail from being starved indefinitely, but it also means a large deferred queue can slow down new mail entering delivery.

In-memory state that does not survive restart. While queue files are on disk, qmgr also maintains significant in-memory state: the active queue recipient pool (up to qmgr_message_recipient_limit, default 20,000), the dead destination cache, and concurrency feedback counters. When qmgr restarts, this state is lost. The queue scan that repopulates it can take minutes on large queues, and during that window, delivery appears to stall.

Delivery agents do the actual work. smtp (outbound), local (system mailboxes), virtual (virtual mailbox domains), and pipe (external programs like Amavis or Mailman) are spawned by master on demand. They execute their delivery, report success or failure back to qmgr, and exit. They are stateless.

Where it shows up in production

The mental model maps directly to operational concerns across deployment variants.

Null client. Forwards everything to a relayhost. No local delivery, minimal queue concerns. The main risk is relayhost reachability and SASL/TLS to the relay. If the relayhost is down, the entire deferred queue accumulates with no alternative path.

Internet site (full SMTP service). Direct delivery to internet MX hosts. Heavy queue monitoring is essential because every destination on the internet is a potential source of 4xx deferrals, rate limiting, or greylisting. DNS health is critical because every delivery requires MX resolution.

Inbound gateway. Receives mail for internal systems (Exchange, Google Workspace, internal LMTP servers). Queue buildup patterns differ: the bottleneck is often the downstream internal server, not the internet. Relay recipient maps must be current, or mail is accepted then bounced, producing backscatter.

Outbound relay with content filter. Content filters (Amavis, Rspamd, commercial appliances) become critical dependencies. When a filter slows down, delivery agents to the filter hold active queue slots longer than normal. The active queue saturates with messages destined for the filter address, and the incoming queue grows behind it. The deferred queue may stay small because the filter is slow, not rejecting. This pattern is frequently missed because teams monitor the filter’s process health, not its response latency.

Backup MX. Queue growth without delivery is expected by design. The primary is down, mail queues. Different alerting logic is needed: a large deferred queue on a backup MX during a primary outage is normal, not an incident.

Multi-instance. Multiple Postfix instances on one host share hardware resources. One instance can starve another for disk I/O, file descriptors, or process slots. Per-instance resource accounting is essential. Aggregate metrics hide contention.

Tradeoffs and common misuses

Single-threaded qmgr as I/O bottleneck. The qmgr man page documents this in its BUGS section: a single queue manager process competes for disk access with multiple front-end processes like cleanup. Under heavy inbound load, qmgr’s ability to schedule outbound delivery degrades because it is fighting for the same disk I/O that cleanup is using to write incoming messages. This is architectural, not a bug.

Fair queueing without priority classes. Postfix’s fair queueing means one slow destination can consume active queue slots that would otherwise serve healthy destinations. There is no built-in mechanism to say “deliver transactional mail before bulk mail.” If you mix traffic classes on one Postfix instance, a slow destination consuming bulk mail slots will delay transactional mail. Operators who need traffic separation typically run multiple instances or use transport_maps to split flows.

Active queue saturation as head-of-line blocking. When the active queue reaches qmgr_message_active_limit (default 20,000), no new messages can enter delivery. The queue manager is working as designed, but the design creates head-of-line blocking: all destinations are effectively stalled because one or few slow destinations have consumed the available slots. The fix is not to raise the limit but to address the slow destination.

In-memory state loss on restart. Because qmgr maintains in-memory scheduling state that does not survive restart, any restart (planned or crash) triggers a full queue scan. On large queues, this scan takes minutes. During the scan, delivery appears to stop. This is often misdiagnosed as a hang or a new problem, when it is simply the queue manager rebuilding its in-memory state from on-disk queue files.

Exponential backoff creating long recovery tails. When a destination recovers after being down, messages in deferred/ do not immediately retry. They wait until their next scheduled retry, which may be up to maximal_backoff_time (default 4000s) away. A deferred queue that took hours to build can take hours to drain even after the root cause is fixed. Operators sometimes manually re-queue messages with postsuper -r after confirming the destination is healthy. Warning: re-queuing a large number of messages at once can cause a burst of delivery attempts that overwhelms qmgr and the destination. Re-queue selectively, and consider re-queuing in batches by domain or queue ID range rather than postsuper -r ALL.

DNS as an invisible single point of failure. Postfix is DNS-heavy. Every outbound delivery requires MX or A record resolution. DNSBL queries add to this load. When DNS is slow rather than failed, every delivery attempt incurs extra latency. When DNS fails entirely, all deliveries defer with “Host not found” but the queue manager appears healthy because it is successfully scheduling retries. Teams that monitor Postfix but not the resolver can spend significant time looking at the wrong system.

Signals to watch in production

Signal	Why it matters	Warning sign
Active queue size vs `qmgr_message_active_limit`	When full, no new mail enters delivery regardless of destination health	Sustained above 80% of limit
Deferred queue growth rate	Velocity, not absolute size, is the earliest indicator of delivery failure	Sustained positive growth over 4+ hours
Injection rate vs delivery rate	Divergence means the queue is growing	Delivery rate below 90% of injection over 5-minute windows
Queue filesystem inode usage	Postfix creates one file per queued message; inode exhaustion kills the queue with “No space left on device” even when disk space remains	Below 20% free inodes
`postqueue -p` response time	Slow response indicates qmgr is under pressure or scanning a large queue	Consistently above 5 seconds
Deferred queue age (oldest file)	Old messages indicate chronic delivery problems, not transient blips	Oldest file older than 1 hour during normal operations
DNS resolver latency	Postfix is DNS-heavy; slow DNS affects every delivery	Lookups above 500ms sustained
Content filter response time	Slow filters cause incoming queue backpressure before process failure	p99 above 5 seconds

Thresholds above are starting points for alerting, not universal rules. Calibrate them against your baseline traffic patterns.

How Netdata helps

Netdata surfaces the signals that make the Postfix mental model actionable:

Queue depth metrics (active, deferred, incoming, maildrop, hold, corrupt) at high collection frequency let you see queue gridlock forming, not after a threshold trips.
Correlating active queue saturation with deferred queue growth and per-destination deferral rates distinguishes “one bad destination” from “systemic delivery failure.”
Disk I/O metrics, including fsync latency, explain why the single-threaded qmgr is struggling under inbound bursts.
DNS query latency and failure rate, collected at the resolver level, catch the invisible DNS degradation that looks like “slow mail” in Postfix logs.
Filesystem inode usage alongside disk space usage prevents the classic “No space left on device with 50% disk free” confusion.
Process-level metrics for qmgr, smtpd, cleanup, and delivery agents show which daemon is consuming resources and whether any service is hitting its maxproc limit.