Self-hosted email infrastructure, honestly reviewed. Not a beginner product — here’s what it actually costs to run your own SMTP server.

TL;DR

What it is: Postfix is a Mail Transfer Agent (MTA) — the daemon that speaks SMTP and routes email. It shipped as a security-hardened Sendmail replacement in 1999 and is today the default MTA on Ubuntu, Debian, RHEL, and most Linux derivatives [postfix.org].
Who it’s for: Linux sysadmins and DevOps engineers building or operating email infrastructure. Not a product for non-technical founders to deploy solo.
Cost savings: Google Workspace Business Starter runs $6/user/month. A self-hosted stack built on Postfix + Dovecot on a $6 VPS is ~$6/month flat regardless of user count — but that comparison hides the operational overhead, which is real and ongoing [1][3].
Key strength: 25+ years of production hardening, modular security architecture, runs on everything from ancient HP-UX to Kubernetes, integrates with any filter or database you need [postfix.org].
Key weakness: Postfix alone gives you SMTP. A working email server requires Dovecot (IMAP), OpenDKIM or Rspamd (DKIM signing), a spam filter, a webmail client, working DNS, and the operational knowledge to keep deliverability intact [1][2][3]. “Running Postfix” and “having email” are not the same sentence.

What is Postfix

Postfix is an MTA — the process that accepts mail from clients or other servers via SMTP, routes it, and delivers it either locally or to a remote destination. It was written by Wietse Venema at IBM Research in the late 1990s as a more secure, more maintainable alternative to Sendmail, the software that had handled Unix email for fifteen years but had accumulated a reputation for security vulnerabilities and incomprehensible configuration [postfix.org].

The design philosophy shows in the architecture. Postfix is not a single daemon but a collection of independent processes — each responsible for one job (accepting mail, queueing, delivering, filtering) — communicating over Unix sockets. The master process is the only piece that runs as root, and only long enough to bind to port 25, then drops privileges. A crash in one component does not cascade. This isolation is why Postfix has maintained a strong security record while Sendmail kept generating CVEs [postfix.org].

The project is licensed under IBM Public License 1.0 (IPL-1.0), an OSI-approved open source license. It lives at http://www.postfix.org rather than GitHub — reflecting its age, pre-dating modern open source hosting. Most Linux distributions ship it in their standard repositories. The website describes it plainly: “Postfix attempts to be fast, easy to administer, and secure. The outside has a definite Sendmail-ish flavor, but the inside is completely different” [postfix.org].

What Postfix is not: it is not a web application, not a self-service tool with a management UI, and not a complete email solution. It is infrastructure. Configuration happens in flat text files (main.cf, master.cf), management happens in the terminal, and debugging happens in log files.

Why people choose it

Nobody chooses Postfix in 2026 because it just launched a compelling feature. They choose it for specific, defensible reasons.

Ubiquity and maturity. When a Linux server needs to send email — cron job alerts, monitoring notifications, application password resets — Postfix is usually already installed and waiting to be configured [1]. That ubiquity means the community knowledge base is enormous. Every obscure configuration problem has a Stack Overflow answer that’s ten years old and still correct.

Security architecture. The process isolation model has made Postfix consistently more resistant to critical vulnerabilities than alternatives. This is not marketing language — it is a track record accumulated across 25 years and observable by comparing CVE histories between MTAs [postfix.org].

Composability at scale. The articles gathered for this review show who actually uses Postfix in 2026: engineers building systems. The Medium tutorial [1] builds a full local mail environment with Postfix + Dovecot + TLS for DevOps learning. Two container guides [2][3] integrate Postfix as an SMTP relay inside Kubernetes and Docker Compose stacks. A ServerFault thread with 54,000 views [4] shows developers routing application mail from containers through a Postfix host relay. A Dev.to guide [5] adds Postfix Admin as a PHP-based management layer. The pattern is consistent: Postfix as a building block, not a finished product.

No per-message billing. Transactional email services (SendGrid, Mailgun, Postmark) charge by volume beyond free tiers. Applications sending tens of thousands of emails per month can accumulate $50–$200/month in email bills. A Postfix relay on a $6 VPS has no per-message charge. As sending volume grows, the cost of self-hosted stays flat [2].

Features: what it actually does

Core SMTP engine:

SMTP server (inbound) and SMTP client (outbound delivery) [postfix.org]
Message queuing with configurable retry intervals, expiry, and bounce handling
Virtual domain routing — multiple domains through one instance [postfix.org]
Transport maps — route different domains or users through different upstream relays [3][postfix.org]
LDAP, MySQL, PostgreSQL, and SQLite for address and routing lookups [2]

Security and filtering:

