Self-hosted email in 2026: revisit Stalwart, mailcow and Mailu before you run another mail server

Every few years, an Indian company with a few hundred people asks the same question about email. The hosted suite renewal has come in higher than last year, or the old mail server set up by a contractor in 2017 is running on an operating system that no longer gets updates, or invoices sent from the ERP have started landing in spam. Somebody says, “Let us just run our own mail server, it is only Postfix”, somebody else says, “Nobody runs their own mail any more”, and a third person has seen a new Rust mail server with a 1.0 release. Two weeks later there is a half-configured server in the data centre and nobody is sure whether it is safe to switch the MX record.

This post is written for the moment before that switch. A mail server is a set of services: it receives mail over SMTP, accepts mail from your users, stores and filters it, lets people read it, and sends mail to providers who judge you by your DNS records, IP address and past behaviour. The software decides how many moving parts you own, how backups and upgrades work, and how much RAM you need. It does not decide whether Gmail and Outlook accept your mail. That part is yours either way.

We revisit three popular open-source options in 2026: Stalwart (a single Rust server that speaks every mail and collaboration protocol itself), mailcow (a Docker Compose bundle of Postfix, Dovecot, Rspamd, SOGo and friends, with a web interface on top) and Mailu (a smaller Docker bundle of Postfix, Dovecot and Rspamd with an admin interface, under the MIT licence). We also look briefly at docker-mailserver, mox and maddy, as context. The aim is not to crown a winner but to see what each asks of you over five years.

A few pieces of news set the scene. Stalwart released version 1.0.0 on 26 October 2026, followed by 1.0.1 on 28 October. The release notes are clear that 1.0 has a new database layout and that existing 0.16 deployments cannot be upgraded in place; a separate migration tool copies the data into a new store. mailcow keeps its monthly rhythm: the 2026-10 release on 21 October 2026 was a security update with PHP 8.2.35, SOGo 5.12.12 and nginx 1.30.6. Mailu is still on its 2024.06 stable line, but it is far from quiet: it shipped six patch releases between 12 and 23 October 2026, the latest being 2024.06.67, which hardened the PHP runtime used by its webmail.

This post stays with servers that hold mailboxes. If you only need to send application mail, a relay or a transactional mail service may be simpler, and we touch on that below. For the pieces around a mail server, see TLS certificate automation in 2026, DNS servers in 2026 and backups in 2026. If you want single sign-on for mail clients, Keycloak and its alternatives is the better starting point.

A scenario to keep us honest

We will use one invented company through the post. Morar Agro Implements is an invented example, not a real business. It is a Gwalior company that makes tractor trailers, seed drills and rotavators, and sells them through about 140 dealers across Madhya Pradesh, Rajasthan and Uttar Pradesh. The company has about 260 people, of whom about 180 need a mailbox. The IT team has three people, led by Farhan.

What they run today:

  • One virtual machine on a rented server in a Noida data centre, set up in 2017 by a contractor who has since left. It runs Postfix and Dovecot on an operating system that reached end of life, with SpamAssassin, a webmail that nobody has updated, and about 900 GB of mail in Maildir folders.
  • About 60 people in sales and on the shop floor use mail only on phones. Managers want shared calendars, which the server does not offer.
  • The ERP sends about 6,000 messages a day at month end: invoices, dispatch notes and payment reminders to dealers and farmers’ cooperatives. It sends them through the same server, from the same domain that people use.

What triggered the review: in September, dealers using Outlook.com addresses started getting nothing, and the ERP logs showed rejections with the code 550 5.7.515. Around the same time, a Gmail-using cooperative said that every Morar invoice went to spam. The domain had an SPF record but no DKIM signing and no DMARC record, and the server’s IP address had no matching reverse DNS name. A hosted suite quote came in high, and a young engineer proposed Stalwart because “it is one binary and it just went 1.0”.

Farhan’s questions: should we keep running our own mail at all, and if yes, which server; what will it cost us in RAM, disk and hours; how do we fix delivery to Gmail and Outlook; how do we back it up and upgrade it; and can three of us own this for five years?

