What Is Postfix and What Role Does It Play in a Mail Server?
Postfix is the SMTP server (Mail Transfer Agent, or MTA) in a mail stack: it accepts mail from the internet or from your own users, decides where each message should go, and hands it off to the next hop. You need it if you want to send or receive mail at all — it is the component that actually speaks SMTP on port 25 and the submission ports. It does not store mailboxes for reading (that is Dovecot's job), does not filter spam on its own (that is Rspamd's job), and does not give you a web interface. In a containerized suite like mailcow, Postfix is one container among several, and most of what you configure is relay, ports, TLS, and the mail queue.
The core job: receive, relay, deliver
Postfix does three things in sequence, and almost every problem you will hit maps to one of them:
- Receive — accept an inbound SMTP connection, check whether the recipient domain is one it handles, and take responsibility for the message.
- Relay — decide the next destination. For local recipients it passes the message to the delivery agent (in mailcow, Dovecot's LMTP service). For outbound mail it looks up the recipient domain's MX record and opens a connection there.
- Deliver — complete the handoff, or hold the message in the queue and retry if the remote side is unavailable.
The queue is the key mental model. A message Postfix has accepted but not yet delivered lives in the queue, and it stays there until delivery succeeds or the retry window expires. That is why "mail is stuck" almost always means "look at the queue," not "look at the mailbox."
How Postfix differs from the rest of the stack
These components are often confused because they all touch email, but they operate at different layers:
| Component | Protocol / role | What it does | What it does not do |
|---|---|---|---|
| Postfix | SMTP | Receives, relays, queues, delivers mail | Store mailboxes, filter spam, provide a UI |
| Dovecot | IMAP / POP3 / LMTP | Stores mailboxes, serves mail to clients | Accept mail from the internet |
| Rspamd | Content filtering | Scores and filters spam/viruses | Move mail between servers |
| Web UI | HTTP | Manage domains, mailboxes, settings | Handle SMTP traffic |
A useful way to hold this in your head: Postfix is the postal service, Dovecot is the mailbox on your wall, Rspamd is the mailroom inspector, and the web UI is the administration office. They are separate processes with separate logs, which is why a "mail problem" needs to be localized to one of them before you start changing configuration.
Where Postfix sits in a containerized suite like mailcow
mailcow packages Postfix, Dovecot, Rspamd, SOGo, Nginx, and supporting services as separate Docker containers orchestrated together. Postfix is one of them, and it is the container that binds the SMTP ports. Its configuration is generated from the suite's own settings rather than edited directly in most cases — you change a domain, relay, or TLS option through the suite, and the Postfix configuration is regenerated to match.
This matters practically: if you hand-edit Postfix config files inside the container, those edits can be overwritten the next time the suite regenerates configuration or you update. Treat the suite's settings as the source of truth and the container's files as generated output.
mailcow's own release notes show Postfix tracked as a versioned component alongside the rest of the stack — for example, the Mooly 2026 update bumped Postfix to 3.10.12 together with Rspamd 4.1.0 and Nginx 1.30.3. That is the pattern to expect: Postfix updates arrive as part of suite updates, not as something you patch independently.
Configuration touchpoints you will actually deal with
Most day-to-day Postfix work in a managed suite comes down to four areas:
- Relay — sending outbound mail through a smarthost instead of directly, common when your host blocks port 25 or you want a provider to handle deliverability. You set the relay host and credentials; Postfix routes all outbound mail through it.
- Ports — port 25 for server-to-server mail, and submission ports (typically 587 with STARTTLS, or 465 with implicit TLS) for your own users' mail clients. If clients can receive but not send, the submission port or its authentication setting is the first thing to check.
- TLS — certificates for inbound and outbound connections. Expired or mismatched certificates produce connection failures that look like delivery problems but are actually handshake problems.
- Queue handling — inspecting, flushing, or deleting queued messages. This is the operational lever when mail is delayed.
Typical failure symptoms and where to look first
| Symptom | Likely layer | First place to look |
|---|---|---|
| Mail stuck in queue, retrying | Postfix | Queue contents and the reason each message is deferred (connection refused, DNS failure, TLS error) |
| "Relay access denied" | Postfix | Whether the sending client is authenticated and whether its address is allowed to relay |
| TLS handshake errors | Postfix / certificates | Certificate validity and whether the port expects STARTTLS or implicit TLS |
| Mail delivered but not visible in client | Dovecot | Mailbox storage and IMAP service, not Postfix |
| Spam arriving unfiltered | Rspamd | Filtering service and its connection to Postfix, not Postfix itself |
The general rule: if the message never left your server, it is Postfix. If it left and arrived but the user cannot see it, it is Dovecot. If it arrived and should have been blocked, it is Rspamd.
Deciding whether you need to think about Postfix at all
If you run a managed mail suite, Postfix is present whether or not you configure it directly — you inherit it as part of the stack. You only need to engage with it when you change relay settings, adjust ports or TLS, or troubleshoot delivery and queue behavior. If you are building a mail server from components, Postfix (or an equivalent MTA) is not optional: without an SMTP server, nothing sends or receives mail, and the rest of the stack has nothing to store or filter.