What are we building?

By the end, Stalwart 0.16.14 runs as a single Docker container on your server and provides everything a full-featured mail server needs:

• SMTP (send/receive) on ports 25, 465 and 587,
• IMAP (993) and the modern JMAP for fast, efficient clients,
• ManageSieve (4190) for server-side filter rules,
• a built-in spam and phishing filter (no separate Rspamd/ClamAV needed),
• integrated storage (RocksDB) – no external database,
• a modern web interface to manage domains, accounts and settings.

The big difference from Mailcow: it’s one process, one container, a few hundred megabytes of image. That significantly reduces RAM demand, attack surface and maintenance effort. Tested with Docker 29 on Debian 13.

Why is the lean approach worth it? A classic mail server stack consists of a good dozen services – Postfix, Dovecot, Rspamd, a database server, a virus scanner, Redis, a web server – all of which run individually and have to be updated and tuned to each other. Each of them is a potential source of error and a piece of attack surface. Stalwart bundles the same functionality into a single application written in Rust. Rust also brings memory safety out of the box – for software that accepts unfiltered data from the entire internet, that’s a real security argument.

Prerequisites

• A dedicated server with Debian 13 and Docker installed, on which the mail and web ports are free (no reverse proxy occupying 25/443).
• A domain whose DNS you control yourself – for the mail server’s A record and the MX record.
• Outbound port 25 must be open. Many providers block it against spam; at netcup you enable it via a support ticket. Without an open port 25 you can’t deliver mail to other servers.
• A PTR/reverse-DNS entry for the server IP (in the netcup SCP) that points to your mail hostname.

Stalwart is frugal – a small server is enough to start. How much your setup needs in total is estimated by the server calculator.

Step by step

Step 1: Create the DNS records

First set up the DNS entries – they need time to propagate. YOUR_DOMAIN is your mail domain, YOUR_SERVER_IP the server’s IPv4 address:

mail.YOUR_DOMAIN.   A     YOUR_SERVER_IP
YOUR_DOMAIN.        MX    10 mail.YOUR_DOMAIN.

The MX record refers other mail servers to mail.YOUR_DOMAIN. This hostname is your server’s identity. SPF, DKIM and DMARC we add in the deliverability tutorial – Stalwart generates the DKIM keys itself during setup.

Step 2: Write the compose.yaml

Create a folder and change into it:

mkdir -p /opt/stalwart && cd /opt/stalwart

Create the file compose.yaml:

services:
  stalwart:
    image: stalwartlabs/stalwart:v0.16.14
    container_name: stalwart
    restart: unless-stopped
    ports:
      - "25:25"       # SMTP (server-to-server)
      - "465:465"     # SMTPS (send, implicit TLS)
      - "587:587"     # Submission (send, STARTTLS)
      - "143:143"     # IMAP
      - "993:993"     # IMAPS
      - "4190:4190"   # ManageSieve
      - "8080:8080"   # web interface & JMAP (initial setup)
      - "443:443"     # HTTPS (after setup, own certificate)
    volumes:
      - stalwart_data:/opt/stalwart
volumes:
  stalwart_data:

The most important thing: one service, one volume for all data. Stalwart fetches its TLS certificate later itself via Let’s Encrypt – you don’t need a separate reverse proxy for that. Make sure port 443 is free on the host (Stalwart also uses it for the certificate retrieval, see step 4).

Step 3: Start the container and get the startup password

Start Stalwart:

docker compose up -d

On the very first start, Stalwart runs in bootstrap mode: there’s no configuration yet, and port 8080 is open for the initial setup. In the process it generates a one-time administrator password that you read from the logs:

docker compose logs | grep -A2 "temporary administrator"

🔑 Stalwart bootstrap mode - temporary administrator account
   password: <ONE-TIME-PASSWORD>

Note this password – it’s shown only once. (If you’d rather set a fixed password, you can store a STALWART_RECOVERY_ADMIN=admin:YOUR_PASSWORD under environment: in the compose.yaml.)

Step 4: Log in and run through the setup wizard

Open the web interface in the browser: http://YOUR_SERVER_IP:8080/admin. You land on the login. Log in as user admin with the one-time password from step 3 – the input is done in two steps (first username, then password):

After logging in, the setup wizard greets you. In the first step you set the server identity:

• Server Hostname: mail.YOUR_DOMAIN – the FQDN from your A record.
• Default Email Domain: YOUR_DOMAIN – your mail domain.
• Automatically Obtain TLS Certificate – leave enabled; Stalwart fetches the Let’s Encrypt certificate itself. For that, port 443 must be reachable from outside: Stalwart uses the TLS-ALPN-01 challenge over 443 by default, it doesn’t need port 80 for it.
• Generate Email Signing Keys – leave enabled; that generates your DKIM keys right away.

