Source: https://once-email.com/blog/corecomponent Delivery and authentication · May 22, 2025Updated Aug 23, 2026 # Postfix vs Dovecot: Different Roles in a Receiving Email Server See where Postfix and Dovecot sit in the inbound mail path, what each service owns, how LMTP connects them, and which evidence to check when delivery fails. [Once Email Engineering, Once Email author Once Email Engineering]() Reviewed by Once Email technical review What this guide helps you do Identify whether an inbound mail failure belongs to SMTP receipt, queue delivery, mailbox storage or IMAP access. Article guide Why this article is worth your time **Original analysis** The guide maps one inbound message across SMTP acceptance, queueing, LMTP delivery, mailbox storage and IMAP access, then assigns each failure signal to the component that can actually produce it. **Trend context** Postfix and Dovecot remain widely combined, but container images and one-click panels often hide the boundary between transfer, final delivery and mailbox access, which makes failures easy to misdiagnose. **Practical value** Operators get a decision table and evidence-first troubleshooting order that separates SMTP acceptance, queued delivery, mailbox placement and client access without exposing message content. 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]() | Question | Postfix | Dovecot | | --- | --- | --- | | Main network role | Accepts or sends SMTP | Serves mailbox access over IMAP/POP3 and can accept final delivery over LMTP | | Owns the mail queue | Yes | No | | Decides whether an SMTP recipient is accepted | Usually Postfix and its lookup/policy services | May supply user or mailbox data, depending on the design | | Places mail into the final mailbox | Postfix can use local/virtual delivery; many designs hand off to Dovecot LMTP | Dovecot LMTP can perform final mailbox delivery | | Lets an inbox client list and read mail | No | Yes, commonly through IMAP | “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]() | Observed evidence | Most likely boundary to inspect first | | --- | --- | | Remote sender cannot connect to port 25 | DNS, firewall, TLS listener or Postfix ` smtpd ` | | SMTP rejects the recipient before message data | Postfix recipient maps and policy; possibly the user directory it queries | | SMTP accepted, message remains queued/deferred | Postfix queue status and the selected delivery transport | | Log shows LMTP socket unavailable or permission denied | Postfix-to-Dovecot LMTP socket and service permissions | | LMTP reports quota or mailbox write failure | Dovecot delivery and mailbox storage | | Message exists on disk but client cannot list it | Dovecot IMAP authentication, namespace, index and filesystem access | | Client lists the message but sender reports failure | Correlate queue ID, recipient and timestamps; do not assume the two observations refer to the same transaction | 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: | Checkpoint | Keep | What it proves | | --- | --- | --- | | SMTP acceptance | Timestamp, enhanced status class and a shortened queue ID | Postfix accepted this transaction; it does not prove final delivery | | Queue outcome | Same shortened queue ID, transport name and delivered/deferred state | Postfix selected a transport and either completed or retained the handoff | | LMTP outcome | Success or enhanced error class, without recipient or message text | Dovecot LMTP accepted final delivery, or returned a bounded reason | | Mailbox visibility | Mailbox count before/after and the application read result | Storage changed and the same read path can, or cannot, see the result | 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. ## Related guides How to Read Received Headers and Trace an Email Delivery Path Follow Received header fields in the correct order, compare timestamps safely and recognise the limits of hostnames, IP addresses and untrusted trace data. [How to Read Received Headers and Trace an Email Delivery Path]() How to Use a Temporary Email API Without Building Flaky Tests A practical design for temporary-email API tests: isolate each run, poll with backoff, identify the right message, protect secrets and always clean up. [How to Use a Temporary Email API Without Building Flaky Tests]() Verification Email Not Arriving? A Safe Troubleshooting Checklist Work through address mistakes, sender delays, retries, filtering and mailbox limits without repeatedly requesting codes or weakening account security. [Verification Email Not Arriving? A Safe Troubleshooting Checklist]() ## Use a related tool Email header analyzer Explain delivery hops and summarize SPF, DKIM and DMARC evidence without claiming absolute authenticity. [Email header analyzer]() [Batch-download Email Attachments and Unpack Them Locally with UnpackFlow Use a dedicated folder, verify every browser download, then list, plan and unpack multipart or nested archives locally without uploading them to an online service.]() [How Long Does a Temporary Email Last? Plan Before It Expires Understand Once Email lifetime choices, deletion and replacement, then decide what to save and when an account needs a permanent recovery address.]()