Postfix and Dovecot Explained for People Who Aren't Sysadmins

If you have ever opened a mail server tutorial and hit a wall of config files, this is the post that should have come first. Postfix and Dovecot explained for beginners comes down to one sentence: Postfix talks to other mail servers, and Dovecot talks to your mail app.

They are two separate programs, written by different people for different jobs. They are installed together so often that people assume they are one system with two names — which is exactly why a broken setup is hard to diagnose. You cannot fix it until you know which half is failing.

This post maps the division of labour, shows where the two actually touch, and gives you a way to tell which one to look at when mail stops moving.

What is Postfix?#

Postfix is a Mail Transfer Agent, or MTA. Its job is SMTP — the protocol mail servers use to hand messages to each other. It is Wietse Venema's mail server, which began at IBM Research as an alternative to Sendmail.

Inside Postfix, mail arrives at the smtpd server from the network, passes through cleanup, and lands in the incoming queue. The queue manager qmgr then hands each message to a delivery agent: smtp for mail leaving your server, lmtp for handing it to a mailbox server, local or virtual for writing it to disk directly.

That queue is the underrated part. If a remote server is down, Postfix holds the message in a deferred queue and retries on a schedule rather than losing it. Nothing in Postfix serves mail to a mail app, though — there is no IMAP or POP3 server anywhere in it.

What is Dovecot?#

Dovecot's own documentation describes it as an open source IMAP and POP3 email server for Linux and UNIX-like systems, written with security primarily in mind. That is the whole job: hold the mail, and hand it to the client that asks for it.

When Thunderbird, Apple Mail or your phone connects to the server, downloads a folder list, marks something read or moves it to Archive, it is talking to Dovecot. Folders, read and unread flags, the search index, the storage format on disk — all Dovecot.

Dovecot also does two jobs that surprise beginners: it usually owns your user accounts and passwords, and it runs your server-side filtering rules. Both come up below, because both are places the two programs overlap.

How the handoff actually works#

Follow one inbound message end to end and the split becomes obvious. Someone emails you from Gmail, and this is the path it takes.

1. 1

   Gmail connects to your server over SMTP

   Postfix answers. It checks the recipient exists and whether to accept the message at all — that is where spam rejection and relay rules live.

2. 2

   Postfix queues the message

   It lands in the incoming queue and the queue manager picks it up. Your server has now taken responsibility for the message.

3. 3

   Postfix sees a local recipient

   Mail for a domain you host does not go back out to the internet. It goes to a local delivery agent instead.

4. 4

   Postfix hands it to Dovecot over LMTP

   LMTP (RFC 2033) is a delivery protocol similar to SMTP. In Postfix's main.cf this is virtual_transport = lmtp:unix:private/dovecot-lmtp for virtual users, or mailbox_transport for system users.

5. 5

   Dovecot writes it to the mailbox

   Dovecot's LMTP service runs your Sieve rules, files the message into the right folder, and updates its index so search and unread counts stay correct.

6. 6

   Your mail app asks for it over IMAP

   Minutes or milliseconds later, your client connects to Dovecot on port 993 and sees the new message. Postfix is no longer involved.

Why LMTP rather than writing to disk#

Postfix can write mail to a mailbox file itself, using its local or virtual delivery agents, and plenty of older guides do exactly that. It works, and it is also the source of a class of bug that is miserable to debug.

Dovecot keeps index files describing what is in each mailbox. If Postfix drops a message into the folder behind Dovecot's back, those indexes have to catch up — and quotas and Sieve rules are skipped entirely, because they live on the Dovecot side.

Delivering over LMTP means Dovecot is the only thing that ever writes to the mail store. Its documentation recommends LMTP for most installations, which is why modern setups default to it.

Where authentication fits, and why it confuses everyone#

Here is what trips up almost every beginner. Sending mail from your own client also uses SMTP, so it goes to Postfix — but your username and password live in Dovecot.

Postfix solves this by borrowing Dovecot's authentication service instead of running its own. The Postfix documentation is explicit: Dovecot is a POP/IMAP server with its own configuration for authenticating POP/IMAP clients, and when the Postfix SMTP server uses Dovecot SASL it reuses parts of that configuration.

In practice that is three settings in Postfix's main.cf — smtpd_sasl_type = dovecot, smtpd_sasl_path = private/auth and smtpd_sasl_auth_enable = yes — pointed at a socket Dovecot creates inside the Postfix spool directory. One password store, two protocols.

It is also why a password change can appear to break sending and receiving at once. That is not two failures. It is one account database that both programs read.

Where Sieve filtering runs#

Server-side filtering rules — file this sender into that folder, send a vacation reply, reject mail matching a pattern — are written in Sieve, defined in RFC 5228. On this stack Sieve is Dovecot's job, not Postfix's.

Dovecot's Sieve support comes from Pigeonhole, which runs as a plugin on the LMTP and LDA delivery services. That placement matters: rules execute at the moment of delivery, after Postfix has already accepted the message and passed it on. Dovecot's ManageSieve service lets users upload their own scripts without shell access.

The consequence: a rule that never fires is a Dovecot problem, even though the mail arrived through Postfix. Extensions verified as of September 2026 include fileinto, vacation and reject; the current list is in the Pigeonhole documentation.

MTA, MDA, MUA — the comparison that makes it click#

Mail server documentation uses three abbreviations constantly and rarely defines them in the same place. This is the whole vocabulary, and each program sits in exactly one row.

What breaks when one of them stops#

Because the two programs own different halves, the symptom tells you which one to look at. This table has saved more debugging hours than any single config snippet.

Common misconceptions#

Five beliefs cause most of the confusion here.

That Postfix handles IMAP. It does not, and never has. If your client cannot download mail, Postfix logs will not tell you why.

That you only need one of them. Postfix alone can accept and send mail but gives you no way to read it in a mail app. Dovecot alone can serve mail to clients but cannot receive anything from the internet or send a reply.

That Dovecot never speaks SMTP. Mostly true, with a real exception: Dovecot ships a Submission service, an MSA under RFC 6409. Its own documentation is blunt that this is not a full SMTP server and requires proxying to an external relay to deliver anything. It is a front end, not a replacement for Postfix.

That they must run on the same machine. They usually do, and config examples assume it, but LMTP is a network protocol — one Postfix server can feed several mailbox servers.

That the mailbox format is Postfix's decision. Maildir versus mbox versus dbox is a Dovecot setting, because Dovecot reads and writes the store.

Where a mail client fits, and where AI Emaily fits#

Notice what neither program does. Neither reads your mail, sorts it by what actually needs an answer, or drafts a reply. Postfix moves messages and Dovecot stores them; the judgement about what matters happens in the client — the MUA row of that table — which you choose independently of your server.

That is the layer we build. AI Emaily is an email client that connects to any IMAP server, including a Postfix and Dovecot box you run yourself, and adds triage, drafting and an agent that can act on a thread — with approval before anything sends, an undo window, and an audit trail. It matches your writing style from a Personal Context brain and client profiles you set yourself, not by mining your sent folder.

Two honest limits on a Linux server: we have no native Linux desktop build, so on Linux it is the web app. And a client cannot fix a server problem — if Dovecot is refusing connections, no mail app will help.