The short version

  • Deliverability is mostly DNS and behaviour, not software. Every server here can sign DKIM, check SPF and publish DMARC. Whether your mail is accepted depends on a static IP with matching reverse DNS, aligned SPF and DKIM, a DMARC record, TLS, low complaint rates and not sending bulk mail from the same place as people mail. Gmail has required these since February 2024 and Outlook.com since May 2025 for large senders.
  • Stalwart is one Rust program that implements SMTP, IMAP, JMAP, POP3, CalDAV, CardDAV and WebDAV, with its own spam filter, ACME client and storage layer (RocksDB by default, or PostgreSQL, MySQL, SQLite or FoundationDB). Fewest moving parts, AGPL-3.0 with a paid Enterprise edition, and the newest: 1.0 came on 26 October 2026 with a new data layout that 0.16 users must migrate to.
  • mailcow is the most complete groupware bundle on the classic stack: Postfix, Dovecot, Rspamd, SOGo webmail with calendars and ActiveSync, ClamAV, MariaDB, Redis and more, as about eighteen containers, under GPL-3.0. It releases monthly; the price is weight, at least 6 GiB of RAM plus swap.
  • Mailu is the lighter Docker bundle on the same classic stack, under the MIT licence, with an admin interface and a choice of webmails. It needs as little as 1 GB of RAM without antivirus. It has no built-in calendars, its stable line is still 2024.06 with Dovecot held below 2.4, and its own setup page warns that it is “still not massively tested”.
  • Do not mix people mail and bulk mail. Send ERP and marketing mail from a subdomain, through a separate path, so that a bad month for invoices does not sink the CEO’s replies.
  • For Morar Agro Implements, our plan is: fix DNS and authentication on the old server this month, move ERP mail to a subdomain and a separate sending path, and then migrate mailboxes to mailcow on a fresh virtual machine with 16 GiB of RAM, because they want calendars and phone sync on a stack the team can search the internet about. Stalwart goes into a three-month pilot for the IT team’s own mailboxes, to be reconsidered after 1.0 has had a few patch releases. Mailu stays the option if they ever need a small, separate mail server for a subsidiary.

Where things stand on 1 November 2026

Stalwart

Stalwart is developed by Stalwart Labs. Its README describes it as an open-source mail and collaboration server with JMAP, IMAP4, POP3, SMTP, CalDAV, CardDAV and WebDAV support, written in Rust. It is dual licensed under AGPL-3.0 and the proprietary Stalwart Enterprise License v2 (SELv2).

The big news is 1.0. Version 1.0.0 was published on GitHub on 26 October 2026 and 1.0.1 on 28 October. The 1.0.0 notes say it has “multiple breaking changes and a new database layout”, so v0.16.x deployments cannot be upgraded in place. Points worth knowing:

  • Migration is a copy, not an upgrade. A separate stalwart-migrate tool copies settings and data from a 0.16 store into a new, empty 1.0 store. It runs repeatedly while 0.16 keeps serving users, and the only downtime is the final run. The source must first be on 0.16.27 (released 18 October 2026), and you need room for a second copy of the data store. OAuth tokens are not migrated, CalDAV and CardDAV clients fetch their data again, and the search index is rebuilt after start. IMAP UIDs and JMAP state are kept, so IMAP clients do not download mailboxes again. There is a rollback command that copies a 1.0 store back into a new 0.16 store.
  • Settings were renamed and restructured, and telemetry event identifiers were renumbered. In 1.0.1, the metrics exporters were replaced and metric names now follow OpenTelemetry and Prometheus conventions, so the notes say plainly that dashboards and alerts must be updated.
  • New in 1.0: indexing of PDF and Office attachments, a redesigned cache, a built-in in-memory store for single nodes, OAuth scopes and SSRF protection for outbound requests.
  • Development model change: the 1.0.0 notes say test suites are now kept in a private repository and new features are developed privately before release, while the source of every release stays public under AGPL-3.0. A blog post from 16 October 2026 explains the reasons. We come back to what this means in the licences section.

1.0.1 updates the bundled RocksDB to 11.8.1, fixes an aarch64 crash under concurrent writes, and fixes config.json (which holds data store credentials) being created readable by other local users. Details like these are why we suggest waiting for a few 1.0.x releases before moving production mailboxes.

mailcow

mailcow: dockerized is a community project under GPL-3.0, with its repository dating from December 2016. It is not a new mail server; it is a carefully assembled set of well-known ones, each in its own container, with a PHP web interface for administration and users.

Releases are named by month: 2026-10 is the October release, and fixes come as revisions such as 2026-09a. The documentation describes a monthly cycle for stable updates. Recent ones:

  • 2026-10 (21 October 2026): a security update with PHP 8.2.35 on Alpine 3.24, SOGo 5.12.12 and nginx 1.30.6, plus an updated user interface.
  • 2026-09a (6 October 2026): Rspamd 4.2.1 and postfix-tlspol 1.14.0.

The Compose file on the main branch today lists Postfix 3.10.12, Dovecot 2.3.21.1, Rspamd 4.2.1, SOGo 5.12.12, MariaDB 10.11, Redis 7.4.11, Unbound 1.26.1, ClamAV, nginx 1.30.6 and helper containers for ACME, a netfilter based blocker, a watchdog, a Docker API bridge, Oletools and a cron scheduler. Note that Dovecot here is still on the 2.3 line, while upstream Dovecot has been on 2.4 since January 2025.

Mailu

