Postfix is the most widely deployed open-source MTA in the world — default on macOS, NetBSD, RHEL/CentOS, and Ubuntu, tied with Exim at ~2.57M Shodan-detected instances as of February 2025. Created by Wietse Venema at IBM Thomas J. Watson Research Center in 1997 and first released in December 1998 as a security-focused Sendmail replacement. Its modular architecture splits responsibilities across a resident master(8) daemon and ~50 specialized child daemons running with reduced privileges, providing security through process isolation. Configuration is split between main.cf (parameters) and master.cf (daemon definitions). Realistic throughput on tuned hardware is hundreds of deliveries per second — sufficient for most enterprise, SaaS, and small-to-medium ESP workloads but below dedicated commercial MTAs (PowerMTA, KumoMTA) for ESP-scale operations.
Postfix closes the high-volume MTA cluster. With PowerMTA as the commercial industrial standard and KumoMTA as the open-source PowerMTA-class alternative, Postfix is the choice for the 90%+ of email infrastructure deployments that don't need ESP-grade per-domain throttling and aren't willing to pay $5,500-8,000+/year for PowerMTA's license. It's the right answer for the complete mail server with Dovecot, the application relay sending transactional mail, the gateway/filtering deployment in front of internal Exchange, and the small-to-medium ESP under 1-2M messages/day.
This entry covers Postfix specifically — its modular architecture, the 4-queue lifecycle that makes high-volume operation possible, the configuration philosophy that splits main.cf from master.cf, the real-world throughput characteristics, the high-volume tuning patterns from official TUNING_README, and the operational decision framework for choosing Postfix vs PowerMTA vs KumoMTA. The umbrella view covering all 7 major MTAs (Postfix + Exim + Sendmail + PowerMTA + KumoMTA + MailerQ + Halon) is in the MTA umbrella entry.
Origin: a security-focused Sendmail replacement
Postfix's origin story explains why its architecture looks the way it does. Wietse Venema is a Dutch security researcher who, while working at IBM Thomas J. Watson Research Center in the late 1990s, set out to build a Mail Transfer Agent that could replace Sendmail without inheriting Sendmail's structural security problems. The project was originally called VMailer, then renamed IBM Secure Mailer for IBM's brief commercial release, and finally Postfix when released to the public in December 1998 under what became the IBM Public License 1.0.
The naming logic per Wikipedia: "Postfix is a compound of 'post' (which is another word for mail) and 'bugfix' (which is for other software that inspired Postfix development)." The "other software" was Sendmail — Postfix was explicitly designed as a fix for Sendmail's monolithic architecture, configuration complexity, and security history.
The architectural insight Venema brought from his security research: process isolation contains compromise. A monolithic MTA like Sendmail runs everything in one process — if an attacker exploits the SMTP server, they immediately have access to the queue manager, the local delivery agent, and root privileges. Postfix's modular design means a compromise of the public-facing smtpd daemon doesn't escalate to controlling the queue or local delivery — those run as separate processes with reduced privileges and well-defined IPC boundaries.
The master/child daemon architecture
Postfix's runtime model: a resident master(8) daemon supervises ~50 specialized child daemons that handle specific aspects of email delivery. The master is started at boot via postfix start and runs until shutdown — it spawns child daemons on demand based on master.cf configuration, enforces process count limits, and restarts daemons that terminate prematurely. Most child daemons are short-lived: they handle a configurable number of requests (max_use, default 100) or run for a configurable idle timeout (max_idle, default 100s), then voluntarily terminate.
The daemons that operators encounter most frequently:
master(8)
The orchestrator. Started at boot, runs until shutdown. Spawns child daemons on demand. Enforces master.cf process limits. Restarts daemons that crash. The single resident process every Postfix deployment has.
qmgr(8)
The traffic controller. Manages active queue, schedules deliveries, implements TCP-slow-start-analog concurrency adaptation. One of the few daemons that stays resident (always running). Limit is fixed at 1.
smtpd(8)
Accepts incoming SMTP connections on ports 25, 465, 587. Applies smtpd_*_restrictions for relay control, anti-spam, RBL/DNSBL checks. Public-facing daemon, runs with reduced privileges (postfix user).
smtp(8)
Delivers messages to remote SMTP servers. Handles MX lookups, STARTTLS, connection caching, fallback relay. Multiple instances run concurrently up to default_destination_concurrency_limit per destination.
local(8)
Delivers to local Unix mailboxes (/var/spool/mail/user). Handles aliases, .forward files, |pipe commands. Often replaced by Dovecot LMTP delivery in production deployments.
lmtp(8)
Delivers via LMTP (Local Mail Transfer Protocol) — typically to Dovecot for IMAP/POP3 mailbox handling. Modern Postfix+Dovecot deployments use LMTP instead of local(8).
cleanup(8)
Performs header rewriting, content filtering hooks, queue ID assignment, header_checks/body_checks. The path messages take from incoming queue to active queue. milter integration happens here.
pickup(8)
Picks up messages from /var/spool/postfix/maildrop (where local sendmail(1) command writes them) and feeds them to cleanup(8). Bridges command-line submission into the SMTP queue lifecycle.
tlsmgr(8)
Manages TLS session cache and pseudo-random number pool. Resident daemon shared across all SMTP-speaking processes. Dramatically reduces TLS handshake overhead at scale.
The full architecture includes ~50 daemons total — these are the ~9 most operationally significant. Per Linux Journal's Anatomy of Postfix: "You can think of the whole Postfix system as a router." Messages arrive (via smtpd or pickup), get processed (cleanup), wait in queues, and get delivered (smtp/local/lmtp). The master daemon is the routing supervisor; everything else is a specialized worker.
The 4-queue lifecycle
Postfix's queue management is the engineering achievement that makes high-volume operation possible. Messages move through four physical directories under /var/spool/postfix/, each representing a distinct lifecycle stage. Understanding these queues is essential for operational debugging — if mail is delayed, the queue distribution tells you why.
Postfix queue lifecycle: maildrop → incoming → active → deferred
sendmail(1) command are written here by anyone (mode 1733). The pickup(8) daemon — running as the postfix user — reads them periodically and feeds them to cleanup(8). Web-app /usr/sbin/sendmail integrations use this path.smtpd(8) (network) or pickup(8) (local) wait here briefly. cleanup(8) performs header rewriting, milter content-filter hooks, header_checks/body_checks, and assigns the queue ID. Once cleanup completes, the message moves to active.qmgr(8) and dispatched to delivery agents (smtp, local, lmtp, pipe). Intentionally kept small — default qmgr_message_active_limit=20000. The qmgr pulls from incoming/deferred as active slots free up. If active is large, delivery agents are blocked or destinations are slow.qmgr scans deferred every queue_run_delay seconds (default 300s) and uses exponential backoff between minimal_backoff_time (300s) and maximal_backoff_time (4000s). Messages stay until maximal_queue_lifetime expires (default 5 days), then bounce back to sender.qshape tool inspects all four queues and shows message distribution per destination domain plus age buckets. qshape active shows what's currently delivering; qshape deferred shows what's retrying. If qshape deferred shows one domain dominating with old-age messages, you have a destination-specific problem (often DNS, RBL listing, or rate limiting). If qshape active grows large, your delivery concurrency is too low for current arrival rate. The QSHAPE_README from postfix.org is essential reading for production operators.
main.cf vs master.cf: the configuration split
Postfix configuration lives in /etc/postfix/ across two complementary files. Operators frequently confuse them — understanding the split makes high-volume tuning straightforward.
| File | Purpose | Format | Reload required? |
|---|---|---|---|
main.cf |
Site-specific Postfix parameters — over 700 directives controlling almost every behavior. Default values come from postconf -d; site-specific overrides go here. |
parameter = value key=value pairs |
postfix reload applies changes for most parameters |
master.cf |
Daemon process configuration — which daemons run, command-line arguments, process limits, listening ports. Per-service parameter overrides via -o syntax. |
Tabular: service / type / private / unprivileged / chroot / wakeup / maxproc / command + args | postfix reload after changes |
A representative main.cf snippet:
# /etc/postfix/main.cf — site-specific parameters myhostname = mail.example.com mydomain = example.com myorigin = $mydomain mydestination = $myhostname localhost.$mydomain localhost mynetworks = 127.0.0.0/8 192.0.2.0/24 # trusted networks (no auth) relay_domains = $mydomain # High-volume tuning default_process_limit = 200 # default 100 — bump for volume default_destination_concurrency_limit = 20 # max parallel to one destination smtp_destination_concurrency_limit = 50 # override for outbound qmgr_message_active_limit = 20000 # active queue ceiling smtp_connect_timeout = 5s # default 30s — too high smtp_helo_timeout = 5s # Queue retry behavior queue_run_delay = 300s minimal_backoff_time = 300s maximal_backoff_time = 4000s maximal_queue_lifetime = 2d # default 5d — shorter for relays # Anti-spam smtpd_*_restrictions smtpd_relay_restrictions = permit_mynetworks reject_unauth_destination smtpd_recipient_restrictions = permit_mynetworks reject_unauth_destination smtpd_client_restrictions = permit_mynetworks reject_rbl_client zen.spamhaus.org # TLS configuration smtpd_tls_security_level = may # opportunistic STARTTLS inbound smtp_tls_security_level = may # opportunistic STARTTLS outbound smtpd_tls_cert_file = /etc/letsencrypt/live/mail.example.com/fullchain.pem smtpd_tls_key_file = /etc/letsencrypt/live/mail.example.com/privkey.pem
And master.cf showing the -o override pattern:
# /etc/postfix/master.cf — daemon definitions with per-service overrides # service / type / private / unprivileged / chroot / wakeup / maxproc / command smtp inet n - y - - smtpd submission inet n - y - - smtpd -o syslog_name=postfix/submission -o smtpd_tls_security_level=encrypt # mandatory TLS on 587 -o smtpd_sasl_auth_enable=yes # SMTP AUTH required -o smtpd_relay_restrictions=permit_sasl_authenticated,reject smtps inet n - y - - smtpd -o syslog_name=postfix/smtps -o smtpd_tls_wrappermode=yes # implicit TLS on 465 -o smtpd_sasl_auth_enable=yes # Dedicated relay transport with custom timeouts relay unix - - y - - smtp -o syslog_name=postfix/relay -o smtp_connect_timeout=2s # aggressive for known-good relay -o smtp_destination_concurrency_limit=100 # higher for trusted destination # Resident services (process limit must remain low/fixed) qmgr unix n - n 300 1 qmgr pickup unix n - n 60 1 pickup cleanup unix n - n - 0 cleanup tlsmgr unix - - n 1000? 1 tlsmgr
default_process_limit at 100 while running high-volume — caps total concurrency artificially; (3) not adjusting smtp_connect_timeout from 30s default — wastes workers on dead MX hosts; (4) running without a local DNS resolver — every delivery does a round-trip to 8.8.8.8 or your provider's resolver, killing throughput at scale. The fixes are in TUNING_README.
Realistic throughput numbers
Postfix's throughput characteristics are misunderstood at both extremes. Operators new to Postfix sometimes assume it can match PowerMTA's millions-per-hour numbers; operators coming from PowerMTA sometimes assume Postfix is hopelessly slow. Both views are wrong. The realistic picture from official documentation and production deployments:
The throughput ceiling is rarely about Postfix's protocol implementation — it's about the operational complexity of managing per-domain throttling, IP pool isolation, and FBL integration that becomes painful at scale. Postfix CAN handle 5M/day with sufficient tuning, but the per-domain throttling profiles required, the FBL processing infrastructure built outside Postfix, and the ISP-specific bounce categorization that's a manual exercise — these are exactly what PowerMTA and KumoMTA were designed to bake in. At ESP scale, Postfix becomes a tool that works rather than the tool that's designed for the job.
Common deployment patterns
Postfix operates in four distinct architectural roles. Most production deployments use exactly one of these patterns; understanding which fits your use case is the first decision before tuning anything.
Complete mail server
Postfix handles SMTP send/receive; Dovecot handles IMAP/POP3 mailbox access. LMTP for local delivery to mailboxes. Self-hosted email for enterprises, universities, and privacy-focused individuals.
Application relay
Postfix accepts SMTP submission from internal applications (web apps, SaaS platforms, monitoring systems) and relays to recipient ISPs or a third-party SMTP service. No local mailboxes. Common transactional email pattern.
Gateway / filtering
Postfix in front of internal mail server (Exchange, Zimbra, Proofpoint) — applies anti-spam policies, DNSBL checks, milter integration before relaying clean mail to the internal MTA. Adds Postfix's flexibility to inflexible internal deployments.
Split-MTA architecture
Postfix handles inbound submission with policy enforcement; PowerMTA or KumoMTA handles outbound delivery with per-domain throttling. Each MTA does what it's best at. Standard ESP architecture.
High-volume tuning: the parameters that matter
The official guides are postfix.org's TUNING_README and QSHAPE_README. The parameters that move the needle for high-volume deployments:
| Parameter | Default | High-volume value | Effect | Where |
|---|---|---|---|---|
default_process_limit | 100 | 500-1000 | Maximum concurrent processes per service. Cap on smtp/smtpd workers. | main.cf |
smtp_destination_concurrency_limit | 20 | 50-100 | Max parallel SMTP connections to one destination domain. | main.cf |
smtp_connect_timeout | 30s | 5s (or 1-2s for known-fast) | How long to wait for TCP connect. 30s default kills throughput on dead MX. | master.cf -o |
smtp_helo_timeout | 300s | 5-15s | How long to wait for EHLO/HELO response. High default punishes slow servers. | master.cf -o |
qmgr_message_active_limit | 20000 | 50000-100000 | Active queue ceiling. Larger = more parallelism but more memory. | main.cf |
queue_run_delay | 300s | 300s (rarely lower) | How often qmgr scans deferred. Lower = faster retry but more overhead. | main.cf |
maximal_queue_lifetime | 5d | 1-2d for relays | How long messages stay in deferred before bouncing. Shorter for relays. | main.cf |
default_destination_recipient_limit | 50 | 100-500 | Max recipients per delivery agent connection. Higher = better throughput. | main.cf |
smtp_connection_cache_on_demand | yes | yes (Postfix 2.2+) | Reuse SMTP connections for active-queue backlogs. Critical for scale. | main.cf |
| Local DNS resolver | — | Unbound or Bind on localhost | Per-message DNS lookups. 100ms × millions = throughput killer. | /etc/resolv.conf |
The most impactful tuning is rarely a single parameter — it's the combination of process limit, destination concurrency, connect timeout, and a local DNS resolver. Per the official TUNING_README:
"For high volume sites a key tuning parameter is the number of 'smtp' delivery agents allocated to the 'smtp' and 'relay' transports. High volume sites tend to send to many different destinations, many of which may be down or slow, so a good fraction of the available delivery agents will be blocked waiting for slow sites."
Postfix vs PowerMTA vs KumoMTA: when to pick which
The MTA decision matrix is in the MTA umbrella entry. The Postfix-specific framing:
Postfix in Cloud Server for Email infrastructure
Our managed email infrastructure uses Postfix in specific operational roles where it excels:
- Inbound submission infrastructure for client applications submitting transactional and marketing mail to our PowerMTA outbound layer. Postfix on 587/465 with SMTP AUTH, milter integration for anti-spam, smtpd_recipient_restrictions for relay control. This is the split-MTA pattern at scale.
- Mailcow-dockerized deployments for clients who want self-hosted complete mail servers (MX + IMAP/POP3 via Dovecot LMTP). Containerized Postfix + Dovecot + Rspamd + admin UI as a unified stack.
- Gateway/filtering deployments for clients with internal Exchange or Zimbra installations needing additional anti-spam layer in front. Postfix applies Spamhaus ZEN queries, SPF/DKIM/DMARC validation, and milter-based content filtering before relaying clean mail to the internal MTA.
- Bounce and FBL processing infrastructure behind PowerMTA's outbound delivery — Postfix accepts bounces and Feedback Loop reports, applies content parsing rules, and feeds structured data into customer reporting systems. Postfix's milter ecosystem and address_verify_relayhost flexibility shine for this role.
- High-volume tuning consultation for clients running their own Postfix infrastructure approaching the 500K-1M msgs/day threshold. We work through TUNING_README parameters, deploy local DNS resolvers, and help diagnose qshape patterns. When the operational tax exceeds the license cost of KumoMTA or PowerMTA, we advise migration; when Postfix can be tuned to handle the volume cleanly, we keep it.
For clients deciding among Postfix, PowerMTA, and KumoMTA, our recommendation framework runs through volume bands, team expertise, integration requirements, and operational pattern preferences. Postfix is the rational default below 1M/day for almost every use case; the exceptions are specific (cloud-native ESP, multi-tenant Lua policy, ESP-grade vendor support).
Related glossary concepts
- MTA — the umbrella concept comparing all 7 major implementations including Postfix.
- PowerMTA — the commercial MTA Postfix is sometimes paired with in split-MTA deployments.
- KumoMTA — the open-source PowerMTA-class alternative that competes with Postfix at the 500K-5M/day band.
- SMTP — the protocol Postfix implements for both submission (587/465) and relay (25).
- SPF, DKIM, DMARC — authentication standards Postfix supports via opendkim/opendmarc milters.
- MTA-STS — TLS policy that Postfix can fetch and enforce via smtp_tls_security_level + smtp_tls_policy_maps.
- DANE — DNS-based TLS validation Postfix supports via smtp_dns_support_level=dnssec + smtp_tls_security_level=dane.
- Spamhaus — DNSBL queries Postfix runs at SMTP connection time via smtpd_client_restrictions: reject_rbl_client zen.spamhaus.org.
- Sender Reputation — Postfix's per-IP reputation maintained through proper authentication, throttling, and bounce handling.
Frequently asked questions
Is Postfix really the most-deployed MTA?
Tied with Exim, technically. Per Wikipedia citing Shodan February 2025 internet scans: Postfix detected 2.57 million times, Exim detected 2.56 million times — essentially tied. A separate February 2025 study by E-Soft put Exim ahead in their 10× smaller sample (0.31M Exim vs 0.21M Postfix). Both are within margin of error of each other; both are far ahead of Sendmail (~4% of public email servers in 2025), commercial MTAs (PowerMTA + MailerQ + Halon combined are well below 1M instances by count), and KumoMTA (founded 2023, smaller deployed base by definition). The Postfix-vs-Exim split tends to follow OS distributions: Debian and cPanel hosting drives Exim's number; macOS/NetBSD/RHEL/CentOS/Ubuntu drive Postfix's. For practical purposes, Postfix is the most-deployed MTA in environments operators typically encounter.
What's the maximum volume Postfix can realistically handle?
With proper tuning and dedicated hardware: hundreds of deliveries per second sustained, roughly 50,000-100,000 messages per hour per server. The ceiling is rarely about Postfix's protocol implementation — it's the operational complexity of managing per-domain throttling, IP pool isolation, and FBL integration at scale. Postfix CAN be tuned to handle 5M+/day on dedicated hardware with serious operational investment, but at that volume, PowerMTA's per-VirtualMTA model or KumoMTA's per-tenant Lua policy starts being structurally simpler than tuning Postfix to do the same. The pragmatic threshold: below 1M/day Postfix is the right default; 1-5M/day is workable Postfix territory with growing operational tax; above 5M/day commercial or PowerMTA-class open-source MTAs typically take over.
Can Postfix replace Microsoft Exchange?
For SMTP send/receive only, yes — Postfix handles email transport perfectly well. For the full Exchange feature set (calendars, contacts, MAPI clients, Outlook integration), no — Postfix is specifically an MTA, not a groupware platform. The combination Postfix + Dovecot + (optional) SOGo or Z-Push covers SMTP + IMAP/POP3 + basic CalDAV/CardDAV for users running standard email clients (Thunderbird, Apple Mail, mobile native clients). For users dependent on Outlook + MAPI + native Microsoft 365 features, Postfix is not a drop-in replacement — that's a different product category. Many enterprises run Postfix as the SMTP gateway in front of Exchange (the gateway/filtering pattern in this entry) rather than replacing Exchange entirely.
Why does Postfix run so many separate processes?
Security through process isolation. Wietse Venema's design treats each daemon as a security perimeter — a vulnerability in the public-facing smtpd daemon doesn't escalate to controlling the queue manager, the local delivery agent, or root privileges. This is structurally different from Sendmail or Exim's monolithic designs where a vulnerability in any subsystem can compromise the entire mail system. The performance overhead is minimal in practice — most child daemons are short-lived (terminate after max_use=100 requests or max_idle=100s timeout), and the few resident daemons (master, qmgr, tlsmgr) are lightweight. The architectural cost is small; the security benefit is substantial. Postfix's 28-year track record of containment is the empirical proof that the modular design works.
What's qshape and why is it essential?
qshape is Postfix's queue inspection tool — included in standard distributions. It shows message distribution per destination domain across age buckets, for any of the four queues. qshape active shows what's currently delivering (if growing, your concurrency is too low for arrival rate); qshape deferred shows what's retrying (if one domain dominates with old-age messages, you have a destination-specific problem); qshape incoming shows the cleanup pipeline (rarely interesting unless backed up). The QSHAPE_README from postfix.org is essential operator reading — it teaches diagnostic patterns that map queue distributions to root causes (DNS issues, RBL listings, recipient rate limiting, congested destinations). Production Postfix deployments without qshape monitoring are flying blind during incidents.
Does Postfix support DANE, MTA-STS, and TLS-RPT?
Yes, all three. DANE is supported via smtp_dns_support_level=dnssec + smtp_tls_security_level=dane (or dane-only). MTA-STS is supported via smtp_tls_policy_maps lookup and external policy fetch tools (postfix-mta-sts-resolver is the standard helper). TLS-RPT reporting requires external aggregation (Postfix logs TLS handshake outcomes; tools like postfix-tlsrpt-reporter generate the daily aggregate reports). The TLS hardening features production senders need are first-class supported, though the configuration is more verbose than KumoMTA's single-line declarative config or PowerMTA's per-VirtualMTA settings. Detailed configuration walkthroughs are in the postfix.org TLS_README.
Is Postfix appropriate for marketing email?
Below 1M messages/day, yes — Postfix handles small-to-medium ESP volume comfortably with proper authentication (SPF, DKIM, DMARC), per-destination throttling, and IP warmup. Most newsletter platforms with subscriber counts under 1M run Postfix backends. Above 1M/day, the per-domain throttling complexity grows uncomfortable — you'll be writing transport_maps for Gmail, Microsoft, Yahoo each with different concurrency and rate-delay parameters, managing IP pools through complex master.cf service definitions, and building FBL processing infrastructure outside Postfix. At that point, PowerMTA's per-VirtualMTA model or KumoMTA's per-tenant Lua policy is structurally simpler. The decision isn't "can Postfix do this" — it can — but "is the operational tax worth avoiding the migration cost." For sustained marketing volume above 5M/day, almost always migrate.
What about mailcow-dockerized?
Mailcow-dockerized is the industry-standard containerized Postfix deployment. It bundles Postfix + Dovecot + Nginx + PHP + MariaDB + Rspamd into a cohesive Docker Compose stack with admin UI. For operators who want a complete self-hosted mail server without manual configuration of each component, mailcow is the rational default in 2026. It handles the Postfix + Dovecot LMTP integration, the Rspamd anti-spam configuration, the Let's Encrypt TLS automation, and the admin UI for user/domain/alias management. The performance characteristics are essentially Postfix's — within hundreds-of-deliveries-per-second on appropriate hardware. Mailcow is appropriate for volumes up to ~500K msgs/day; above that, the containerized stack adds operational complexity that direct deployment avoids. For Cloud Server for Email customers running mailcow, we provide deployment + tuning consultation as part of standard managed infrastructure engagements.
Last updated: May 2026 · Sources: Postfix official documentation, Postfix Architecture Overview, Postfix Performance Tuning, Postfix Bottleneck Analysis (QSHAPE_README), Wikipedia: Postfix, Anatomy of Postfix (Linux Journal), SMTPedia Postfix 2026 guide.