What Is mailcow and What Does It Include?
mailcow is a Docker-based mail server suite that bundles the full stack you'd otherwise assemble by hand — Postfix for SMTP, Dovecot for IMAP/POP3, SOGo for webmail and groupware, Rspamd for spam filtering, plus a web admin UI — and ships it as a set of coordinated containers. It fits self-hosters who want a complete, working mail system on their own hardware without wiring each component together, and who can supply a dedicated host, Docker with Compose, a domain, and correct DNS/MX records. If you'd rather not run and patch a mail server yourself, a hosted provider is the more sensible choice.
What's inside the suite
mailcow's value is that these pieces are pre-integrated and versioned together, so you don't have to reconcile their configs yourself:
| Component | Role |
|---|---|
| Postfix | SMTP — sending and receiving mail |
| Dovecot | IMAP/POP3 — mailbox storage and access |
| SOGo | Webmail and groupware (calendar, contacts) |
| Rspamd | Spam and threat filtering |
| Nginx | Web front end for the admin UI and webmail |
| Unbound | DNS resolver |
| Redis | Caching and internal coordination |
| ClamAV | Antivirus scanning |
The project also references tinc for networking between instances. The web admin UI is where you manage domains, mailboxes, aliases, and filtering — the operational surface most users interact with day to day.
What it's actually good at
- One deployable stack. SMTP/IMAP, webmail, groupware, spam filtering, and administration come as a unit rather than as a checklist of separate installs.
- Container-based updates. Releases are published as versioned updates you apply to the running stack, with changelogs describing what changed.
- A real admin UI. Domain, mailbox, and alias management happen in the browser instead of by editing config files.
What you need before it makes sense
- A dedicated host — mail servers want a stable, known IP.
- Docker plus Compose installed and working.
- A domain you control, with correct DNS and MX records pointing at the host. Getting this wrong is the most common reason mail silently fails to arrive or gets rejected.
- Willingness to apply updates, including security ones, on an ongoing basis.
How it compares to the alternatives
- Versus building your own Postfix/Dovecot stack: you trade full control over every config file for a maintained, integrated bundle. mailcow is faster to a working state; a hand-built stack is more flexible if you have unusual requirements.
- Versus hosted mail: self-hosting gives you control over data and configuration, but you own deliverability, DNS, patching, and uptime. Hosted mail removes that operational load.
Where to follow releases and upgrades
Release notes, changelogs, and upgrade guidance live on mailcow.email. The blog carries dated update posts — for example, the September 2026 update covering Unbound 1.26.1, SOGo 5.12.11, and Redis 7.4.11, and the August 2026 revision bumping Redis, SOGo, and ClamAV while addressing security issues in those components. There's also a dedicated upgrade tag and upgrade guides (such as Debian 12 to Debian 13) for major version transitions.
A few things worth knowing from the project's own posts:
- Updates are frequently security-driven and the project explicitly recommends applying them — the March 2026 revision and the May 2026 revision both fix CVEs in bundled components.
- Behavior changes do land in updates: the January 2026 release introduced limited EAS/DAV access and restricted alias sending, and a 2026 update introduced forced 2FA.
- The team changes over time — a maintainer announced departure effective May 2026 — so treat the blog as the authoritative source for current state rather than any single snapshot.
If you're evaluating mailcow, the practical test is whether you can meet the host, Docker, and DNS prerequisites and commit to applying updates. If yes, it gets you to a functioning mail server with far less assembly than a manual stack. If not, that's the signal to look at hosted mail instead.