Mailu is a community project under the MIT licence. Its documentation says it started in late 2014 under the name Freeposte.io, maintained by the French non-profit TeDomum, and became a public project around late 2015. Its stated aim is a full-featured mail server with free software only, without “unrelated features often found in popular groupware”.

The current stable line is 2024.06. With that release the project changed its version scheme to Year.Month.Minor, to make clear that upgrades only go forward; downgrades are only possible between minor versions of the same line. The line still receives regular patch releases: 2024.06.65 (20 October 2026) brought Roundcube 1.6.20, and 2024.06.66 and 2024.06.67 (22 and 23 October) mitigated attack paths in the webmail’s PHP runtime. The Dovecot image is pinned to versions below 2.4, and the base image is Alpine 3.20. The project is responsive on fixes, but new features arrive slowly.

Around them

  • Postfix and Dovecot upstream: Postfix 3.11.0 came out on 5 March 2026 and the stable release is 3.11.7 (7 September 2026), with 3.10.14 as a legacy release. Dovecot 2.4.0 came in January 2025 and the latest tag is 2.4.5 (28 August 2026). Dovecot 2.4 changed its configuration format, which is one reason bundles move to it slowly.
  • docker-mailserver is a single-container Postfix and Dovecot setup configured by files and environment variables, under MIT. v16.0.0 came out on 30 August 2026 and v16.0.1 on 4 September. It suits teams who want no web interface at all.
  • mox (MIT, v0.0.17 on 19 August 2026) and maddy (GPL-3.0, 0.9.6 on 3 October 2026) are single Go binaries worth watching for small setups.

The first questions to ask

Before comparing servers, write down answers to these seven questions. They decide more than any feature list.

  1. Do you need to host mailboxes at all, or only send? Application mail and mailboxes have different needs. Many teams only need a reliable relay.
  2. How many mailboxes and how much stored mail? 900 GB is a different backup problem from 20 GB.
  3. Do people need calendars, contacts and phone sync, or only mail? This is the biggest difference between the three.
  4. Where will it run, and can you get port 25, a static IP and reverse DNS there? Many cloud providers block outbound port 25 by default; home and office broadband lines are often on lists of dynamic addresses.
  5. Who signs in, and how? Local passwords, LDAP or Active Directory, or OpenID Connect.
  6. What does your team already know? Postfix logs, or one binary with a web console?
  7. How will you back it up, restore one mailbox, and upgrade without losing mail? If the answer is “we will take a VM snapshot”, read the operations section first.

How each one works

Email in one minute

When a dealer mails Morar, the dealer’s server looks up Morar’s MX record and connects on port 25. The receiving server checks blocklists, SPF (is this IP allowed to send for the domain), DKIM (was the message signed and unchanged) and DMARC (do they align with the From address, and what to do if not), runs spam and virus filters, and stores the message for IMAP, JMAP, webmail or phone access.

Outbound is the mirror image: users submit on port 587 or 465, the server signs with DKIM, queues the message and delivers it to the recipient’s MX on port 25, retrying when told to try later.

Classic setups give each job to a separate program (Postfix, Dovecot, Rspamd, ClamAV, a PHP webmail, a user database). mailcow and Mailu are built that way; Stalwart does it all in one process.

Stalwart: one program, many protocols

Stalwart implements SMTP (inbound and outbound with queues), IMAP4rev2, POP3, JMAP, ManageSieve, CalDAV, CardDAV and WebDAV itself, in Rust. It has a built-in spam filter with rules, a statistical classifier, DNS blocklists, greylisting and phishing checks. It signs and verifies DKIM, checks SPF, DMARC and ARC, supports DANE, MTA-STS and SMTP TLS reporting, and can obtain certificates with ACME. It can manage DNS records with supported DNS providers and rotate DKIM keys.

Data is split into stores:

  • Data store for metadata and indexes: RocksDB by default for a single node, or PostgreSQL, MySQL, SQLite or FoundationDB.
  • Blob store for message bodies and files: by default inside the data store, or a file system, S3 compatible storage or Azure Blob Storage.
  • Search store: built in, or Meilisearch, Elasticsearch, OpenSearch, PostgreSQL or MySQL.
  • In-memory store for rate limits and caches: built in for a single node, or Redis.

Only one process can open a RocksDB directory, so a cluster uses PostgreSQL, MySQL or FoundationDB, with nodes coordinating peer to peer or through Kafka, NATS or Redis. Most configuration lives in the data store; a small config.json only points to it.

Fewer things to patch, but one codebase owns everything, so SMTP, IMAP and calendar fixes arrive together.

mailcow: the classic stack, assembled and wrapped

