When you send an email, the message isn't handled by a single program. Behind the scenes, several pieces of software cooperate to carry it from you to the recipient. In the open-source world, three names form the backbone of that work: Postfix, Dovecot and Exim. This guide explains what each of them does, how they differ, and how they fit together for a news site or a corporate domain.
What Is a Mail Server?
A mail server is the software (and the machine running it) that accepts email, relays it to other servers, and delivers it into users' mailboxes. In practice it isn't one program but a set of components, each with its own job. Separating those roles makes it far easier to see where Postfix, Exim and Dovecot each fit.
- MTA (Mail Transfer Agent): Moves mail between servers over SMTP. This is the role Postfix and Exim play.
- MSA (Mail Submission Agent): Accepts new messages from users (usually on port 587); it's typically a configuration of the MTA.
- MDA (Mail Delivery Agent): Writes an incoming message into the correct mailbox. Dovecot can do this via LMTP/LDA.
- Access layer (MRA): Lets users read their mailbox over IMAP/POP3. This is Dovecot's core specialty.
- MUA (Mail User Agent): The user's software, such as Outlook, Thunderbird or a webmail interface.
The Journey of an Email and Its Core Protocols
On its way from sender to recipient, a message passes through several standard protocols. Because these have been in place for years, knowing which component listens on which port makes both setup and troubleshooting much easier.
| Protocol | Job | Common port (plain) | Common port (TLS/SSL) |
|---|---|---|---|
| SMTP | Server-to-server mail transfer | 25 | - |
| Submission (SMTP) | Sending mail from a client | 587 (STARTTLS) | 465 (SMTPS) |
| IMAP | Reading/syncing while keeping mail on the server | 143 | 993 |
| POP3 | Downloading messages | 110 | 995 |
Port 25 is used for server-to-server transfer, while port 587 (with STARTTLS) is the recommended path for users sending mail. On the reading side, IMAP is usually a better fit than POP3 because messages stay on the server and stay in sync across multiple devices.
The MTA Role: Postfix and Exim
Postfix and Exim do the same fundamental job: they receive, route and send email over SMTP. The difference lies in philosophy and configuration style. Both are mature, widely used and well-documented open-source MTAs.
Postfix
Postfix is an MTA created by Wietse Venema as a safer, clearer alternative to the older Sendmail. It's the default or preferred mail transport on many Linux distributions. Its notable traits:
- Modular architecture: Instead of one large process, it's built from small processes that each run with limited privileges, which is an advantage for security.
- Straightforward configuration: Main settings live in
main.cfand service definitions inmaster.cf. - Sendmail compatibility: It works largely as a drop-in for applications that expect Sendmail.
- Broad integration: It combines easily with SASL authentication, TLS, virtual domains and external delivery agents such as Dovecot LMTP.
Exim
Exim is an MTA developed at the University of Cambridge, known for the flexibility of its configuration. It ships as the default MTA on some distributions such as Debian and shows up frequently in cPanel-based hosting environments. Its notable traits:
- Single-binary design: Unlike Postfix's multi-process model, it is built largely around one program.
- Powerful configuration language: Access Control Lists (ACLs) and string expansion let you write very fine-grained rules.
- Flexibility: Its router and transport layers adapt well to complex delivery scenarios.
- Panel affinity: Because it's built into the cPanel/WHM ecosystem, it is common on shared hosting.
Postfix vs. Exim
Both MTAs deliver reliable results; the choice usually comes down to your team's familiarity, the control panel in use, and configuration preferences. The table below summarizes general tendencies. There is no absolute 'best' option; it depends on the need.
| Criterion | Postfix | Exim |
|---|---|---|
| Architecture | Multi-process, modular | Largely a single binary |
| Configuration | Simple, file-based (main.cf/master.cf) | Flexible, ACL and string-expansion driven |
| Learning curve | Basic setup is usually simple | Powerful but detailed; takes time to learn |
| Typical default | Preferred on many distributions | Default on Debian; common with cPanel |
| Panel ecosystem | Common in panels like Plesk | Integrated with cPanel/WHM |
Dovecot: The Reading and Delivery Layer
Dovecot is an open-source server specializing in IMAP and POP3, designed with performance and security in mind. It handles the reading side of a user's mailbox, and beyond reading it also fills a few critical supporting roles:
- IMAP/POP3 server: Provides secure access to messages over ports 993/995 (TLS).
- Local delivery (LDA/LMTP): Writes messages coming from the MTA into the mailbox; Sieve enables rule-based filtering.
- SASL authentication: It's common for Postfix to delegate user authentication for submission to Dovecot.
- Mailbox formats: It supports formats such as Maildir and mbox; Maildir is often preferred in multi-user environments.
How Do They Work Together?
In a typical open-source setup, Postfix (or Exim) receives the message from the internet, hands the incoming mail to Dovecot (over LMTP) for delivery, and the user reads it through Dovecot's IMAP service. On the sending side, Postfix can use Dovecot's SASL service to authenticate the user. Below is an example configuration snippet on the Postfix side showing that cooperation:
# /etc/postfix/main.cf (example snippet)
# Use Dovecot LMTP to deliver incoming mail
mailbox_transport = lmtp:unix:private/dovecot-lmtp
# Enable TLS (certificate paths are examples)
smtpd_tls_cert_file = /etc/ssl/certs/mail.crt
smtpd_tls_key_file = /etc/ssl/private/mail.key
smtpd_tls_security_level = may
# Delegate user authentication for submission to Dovecot SASL
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_auth_enable = yesAuthentication and Encryption
Security for an email stack comes down to two things: encrypting the connection and verifying the sender. A modern setup is expected to include:
- TLS/STARTTLS: Encrypts client-to-server traffic and, where possible, server-to-server traffic. TLS has become standard for submission (587) and IMAP/POP3 (993/995).
- SASL authentication: Password verification so users can only send from their own accounts; it prevents unauthenticated relaying (an open relay).
- Strong passwords and rate limiting: Throttling repeated attempts (for example with tools like fail2ban) helps against brute-force attacks.
Deliverability: SPF, DKIM and DMARC
Whether your message lands in the inbox rather than the spam folder depends heavily on domain authentication records. These three records are defined on the DNS side and work together:
| Record | DNS type | What it does |
|---|---|---|
| SPF | TXT | Declares which servers are allowed to send for your domain |
| DKIM | TXT | Signs outgoing messages with a cryptographic signature; proves the content wasn't altered |
| DMARC | TXT | Defines the policy to apply based on SPF and DKIM results, plus reporting |
Spam, Reputation and Operations
Running your own mail server also means taking on responsibility for deliverability and reputation management. The key topics:
- IP reputation: The history of the sending IP matters; new IPs may need a 'warm-up' period.
- Reverse DNS (PTR): The sending IP is expected to have a valid PTR record.
- Spam filtering: On the inbound side, content- and reputation-based filters (such as Rspamd or SpamAssassin) can be used.
- Blocklist monitoring: Regularly check whether your domain and IP appear on blocklists.
Panel or Manual Setup?
Installing Postfix, Exim and Dovecot by hand gives you full control, but it leaves the upkeep of layers like SPF/DKIM/DMARC, TLS and spam filtering to you. Many teams instead use a hosting panel that manages the MTA and IMAP/POP3 server in a ready, integrated way. You can explore how panels approach email in these articles: Plesk, cPanel (which ships with Exim) and DirectAdmin. On the user's reading side, a webmail interface such as Roundcube comes into play.
Legal and Compliance Note (Turkey)
Running your own mail infrastructure inevitably involves processing personal data. In Turkey, the protection of personal data is governed by the Personal Data Protection Law No. 6698 (KVKK); because email addresses and message contents can qualify as personal data, their security, retention periods and access controls should be assessed within that framework. Responsibility for publication and content on the internet is addressed under Law No. 5651. The concrete obligations of these rules vary with the type of data you process and your role (data controller or processor).