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.

ProtocolJobCommon port (plain)Common port (TLS/SSL)
SMTPServer-to-server mail transfer25-
Submission (SMTP)Sending mail from a client587 (STARTTLS)465 (SMTPS)
IMAPReading/syncing while keeping mail on the server143993
POP3Downloading messages110995

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.cf and service definitions in master.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.

CriterionPostfixExim
ArchitectureMulti-process, modularLargely a single binary
ConfigurationSimple, file-based (main.cf/master.cf)Flexible, ACL and string-expansion driven
Learning curveBasic setup is usually simplePowerful but detailed; takes time to learn
Typical defaultPreferred on many distributionsDefault on Debian; common with cPanel
Panel ecosystemCommon in panels like PleskIntegrated 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:

ini
# /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 = yes

Authentication 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:

RecordDNS typeWhat it does
SPFTXTDeclares which servers are allowed to send for your domain
DKIMTXTSigns outgoing messages with a cryptographic signature; proves the content wasn't altered
DMARCTXTDefines 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.