mailcow runs each component in its own container on one Docker host, wired together by Docker Compose:

  • Postfix for SMTP, with postscreen in front and an MTA-STS and DANE policy helper.
  • Dovecot for IMAP, POP3, ManageSieve and storage, with full-text search.
  • Rspamd for spam filtering, DKIM signing and DMARC, with ClamAV and Oletools for attachments.
  • SOGo for webmail, calendars, contacts and Exchange ActiveSync for phones.
  • MariaDB for users and settings, Redis for Rspamd and caches, Unbound as a local validating DNS resolver, nginx in front, and PHP-FPM for the admin interface.
  • Helpers: an ACME client, a netfilter container that blocks brute-force sources, a watchdog that checks and restarts services, and a scheduler.

Each piece is a mature project with years of answers on the internet. mailcow’s job is to pick versions and keep the bundle coherent; yours is to accept the bundle largely as it is, since local changes can conflict with updates.

Mailu: the classic stack, kept small

Mailu also runs Postfix, Dovecot and Rspamd in containers, but keeps the set smaller. A front container (nginx) routes all HTTP and mail traffic and handles TLS, an admin container in Python offers the web interface and an API, and you choose optional pieces when you generate the configuration: antivirus, webmail (Roundcube or SnappyMail), WebDAV for contacts and calendars through a separate small server, and fetching mail from other accounts. Users and settings live in SQLite by default, or in PostgreSQL or MySQL.

A setup form on the Mailu website generates the docker-compose.yml and mailu.env files for your choices, so the first install is fast and the configuration easy to read.

Deliverability: the part no server fixes for you

This section matters more than the choice of server. Every one of the three can send mail that Gmail and Outlook accept, and every one of them will send mail that they reject if the basics are wrong.

What the big mailbox providers now require

Google’s sender guidelines say that since 1 February 2024, anyone sending to Gmail accounts must:

  • Set up SPF or DKIM for the sending domain.
  • Have valid forward and reverse DNS (a PTR record) for the sending IP.
  • Use TLS when transmitting mail.
  • Keep the spam rate reported in Postmaster Tools below 0.3%.
  • Format messages according to RFC 5322 and not impersonate Gmail From addresses.

Senders of more than 5,000 messages a day to Gmail must also set up both SPF and DKIM, publish DMARC (a policy of none is accepted), align the From domain with SPF or DKIM, and support one-click unsubscribe for marketing mail.

Microsoft’s Outlook.com policy says that from 5 May 2025, domains sending more than 5,000 messages a day to Outlook.com, Hotmail and Live addresses must pass SPF and DKIM, publish DMARC at least at p=none, and align with the From domain. Non-compliant mail first went to Junk, and Microsoft now rejects it with the error 550 5.7.515, exactly the code our invented company saw. The same policy says connections from dynamic IP space may not be accepted and that servers must have valid reverse DNS.

A company of 260 people crosses 5,000 a day without noticing: the ERP’s month-end run alone does it.

The DNS records you need

  • MX pointing to a host name, which has an A (and if you use IPv6, an AAAA) record.
  • PTR (reverse DNS) for the sending IP, set by whoever owns the IP, matching the host name your server announces in its greeting. This is the record people forget, because you cannot set it in your own DNS zone.
  • SPF: a TXT record listing the servers allowed to send for the domain. Keep it short and end it with -all or ~all once you are sure the list is complete.
  • DKIM: a public key in DNS under a selector; the server signs outgoing mail with the private key. Rotate keys, and keep the old selector published for a while after rotation.
  • DMARC: a TXT record at _dmarc that states your policy and where to send reports. Start at p=none with reports, read them for a few weeks, then move to quarantine and reject.
  • MTA-STS and TLS-RPT: a policy that tells other servers to require TLS when sending to you, and an address for TLS failure reports. DANE (TLSA records) does the same job for domains signed with DNSSEC.

All three show the records to publish; Stalwart can also update them through supported DNS providers, and Mailu offers a zone file download.

Port 25 and IP reputation

You need inbound and outbound port 25 on a static address with clean reputation. AWS blocks outbound port 25 on EC2 by default and asks you to fill a request form per region, which can take up to 48 hours, and the same form sets reverse DNS. Google Cloud blocks outbound port 25 to external addresses and suggests ports 587 or 465 to a relay. Indian leased line providers can give a static IP, but you must ask them for the PTR record. Check the IP against public blocklists before building on it.

A common, honest compromise is to receive mail on your own server and send outbound through a smart host (a relay service, or your provider’s relay). All three servers support relaying outbound mail through another host. You lose a little control and gain a known reputation.

Separate people mail from machine mail

If a few hundred of 6,000 invoices bounce or are marked as spam, the domain’s reputation suffers and the managing director’s next reply goes to spam too. Send machine mail from a subdomain such as billing.example.in, with its own SPF, DKIM and DMARC, through a separate path. This one change often fixes more than a new server would.

Security and accounts

Exposure