TLS for inbound and outbound SMTP [1]
SASL authentication (requires Cyrus SASL or Dovecot SASL as a companion)
Milter interface — plugs in external filters: OpenDKIM, SpamAssassin, ClamAV, Rspamd [postfix.org]
Built-in policy restrictions on client, sender, recipient, and message content

Deployment:

Runs on AIX, BSD, HP-UX, Linux, macOS, Solaris [postfix.org]
Docker-deployable, but there is no official Docker image — you build your own from Alpine or Debian, or trust a community image of unknown provenance [2]
Kubernetes-deployable via custom containers, with documented failure modes around DNS resolution [3]
Configuration via main.cf and master.cf, with postfix reload for live reloads
Container logging via maillog_file = /dev/stdout redirect [2][3]

What Postfix does not include:

IMAP/POP3 — you need Dovecot or Courier [1]
Webmail — Roundcube, SnappyMail, or Rainloop are standard additions
Web management UI — Postfix Admin is a separate PHP project [5]
Spam filtering — SpamAssassin or Rspamd via Milter [1]
DKIM signing — OpenDKIM or Rspamd handle this
Automatic header injection — missing headers (Message-ID, Date, From) on unauthenticated connections will cause rejection by major providers [4]

Pricing: SaaS vs self-hosted math

If you’re replacing business email:

Google Workspace Business Starter is $6/user/month. For 5 users: $30/month, $360/year. At 20 users: $120/month, $1,440/year. A self-hosted stack on a $6–10 VPS covers unlimited users; the software is free.

Raw math: $1,440/year (Google, 20 users) vs. ~$90/year (VPS) = ~$1,350/year saved.

If you’re replacing transactional email:

Transactional email services charge beyond free tiers. A SaaS sending 50,000 emails/month might pay $35–$90/month depending on provider. A Postfix relay handles this for the cost of the VPS.

The honest accounting:

These numbers assume your Postfix installation is correctly configured and your email reaches inboxes. That assumption has a lot of work behind it. Getting past spam filters requires: correct SPF records, working DKIM signing (OpenDKIM or Rspamd, configured separately), DMARC policy, a valid PTR record on your IP, and an IP that hasn’t been listed on common blocklists. Postfix handles none of this automatically [4].

A misconfigured stack sends email that gets silently dropped into spam or rejected outright. A missed password reset email or a bounced monitoring alert has real costs. Factor in 8–20 hours of initial setup time for a complete stack, plus occasional maintenance when deliverability issues surface. The VPS cost is $90/year; the total cost of ownership is higher. Whether that trade-off is worth it depends on whether you have someone capable of owning it.

Deployment reality check

The container articles show what Postfix deployment actually looks like, including where it gets painful.

No official Docker image. This is a real gap [2]. The Bored Consultant builds one from Alpine in 15 lines of Dockerfile. FrakkingSweet uses Debian [3]. Both approaches work, but it means maintaining your own image and build pipeline. Contrast with Nginx, Redis, or PostgreSQL, which have official images with documented best practices.

Container failure modes are non-obvious. The FrakkingSweet article [3] documents a debugging sequence that took multiple iterations to resolve:

“private/relay socket: malformed response” — caused by /etc/services not being present inside the container, which Postfix needs for SMTP service lookup
DNS resolution failures inside the container required separate investigation
Config directory layout needed symlink-based mounts to avoid overwriting other files in /etc/postfix

These are solvable in an afternoon. They cost that afternoon.

The Docker-in-Docker relay problem. The ServerFault thread [4] (54,000 views — a reliable signal of how commonly this question arises) shows engineers routing mail from application containers through a Postfix relay on the host. The core issue: sending raw SMTP without proper headers (Message-ID, Date, From) from inside a container causes external providers to reject the mail [4]. Postfix on an unauthenticated connection does not inject these headers automatically. Engineers expecting Postfix to behave like a managed SMTP API get burned here.

Postfix Admin [5] is the management UI most teams add for mailbox and domain management. It’s a separate PHP application requiring MySQL, configured behind nginx or Apache. Adding it to a Docker Compose setup adds meaningful complexity: a database container, a PHP-FPM container, an nginx configuration for fastcgi passthrough, and setup password hashing [5].

Realistic time estimates:

Postfix as an application relay (outbound only, single VPS): 1–3 hours
Full stack (Postfix + Dovecot + Rspamd + Roundcube + DKIM/SPF/DMARC): 8–20 hours
First time without a guide: add 50%

Pros and cons

Pros

