Postfix vs Dovecot: Different Roles in a Receiving Email Server

Postfix and Dovecot are often installed together, but they do not do the same job. In a common receiving system, Postfix accepts and queues SMTP mail, while Dovecot delivers into or exposes a user's mailbox through LMTP and IMAP. Either service can be healthy while the complete inbox flow is broken.

This guide is a diagnostic map, not a production configuration recipe. A real deployment also needs DNS, TLS, recipient validation, spam controls, storage permissions, backups, monitoring and careful relay restrictions. Once Email is receive-only and does not expose an SMTP sending product; the examples below describe the inbound boundary only.

The short comparison

“Postfix versus Dovecot” is therefore rarely a product choice. For a hosted mailbox, it is usually a question of where one responsibility ends and the next begins.

Follow one inbound message

The Postfix architecture overview describes network mail entering through smtpd, passing through cleanup and entering a queue. The queue manager later selects a delivery agent. That creates four useful checkpoints:

1. SMTP connection: a remote sender reaches Postfix and negotiates the message.
2. Recipient acceptance: Postfix accepts or rejects the envelope recipient according to its address and access rules.
3. Queue and handoff: an accepted message is queued, then handed to local, virtual, pipe or LMTP delivery.
4. Mailbox access: after final delivery, Dovecot lets an authorised client list and read the stored message through IMAP.

Acceptance is not the same as mailbox visibility. A remote server can receive 250 from Postfix while a later LMTP or storage error leaves the message deferred. Conversely, a message can exist in the mailbox while an IMAP authentication, index or namespace problem prevents the user from seeing it.

Where LMTP joins the services

One common boundary is LMTP. Postfix keeps responsibility for SMTP and its queue, then connects to Dovecot's LMTP service for final delivery. Dovecot's Postfix and Dovecot LMTP guide shows this handoff using a protected Unix socket in the Postfix spool.

The socket is not merely a path to copy from a tutorial. Its owner, group, mode, chroot location and service availability form one security and reliability contract. If Postfix cannot reach it, the correct outcome is normally a deferred queue item, not pretending that the inbox is empty. If LMTP accepts the message, storage and quota evidence becomes more relevant than SMTP logs.

Do not make the socket world-writable to silence a permission error. Identify which service account needs access and grant the minimum required permission. Do not expose LMTP publicly unless the architecture, authentication and transport protections explicitly require it.

Diagnose by evidence, not by restarting both

Start with a unique test marker and a bounded time window. Preserve a queue ID, SMTP status class, LMTP result and redacted mailbox outcome. Do not put a real address, verification code, token, subject, body, attachment name or full URL into shared logs or analytics.

Common category mistakes

Installing Dovecot does not make an SMTP listener appear, and installing Postfix does not provide a user's IMAP inbox. SPF, DKIM and DMARC are also a different layer: they supply authentication and alignment evidence, not mailbox access. Read the separate SPF, DKIM and DMARC result guide for that task.

A queue that is empty does not prove delivery succeeded; the message could have bounced, expired, been discarded by an explicit policy or already left the queue. An inbox that is empty does not prove nothing arrived; the query may have failed, the client may be offline, or a different mailbox namespace may be selected. Keep “no result,” “temporary failure” and “confirmed empty” as separate states.

Build a four-field trace before changing configuration

For one authorised test message, capture only four redacted facts. Together they show whether acceptance, queue handoff, final delivery and mailbox visibility refer to the same transaction:

Use read-only inspection first. postqueue -p lists queued entries; filter locally by the shortened ID instead of exporting the whole queue. doveadm mailbox status -u TEST_USER "messages unseen" INBOX checks mailbox counters, but substitute only an authorised test identity and do not paste its output into public tickets. The official Postfix queue tools and Dovecot mailbox-status reference define what these observations mean. Neither command proves that the visible message is the one you tested unless timestamps and the redacted transaction marker also align.

A safe verification order

Verify the public SMTP endpoint, submit one authorised unique test message, record whether Postfix accepted it, follow its queue and delivery result, confirm the Dovecot mailbox outcome, then read it through the same IMAP path the application uses. Clean up the test mailbox and retain only redacted operational evidence.

That sequence tells you which boundary failed. Restarting both services first erases timing and queue evidence, can turn a reproducible fault into an intermittent one, and still does not explain the cause.