A mail server listens on ports 25, 465, 587, 993 and 443, and password guessing starts within hours.

  • Stalwart has auto-banning, rate limits and IP or ASN blocking. Without a configuration file it starts in bootstrap mode with a plain HTTP setup listener (port 8080 by default) on all interfaces and no protection against password guessing; the documentation says it must not be reachable from the internet, and our drill confirmed the binding. A leftover STALWART_RECOVERY_ADMIN variable acts as a full-access credential, so remove it after use.
  • mailcow includes a netfilter container that bans IPs after failed logins. Its documentation warns that because services run in Docker, INPUT firewall rules on the host do not restrict access; you must use the DOCKER-USER chain.
  • Mailu rate-limits authentication in its front container and supports authentication tokens that it recommends for mail clients instead of user passwords; a setting can make tokens mandatory.

Webmail is the soft spot

Many recent security fixes in these bundles have been in the web parts. mailcow’s admin interface is PHP, and Mailu ships Roundcube or SnappyMail, both PHP. The October 2026 security releases from both projects were about PHP. Patch webmail within days, keep admin interfaces behind a VPN, and ask whether people need webmail at all. Stalwart’s web interface has no PHP.

Sign-in

  • Stalwart has internal, LDAP, SQL and OIDC directories, TOTP, app passwords and OAuth for clients that support it.
  • mailcow supports TOTP and WebAuthn for its web interface, app passwords, and identity provider integration with LDAP, Keycloak or a generic OIDC provider.
  • Mailu has its own user database, authentication tokens, and header authentication from an external proxy for web logins.

Phones will mostly use passwords, so give users app passwords and protect the web sign-in with two factors.

Performance and how to read benchmarks

What vendors publish

  • Stalwart’s site and blog talk about speed and scale, including stress tests on many cloud servers. These are the vendor’s own runs.
  • mailcow publishes sizing guidance rather than benchmarks: at least 6 GiB of RAM plus 1 GiB of swap by default, 8 GiB for about 5 to 10 users, and about 16 GiB for a company with 15 phones on ActiveSync and 50 concurrent IMAP connections. It explains that a single SOGo worker can use about 350 MiB before it is recycled, and a default setup starts 20 workers. ClamAV and full-text search are the other large users, and both can be turned off.
  • Mailu’s requirements are 3 GB of RAM and 1 GB of swap with ClamAV, or 1 GB and 1 GB of swap without it.

We do not repeat any throughput numbers here as a verdict. For a company of a few hundred people, raw SMTP throughput is almost never the limit. Memory, disk I/O during search indexing, and phone sync are.

Questions to ask

Was the test about SMTP acceptance, local delivery, IMAP or search? Were spam filtering, antivirus and attachment indexing on? How large were the mailboxes, how many phones were syncing, and where did the data live?

What to measure yourself

Peak memory over a month-end week, disk growth per month including indexes, time to search an attachment in a large mailbox, queue delay during the ERP run, and restore time for one mailbox and for the whole server.

Licences

Stalwart: AGPL-3.0 or Stalwart Enterprise License v2

The Community edition is AGPL-3.0. If you modify it and offer it as a network service, you must share your changes with its users; running it unmodified for your own staff raises no such duty in practice. The Enterprise edition is a per-mailbox subscription with extra features. Its comparison page lists, among Enterprise-only features: multi-tenancy, per-domain directories, branding, account archiving and undelete, the AI spam classifier, SCIM provisioning, LDAP failover, read replicas, sharded blob and in-memory stores, live telemetry, message delivery history, the dashboard and metric alerts. Metrics are marked “limited” in the Community edition. The page says about 85% of features are free and promises not to move existing ones behind the paywall.

A company like Morar does not need Enterprise features to run mail. Also note that from 1.0 the test suites are private; the code stays AGPL, but outsiders see less of how it is tested.

mailcow: GPL-3.0

The mailcow code (scripts, configuration and web interface) is GPL-3.0. Each bundled component keeps its own licence: Postfix is under the IBM Public License or EPL 2.0, Dovecot under MIT and LGPL, Rspamd under Apache 2.0, SOGo under GPL and LGPL. There is no paid edition with extra features.

Mailu: MIT

Mailu’s own files are MIT, and the project states that all components are free software compatible with the MIT licence. There is no company and no paid edition; support is community only. The setup page suggests that people who want long-term professional support look at Poste.io instead.

Around them

docker-mailserver and mox are MIT; maddy is GPL-3.0.

Operations and day two

Sizing and hosting

  • Stalwart: one binary (about 128 MB for Linux x86_64) plus a data directory; RocksDB on local disk is simplest.
  • mailcow: one VM with Docker, not OpenVZ, LXC or a NAS; 20 GiB disk plus mail.
  • Mailu: one Docker host, or Kubernetes; the smallest footprint with ClamAV off.