25 years of production hardening. Postfix routes a material fraction of global email. Its reliability track record is the strongest argument for it [postfix.org].
Ships with every major Linux distribution. apt install postfix puts it on any Debian-based server in seconds, with distribution-maintained configuration defaults [1].
Modular security architecture. Process isolation limits blast radius from vulnerabilities. Each component runs with minimal privileges [postfix.org].
Composable with everything. LDAP, MySQL, PostgreSQL address lookups; Milter support for any external filter; transport maps for complex multi-domain routing [2][3][postfix.org].
Runs anywhere. AIX, HP-UX, Solaris, every Linux variant, macOS [postfix.org]. Unusual Unix environment? Postfix probably supports it.
No per-message cost. Sending volume is bounded by hardware and IP reputation, not a vendor billing counter [2].
Deep documentation and community. Postfix.org documentation is exhaustive. The community knowledge base spans 25 years.

Cons

Not a complete email solution. IMAP, webmail, spam filtering, DKIM signing, and web management are all separate projects that need to be sourced, configured, and integrated [1][3][5].
No official Docker image. You maintain your own Dockerfile [2]. For production environments, this is an ongoing ownership burden.
Container deployment has documented failure modes that require debugging time: missing /etc/services, DNS resolution issues, header injection behavior [3][4].
Flat-file configuration. main.cf is powerful but dense. Syntax errors produce log messages that require background knowledge to interpret [1][3].
Deliverability is entirely your responsibility. SPF, DKIM, DMARC, PTR, IP reputation — Postfix handles none of this automatically [4]. A gap in any of these causes silent delivery failures.
No management UI out of the box. Postfix Admin requires a separate PHP application with its own database and web server [5].
IPL-1.0 is less familiar than MIT or Apache 2.0. OSI-approved and permissive for use, but worth reading before embedding in something you redistribute commercially.

Who should use this / who shouldn’t

Use Postfix if:

You’re a sysadmin or DevOps engineer who needs a reliable SMTP relay for application mail and you’re comfortable debugging Linux mail logs.
You’re assembling a complete self-hosted email stack and want the most battle-tested MTA component available.
You’re running a high-volume application where transactional email costs are significant and you have the infrastructure capability to own deliverability.
You’re learning how SMTP works at a protocol level [1] — Postfix + Dovecot + telnet is one of the best hands-on environments for that.

Skip it (use a managed transactional service) if:

Your primary need is sending application emails (password resets, notifications, alerts) and you want guaranteed deliverability without managing infrastructure. SendGrid, Postmark, and Mailgun solve the deliverability problem so you don’t have to. For low-to-moderate volume, the cost is often lower than you think.
You’re a non-technical founder. The setup complexity, absence of a management UI, and ongoing deliverability ownership make raw Postfix a significant operational commitment that regularly bites people who underestimate it.

Skip it (use a complete self-hosted stack) if:

You want self-hosted email but not the assembly work. Mail-in-a-Box, Mailcow, and Mailu all bundle Postfix internally but expose a management UI and handle DNS configuration. They are the right starting point for technical users who want email ownership without building a stack from parts.

Alternatives worth considering

Complete self-hosted email stacks (use Postfix internally):

Mail-in-a-Box — the simplest complete self-hosted email server. Single-script install handles Postfix, Dovecot, Roundcube, spam filtering, and DNS setup. For technical-but-not-sysadmin users wanting self-hosted email, this is the honest first recommendation.
Mailcow — Docker Compose-based, more features (SOGo groupware, ActiveSync), actively maintained, well-documented. The most popular full-stack option in r/selfhosted.
Mailu — Docker Compose, simpler than Mailcow, clean setup documentation.
docker-mailserver — community-maintained Postfix + Dovecot Docker image; what most engineers reach for when they want a containerized stack without building from scratch.

Alternative MTAs:

Exim — the other major Unix MTA. More granular configuration control, widely deployed on cPanel hosts. Longer CVE history than Postfix.
OpenSMTPD — from the OpenBSD project. Modern, clean, excellent security record, smaller feature surface. Worth evaluating if you want something newer than Postfix.
Sendmail — the original. Do not use it for new deployments.

Managed services (when self-hosting the MTA isn’t the right trade-off):

SendGrid / Mailgun / Postmark — for transactional email. They own deliverability; you pay per message.
Google Workspace / Microsoft 365 — for business email. More expensive at scale, zero infrastructure overhead.

Bottom line

Postfix is not a product you evaluate by signing up for a trial and clicking around a UI. It is infrastructure that you assemble into a larger system, configured through text files, operated from the command line, and maintained by someone who understands SMTP well enough to investigate a deliverability problem without panicking. For that person — or a team that includes that person — it is the most reliable, most widely deployed MTA available, and it will run for years without demanding much attention. For a non-technical founder who read “escape expensive SaaS email” and felt excited: the honest recommendation is to look at Mail-in-a-Box or Mailcow first. Both use Postfix under the hood and hide the operational complexity behind a management UI. Self-hosted email is achievable; raw Postfix is not where the journey starts.