Click through the further steps of the wizard:

• Storage: the default RocksDB is an embedded key-value store and perfect for single-server setups – no external database server needed. Only for large, clustered installations do you reach for PostgreSQL or similar.
• Directory: the internal directory manages accounts and passwords directly in Stalwart. Whoever already runs a central LDAP/Active Directory can connect it here instead – for getting started you stay with the internal directory.
• Logging: defines how verbosely Stalwart logs. Info is a good compromise in everyday use; on problems you briefly turn up to Debug.
• DNS: for the start, manual management is enough – Stalwart shows you the records to create later under the respective domain.

At the end, Stalwart generates your permanent administrator account and shows its password a single time – write it down immediately. From now on the bootstrap mode is over and port 8080 is no longer open for setup; you reach the console in future via HTTPS.

Step 5: Create a domain and first mailbox

After the setup you’re in the management console. Via the left navigation you reach Directory → Domains and Directory → Accounts. If needed, create further domains and then your first mailbox:

Via Create account you create a mailbox – email address, display name and a strong password (password manager!). This account can then log in via IMAP/JMAP and SMTP:

Step 6: Set it up in a mail program

Enter the new account in your mail program. Stalwart supports autodiscovery, so usually the email address and password are enough. Manually you use:

IMAP:        mail.YOUR_DOMAIN, port 993, SSL/TLS
SMTP:        mail.YOUR_DOMAIN, port 587, STARTTLS
User:        the full email address

Besides the tried-and-true IMAP, Stalwart also speaks JMAP – a modern, JSON-based protocol designed for today’s networks. JMAP transfers only real changes instead of re-syncing whole folders, gets by with a single connection and is thus noticeably more sparing with battery and data – especially on the phone. If your mail client supports JMAP (e.g. the Thunderbird family in newer versions), you benefit directly; otherwise you stay with IMAP, which works just the same.

A mail from you to yourself should land in the inbox immediately – that proves that local delivery, IMAP and SMTP are in place. The acid test, though, is sending to the outside and receiving from the outside, and there deliverability decides.

Step 7: Spam filter and Sieve rules

A big advantage of Stalwart: the spam and phishing filter is already built in and active – you don’t have to run and maintain a separate Rspamd container. It rates incoming mails based on numerous features (reputation, SPF/DKIM/DMARC result, content heuristics) and marks or blocks suspicious ones. In the console under Settings → Spam Filter you can adjust the sensitivity and put senders on allow or block lists.

For your own rules on incoming and outgoing mail, Stalwart supports Sieve – the standardized filter language. With it you sort e.g. newsletters automatically into a folder or forward certain senders. You manage Sieve scripts server-side (via ManageSieve on port 4190) or directly in the web interface, so the rules take effect independent of the mail program – even when your computer is off.

When things go wrong

Maintenance & backups

Updates. Stalwart is a single container – an update is correspondingly simple:

cd /opt/stalwart
docker compose pull && docker compose up -d

Before bigger jumps, read the release notes on GitHub; stay on a specific version tag (like v0.16.14 here) instead of latest so updates remain reproducible.

Backups. All data – messages, accounts, configuration and the DKIM keys – lives in the stalwart_data volume. Back up this volume regularly away from the server, cleanest encrypted with Restic. Because Stalwart writes the data during operation, you back up most consistently by briefly stopping the container (docker compose stop), backing up the volume and starting again. The DKIM keys are especially important: if they’re lost, your signatures break after a restore until you reset the DNS records. A backup you’ve never restored is just a hopeful guess – test the restoration once on a test system.

Keep an eye on reputation. Occasionally check whether your server IP has landed on a block list, and take a look at the Stalwart console under Observability. A compromised mailbox that sends spam quickly ruins the reputation of your entire domain.

What are we building?

By the end, a complete mail server stack runs on your server, reachable as webmail at https://mail.YOUR_DOMAIN with a valid Let’s Encrypt certificate. Included are:

• Postfix as the SMTP server (send/receive),
• Dovecot for IMAP/POP3 (retrieval by mail programs),
• Rspamd as a modern spam and signature filter,
• SOGo as webmail including calendar and contacts (CalDAV/CardDAV),
• an admin interface to create domains, mailboxes and aliases.

The whole thing comes as mailcow-dockerized – a ready-bundled Compose project of 18 containers that makes the notoriously complicated mail server setup manageable. We build on Debian 13 with Docker 29.6 and Compose v5.3; mailcow is a rolling release maintained through monthly tags (you update via update.sh, there’s no classic version number). We tested against the 2026-07b state with Postfix 3.10.12, Dovecot 2.3.21.1, Rspamd 4.1.4 and SOGo 5.12.10.