Backups

  • Stalwart: the binary has export and import options that dump all store data to a directory, and the documentation has a backup and restore section. For RocksDB, do not copy the live directory; use the export or a snapshot taken with the server stopped. If you use PostgreSQL as the data store and S3 for blobs, back them up with their own tools, as in PostgreSQL backups in 2026.
  • mailcow: a helper script, backup_and_restore.sh, backs up components separately: vmail (the mail), crypt (the mail encryption key), redis, rspamd, postfix and mysql, or all of them. It supports threads, unattended runs and deleting old backups. Note the crypt component: mailcow encrypts mail at rest, and a backup of vmail without the key is useless.
  • Mailu: back up the /mailu directory (mail, data, DKIM keys, certificates and overrides) and, if used, the external database. The documentation has a page on migrating an instance.

For all three, copy backups off the machine and practise restores.

Upgrades

  • Stalwart: within a line, replace the binary or pull the image. Across 0.16 and 1.0, use stalwart-migrate as described above. Read the UPGRADING notes; the repository keeps one per version from 0.4 to 0.16.
  • mailcow: run ./update.sh. It shows changes with --check, can prefetch images, and records a git commit “Before update” so that you can roll back with git checkout and docker compose pull. There are stable, nightly and legacy branches.
  • Mailu: pull the images for your version and restart. Pin the full version (for example 2024.06.67), since the 2024.06 tag moves to each new patch.

Monitoring

  • Stalwart: logs and traces through OpenTelemetry, journald or files, metrics for Prometheus or OpenTelemetry, webhooks, and a health endpoint. Remember the metric names changed in 1.0.1.
  • mailcow: the watchdog container checks services and can alert by mail; Rspamd has its own web interface.
  • For all: queue length, delivery delays, bounce and deferral rates by destination, failed logins, certificate expiry, disk space, DMARC aggregate reports, and Google Postmaster Tools and Microsoft SNDS for your domain and IP. Uptime monitoring in 2026 covers simple SMTP and IMAP checks.

Side by side

Architecture

  • Stalwart: one Rust process for all protocols, pluggable stores.
  • mailcow: about eighteen containers around Postfix, Dovecot, Rspamd and SOGo on one Docker host.
  • Mailu: a smaller set of containers around Postfix, Dovecot and Rspamd, with a front proxy and an admin service.

Calendars, contacts and phone sync

  • Stalwart: CalDAV, CardDAV, WebDAV and JMAP built in. No Exchange ActiveSync.
  • mailcow: SOGo with calendars, contacts and Exchange ActiveSync.
  • Mailu: optional WebDAV server for contacts and calendars; no ActiveSync.

Webmail

  • Stalwart: a web interface for administration and account self-service; check the current docs before assuming a full webmail, and plan for desktop and phone clients.
  • mailcow: SOGo webmail.
  • Mailu: Roundcube or SnappyMail.

Storage and scaling

  • Stalwart: RocksDB on one node; PostgreSQL, MySQL or FoundationDB with S3 for clusters.
  • mailcow: one host; Maildir storage under Dovecot, MariaDB for metadata.
  • Mailu: one host with Compose, or Kubernetes; Maildir under Dovecot.

Minimum memory in the projects’ own guidance

  • Stalwart: no fixed figure; measure your own.
  • mailcow: 6 GiB plus 1 GiB swap, 8 GiB for 5 to 10 users, around 16 GiB with phones.
  • Mailu: 1 GB plus swap without antivirus, 3 GB plus swap with ClamAV.

Operational weight

  • Stalwart: lowest number of parts, but one codebase you must trust for everything and a young major version.
  • mailcow: highest number of parts, but each is mature and familiar, and the bundle is tested together.
  • Mailu: medium; fewer parts than mailcow, but less in the box and fewer maintainers.

A worked plan for Gwalior

Here is how we would approach Morar Agro Implements, month by month.

Month 1: fix delivery before touching the server.

  • Ask the data centre to set reverse DNS for the server’s IP to mail.morar.example, and make sure the server greets with that name.
  • Turn on DKIM signing on the existing Postfix (with OpenDKIM or Rspamd), publish the key, and correct SPF to list only the real senders.
  • Publish DMARC with p=none and an address for aggregate reports. Read the reports weekly.
  • Register with Google Postmaster Tools and Microsoft SNDS, and turn off the unpatched old webmail.

Month 2: separate machine mail.

  • Move ERP mail to a subdomain, billing.morar.example, with its own SPF, DKIM and DMARC.
  • Send it through a separate path: a transactional mail service, or a small dedicated relay on another IP. Add a one-click unsubscribe header to reminders that are not strictly transactional.

Month 3: build the new mailbox server.

  • A new VM with 16 GiB of RAM, 4 vCPUs and 2 TB of SSD on a supported Debian or Ubuntu, with static IP and reverse DNS. Install mailcow 2026-10 with ClamAV kept on, and plan memory for SOGo with about 60 phones on ActiveSync.
  • Set the firewall rules in the DOCKER-USER chain. Put the admin interface behind the company VPN; see mesh VPNs in 2026 for options.
  • Schedule backup_and_restore.sh nightly for all components to a separate disk, copy the result off-site with restic, and store the crypt key separately.