Prerequisites

• A dedicated server with Debian 13 on which Docker is installed and that is only for mailcow (ports 80/443 and the mail ports free).
• At least 6 GB RAM – the spam filter (Rspamd) and the optional virus scanner (ClamAV) need room. With less it gets sluggish or ClamAV has to go.
• A domain whose DNS you control yourself. Without matching records (especially MX and reverse DNS), no other mail server accepts your mail.
• Outbound port 25 must be open. Many providers block it by default against spam – at netcup you enable it via a support ticket. Without an open port 25 you can deliver no mail to other servers.
• A PTR/reverse-DNS entry for the server IP, which you set in the provider panel (at netcup in the SCP). It must point to mail.YOUR_DOMAIN.

Mailcow is RAM-hungry, so we recommend at least the VPS 2000. What your specific need is, the server calculator estimates for you.

Step by step

Step 1: Create the DNS records

Before you install anything, set up the DNS entries – they need time to propagate, and mailcow fetches the TLS certificate for the hostname at startup. At your DNS provider (see connecting a domain to your server), create these entries. YOUR_DOMAIN is your mail domain (e.g. example.com), YOUR_SERVER_IPV4 the server’s IPv4 address:

mail.YOUR_DOMAIN.   A      YOUR_SERVER_IPV4
mail.YOUR_DOMAIN.   AAAA   YOUR_SERVER_IPV6      (if you use IPv6)
YOUR_DOMAIN.        MX     10 mail.YOUR_DOMAIN.

The MX record tells other mail servers: “Mail for @YOUR_DOMAIN is accepted by mail.YOUR_DOMAIN.” The hostname mail.YOUR_DOMAIN is the FQDN of the mail server – not to be confused with the mail domain itself. The further records for deliverability (SPF, DKIM, DMARC) and the PTR entry we cover in detail in the follow-up tutorial on deliverability; the PTR entry should be set already now, though, because many servers otherwise don’t accept at all.

Step 2: Install prerequisites on the server

Log in via SSH to the hardened server. Mailcow’s config generator needs git and jq besides Docker – the latter is easily forgotten, and the generator otherwise aborts with Cannot find command 'jq'. Install both:

sudo apt update && sudo apt install -y git jq

Check that Docker and the Compose plugin are running:

docker --version && docker compose version

You should see two version lines – for us Docker version 29.6.1 and Docker Compose version v5.3.1. Mailcow requires at least Docker 24; below that the config generator aborts. If something’s missing, catch up on the Docker setup before continuing.

Step 3: Clone and configure Mailcow

Mailcow is delivered as a Git repository and not maintained via a single image tag. Clone it to /opt and change into it. The umask 0022 is important so the generated files get the right permissions:

sudo su
umask 0022
cd /opt
git clone https://github.com/mailcow/mailcow-dockerized
cd mailcow-dockerized

Now you generate the central configuration file mailcow.conf with the interactive generator:

./generate_config.sh

It first checks whether your server’s IP is on the Spamhaus bad ASN list – a useful early warning, because hardly any mail server accepts post from some networks:

Detecting if your IP is listed on Spamhaus Bad ASN List...
Check completed! Your IP is clean

Then it asks you these questions in turn:

• Mail server hostname (FQDN): Enter mail.YOUR_DOMAIN here – the server’s hostname, not your mail domain. The value must match the A record from step 1.
• Timezone: usually already correctly pre-filled (e.g. Europe/Berlin) – confirm with Enter.
• Choose the Branch with it’s number [1/2/3]: Choose 1 for the master branch – that’s the stable, recommended state. 2 is nightly (testing), 3 the deprecated legacy branch.

/etc/docker/daemon.json not found. Create it with IPv6 settings? [Y/n]

Afterwards take a look at the generated mailcow.conf. The most important values are at the top:

grep -E "^(MAILCOW_HOSTNAME|TZ|HTTP_PORT|HTTPS_PORT|SKIP_CLAMD|ENABLE_IPV6)=" mailcow.conf

On our test server it looked like this – SKIP_CLAMD=n means “ClamAV is running”:

MAILCOW_HOSTNAME=mail.YOUR_DOMAIN
HTTP_PORT=80
HTTPS_PORT=443
TZ=Europe/Berlin
SKIP_CLAMD=n
ENABLE_IPV6=true

The file also contains all port assignments. In the standard configuration mailcow claims these host ports:

25    SMTP     (server-to-server delivery)
465   SMTPS    (send with implicit TLS)
587   Submission (send by mail programs, STARTTLS)
143   IMAP  /  993 IMAPS   (retrieval by mail programs)
110   POP3  /  995 POP3S
4190  Sieve    (server-side filter rules)
80    HTTP  /  443 HTTPS   (webmail + admin + ACME)