Month 4: migrate and cut over.

  • Use mailcow’s sync jobs (imapsync) to copy each mailbox from the old server while it keeps running, in batches by department.
  • Lower the MX TTL a week before, switch on a Saturday, keep the old server as a fallback for a few days, and run a final sync. Update SPF and DKIM, and after a month of clean DMARC reports move to p=quarantine.

Month 5 onwards: run it and test the alternative.

  • Run ./update.sh --check each month, read the notes, update in a maintenance window, and test webmail and phones after each update.
  • Restore one mailbox from backup every month and the whole server to a test VM every quarter.
  • In parallel, run a Stalwart 1.0.x pilot on a small VM for the IT team’s own mailboxes on a separate subdomain. In three months, decide whether its single binary and built-in calendars are worth a second migration.

What we did not choose and why.

  • Stalwart for all 180 mailboxes now: a promising design and the lightest to run, but 1.0 is days old, the data layout and settings have just changed, and the team has no experience with it. It also has no ActiveSync, which matters for 60 phone-only users on stock mail apps that prefer it. It stays the most likely candidate for a future move once 1.0 has settled.
  • Mailu: light and clean, but no ActiveSync, calendars only through a side server, Dovecot held on 2.3 and a stable line from 2024. For 180 mailboxes with calendar needs, mailcow’s bundle fits better.
  • A hosted suite: reasonable, and cheaper in staff time. Farhan should put the yearly cost of the team’s hours next to the renewal quote; if the numbers are close, hosted mail is the calmer option.

When not to adopt each

Do not adopt Stalwart if

  • You need Exchange ActiveSync for phones and cannot move users to IMAP, CalDAV and CardDAV.
  • You must migrate a 0.16 deployment this week; plan the stalwart-migrate runs and the second copy of the data first.
  • You want each protocol handled by a separately maintained, long-established project.
  • You need multi-tenancy, archiving or live telemetry and cannot pay for Enterprise.

Do not adopt mailcow if

  • You cannot give it at least 6 to 8 GiB of RAM, or you must run it in LXC or on a NAS.
  • You plan to customise the components heavily; local changes fight with updates.
  • You want to run it on Kubernetes; it is built around one Docker Compose host.
  • Nobody will apply the monthly updates.

Do not adopt Mailu if

  • You need calendars, contacts and phone sync as a first-class feature.
  • You need vendor support or a guaranteed release roadmap.
  • You want the newest Dovecot and features soon after upstream.
  • You run a critical mail service and cannot test every feature yourself, as its setup page advises.

Do not self-host mail at all if

  • You cannot get a static IP with reverse DNS and open port 25.
  • Nobody will read DMARC reports, bounce logs and blocklist alerts every week.
  • One person would carry it alone. Mail fails at night and on holidays.

A short history

  • 1998: Wietse Venema released Postfix (then also called VMailer and IBM Secure Mailer) as a safer alternative to Sendmail. 2002: Timo Sirainen released the first Dovecot.
  • 2014 to 2016: Mailu began as Freeposte.io in late 2014 and shipped 1.3, its first release under the Mailu name, in November 2016. The mailcow-dockerized repository was created in December 2016.
  • 2019: JMAP was standardised (RFC 8620 and RFC 8621) as a JSON and HTTP alternative to IMAP.
  • 2023: Mailu 2.0 in April; the combined Stalwart repository was created in March.
  • 2024 and 2025: Gmail’s sender rules (February 2024), Mailu 2024.06, Dovecot 2.4.0 (January 2025) and Outlook.com’s high-volume rules (May 2025).
  • 2026: Postfix 3.11 in March; Stalwart 1.0 on 26 October; PHP security updates from mailcow and Mailu in October.

Decision guide

You need mail, calendars and phone sync for 50 to 500 people on one server

Use mailcow, if you can give it the RAM. It is the most complete bundle on familiar components.

You want the fewest moving parts and modern protocols

Use Stalwart, starting with a single node on RocksDB, and plan for a careful pilot on 1.0.x before production. Choose PostgreSQL and S3 from the start if you might cluster later.

You need plain mail for a small team on a small machine

Use Mailu, with ClamAV off if memory is tight, or docker-mailserver if you prefer files to a web interface.

You only need to send application mail

Do not run a mailbox server. Use a relay or a transactional mail service from a subdomain, with SPF, DKIM and DMARC aligned.

Checklist

  • Decision written down: mailboxes, machine mail, or both, and why self-host at all.
  • Static IP with reverse DNS matching the server’s greeting name; IP checked on blocklists.
  • MX, SPF, DKIM, DMARC, MTA-STS and TLS-RPT records published and tested.
  • Machine mail moved to a subdomain and a separate sending path.
  • Firewall checked from outside, including the DOCKER-USER chain for Docker setups.
  • Setup and admin listeners not reachable from the internet; bootstrap and recovery credentials removed.
  • Two-factor sign-in for the web interface; app passwords or tokens for clients.
  • Webmail patched within days of a security release, or turned off.
  • Backups of mail, keys and settings off the machine; one mailbox and one full restore practised.
  • Versions pinned; update procedure and rollback written down.
  • Monitoring of queues, deferrals, failed logins, disk, certificates and DMARC reports.
  • Two named people who can run it, not one.

Common mistakes

  • Believing the new server will fix deliverability. Missing PTR, DKIM and DMARC records follow you to any software.
  • Sending ERP or marketing mail from the people domain. One bad batch hurts everyone’s mail.
  • Leaving setup or admin ports open. Stalwart’s bootstrap listener and any admin interface belong behind a firewall or VPN.
  • Writing host firewall rules that Docker ignores. For mailcow and Mailu, rules in INPUT do not protect published container ports.
  • Backing up mail without the encryption key. mailcow’s crypt key is part of the backup.
  • Jumping on a 1.0 the week it ships. Let the first patch releases arrive; Stalwart’s 1.0.1 already fixed a crash and a file permission issue.
  • Moving straight to DMARC p=reject. Read reports first; forgotten senders such as a scanner or a CRM will be rejected.

A small hands-on check

We ran a small, local drill on our box on 1 November 2026, around 6:22 PM IST. It used the Stalwart v1.0.1 release binary for Linux x86_64 from GitHub, started as an ordinary user inside an unprivileged network namespace that had only a private loopback interface and no route to the outside. No packages were installed and no system services were touched. We did not run mailcow or Mailu, since both need Docker and privileged ports, and we did not complete the setup wizard or send any mail. We started it with a missing configuration file, so it entered bootstrap mode, with the setup port set to 18080. What we saw:

  • It printed a banner on standard error with a temporary administrator, admin, and a random password, shown once. A log collector that keeps only standard output would miss it.
  • It logged “Server started in bootstrap mode” and opened a plain HTTP listener with no TLS. The socket list showed it bound to all addresses, not only loopback. In our namespace that meant only loopback, but on a normal host it would be every interface, which is why the documentation asks you to firewall this port.
  • It tried to download its web interface bundle from GitHub at start, failed because there was no network, and said that no bundle was available to serve for the admin and account pages. A server in a locked-down network needs a plan for that bundle.
  • It warned that the configured DNS resolver could not validate DNSSEC and that DANE had been disabled to avoid deferring mail. A real install needs a DNSSEC-validating resolver if you want DANE.
  • The health endpoints for live and ready both answered 200, and /admin returned a redirect.
  • The process used about 47 MB of resident memory in this state. A configured server with filtering and indexing will use much more; do not size from this number.
  • It wrote nothing to the data directory and stopped cleanly on SIGTERM.

The point is not speed: the first minutes of a new mail server already contain security decisions, and they are easier to make on a test machine. The notes and script are kept on our box.

Unlearn, re-learn

  • Unlearn “running mail is just installing Postfix”. Re-learn that the software is the easy part, and DNS, IP reputation and daily attention are the work.
  • Unlearn “Gmail and Outlook are unfair to small senders”. Re-learn that their rules are published, and that SPF, DKIM, DMARC, reverse DNS and TLS meet most of them.
  • Unlearn “one domain for everything”. Re-learn that separating machine mail from people mail protects both.
  • Unlearn “a single binary means simple operations”. Re-learn that Stalwart removes many moving parts, but its upgrades, settings and data layout still need the same care, as 1.0 shows.
  • Practise: take your domain today, check its MX, PTR, SPF, DKIM and DMARC records, send one message to a Gmail and one to an Outlook.com account, and read the authentication results in the headers. Then decide whether your problem is the server at all.

Sources

Stalwart

mailcow

Mailu

Around them

Deliverability and networks

comments powered by Disqus

Releted Posts

Virtualization platforms in 2026: revisit Proxmox VE, XCP-ng and Incus before you migrate another virtual machine

Most virtualization migrations in India over the last two years did not start with an architecture review. They started with a renewal quote.

Read more

Infrastructure monitoring in 2026: revisit Zabbix, Checkmk and Netdata before you add another host to your monitoring

In most Indian companies, monitoring starts with a person, not a tool. Somebody in the IT team logs in to the file server every morning, checks the disk, looks at the UPS panel, pings the branch router, and goes back to work.

Read more

Self-service BI in 2026: revisit Apache Superset, Metabase and Lightdash before you build another dashboard

Most companies do not decide to “adopt a BI tool”. They drift into one. An analyst installs something on a spare virtual machine to stop emailing Excel files.

Read more