These ports must be free on the host – hence the dedicated server. If a reverse proxy already runs on 80/443 there, mailcow collides with it.

Step 4: Open the firewall

Your UFW firewall must let the mail and web ports through. Besides SSH, you allow:

sudo ufw allow 25/tcp
sudo ufw allow 80,443/tcp
sudo ufw allow 465,587/tcp
sudo ufw allow 143,993/tcp
sudo ufw allow 110,995/tcp
sudo ufw allow 4190/tcp

If you additionally use the netcup firewall in the SCP, allow the same ports there too – otherwise the perimeter firewall blocks the traffic before it reaches the server.

Step 5: Start the stack

Now you download the images and start the stack. Expect about 4.5 GB on disk – the stack consists of 18 services, the biggest being SOGo, Dovecot and Postfix:

docker compose pull
docker compose up -d

The first boot takes a few minutes – the database, search index and the individual services initialize. Watch the progress with:

docker compose ps

The STATUS column shows Up … for every service; the containers with their own health check (such as unbound-mailcow and clamd-mailcow) additionally report (healthy). During this time, mailcow fetches the Let’s Encrypt certificate for mail.YOUR_DOMAIN in the background via its built-in ACME client. For that, the A record and port 80 must be reachable from outside – if that’s not the case, the acme-mailcow container stays in a retry loop and you see it in its logs (docker compose logs acme-mailcow).

Step 6: First login to the admin interface

Open https://mail.YOUR_DOMAIN in the browser. You land in the mailcow UI. Log in with the default credentials:

User:      admin
Password:  moohoo

If the form shows “Sign in as user”, click “Sign in as admin” at the bottom – the login form on the home page otherwise logs you in as a mailbox user, not as an administrator.

After logging in you land in the mailcow dashboard with the overview of your services:

Step 7: Create a mail domain and first mailbox

In mailcow you separate domain (e.g. example.com) and mailbox (e.g. contact@example.com).

Via E-Mail → Configuration in the top navigation bar you manage domains and mailboxes in separate tabs:

1. On the Domains tab, click Add domain and enter your domain YOUR_DOMAIN. The default values (mailbox and alias quotas) are fine for the start. Save with “Add domain and restart SOGo” at the bottom – not with “Add domain only”. Why, see the box below.

   

2. Switch to the Mailboxes tab and click Add mailbox – username, domain, full name and a strong password (password manager!). This mailbox can then log in to the webmail and via IMAP/SMTP.

   

After creating the domain, mailcow shows you the DKIM key and the recommended DNS records under the domain entry. You need those for deliverability – more on that shortly.

Step 8: Test the webmail

Open https://mail.YOUR_DOMAIN/SOGo/ (or click Apps → Webmail at the top right in the mailcow UI). If you aren’t signed in yet, you first land on the mailcow “User Login” mask – log in there with your full mail address and the mailbox password and you are passed straight through to the SOGo webmailer with inbox, calendar and contacts. A test mail from you to yourself should be in the inbox immediately – that proves that local delivery, IMAP and webmail work.

The real acid test, however, is sending to the outside and receiving from the outside – and that’s exactly where it’s decided whether your mails land in the recipient’s inbox or spam folder. That depends on SPF, DKIM, DMARC and the PTR entry and is substantial enough for its own recipe.

When things go wrong

Maintenance & backups

A mail server lives off maintenance – plan it firmly.

Updates. Mailcow brings its own update script. Run it regularly (about monthly); it updates the Compose file and all images to the latest state:

cd /opt/mailcow-dockerized
sudo ./update.sh

The script automatically makes a backup of the configuration before the update and restarts the stack. Read the release notes shown – on bigger jumps, manual steps are occasionally listed there.

Backups. Your mails, the database and the crypto keys (DKIM!) live in Docker volumes. Mailcow brings a ready-made backup script for this:

cd /opt/mailcow-dockerized/helper-scripts
sudo BACKUP_LOCATION=/opt/mailcow-backups ./backup_and_restore.sh backup all

Then back up the target directory away from the server – cleanest encrypted with Restic. Especially important are the DKIM keys: if they’re lost, your signatures break after a restore until you reset the DNS records. A backup you’ve never restored is just a hopeful guess – test the restoration once on a test system.

Keep an eye on reputation. Occasionally check whether your server IP has landed on a block list (e.g. via one of the common block-list checkers) and take a look at the Rspamd dashboard in the mailcow UI now and then. A hacked or misconfigured mailbox that sends spam quickly ruins the reputation of your entire domain.