Mailu: a full mail server assembled from Docker images, and what it costs you to run it
Insular email distribution - mail server as Docker images
At a glance
- What is it?
- Mailu packages SMTP, IMAP, webmail, antispam and an admin UI as a set of Docker images with a Compose-based setup. It suits operators who want to own their mail stack and are willing to run the surrounding infrastructure themselves.
- Who is it for?
- Adopt Mailu if you already run Docker Compose on a host you control, you are comfortable owning DNS, reverse DNS and certificates, and you want a mail stack with no proprietary components. Do not adopt it if you need a hosted service with a support contract, or if you cannot operate a mail server's networking and reputation yourself; Mailu automates configuration, not deliverability.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 30, 2026, and from our analysis. They are not legal advice.
Editorial analysis
What Mailu actually is, and who it is for
Mailu is described in its README as "a simple yet full-featured mail server as a set of Docker images." The unit of delivery is the image, not a package or a single binary. That single sentence explains most of the project's decisions: components are separated into containers, and the operator composes them rather than installing one monolith.
The stated audience is people who want a mail server that is "easily setup, easily maintained and full-featured" without shipping proprietary software or the unrelated features the README associates with popular groupware. That last clause is a positioning statement as much as a feature list. Mailu does not try to be a collaboration suite. It is mail: IMAP and IMAP+, SMTP and submission, webmail, administration, aliases, quotas and antispam.
The feature list spans standard mail (auto-configuration profiles for clients), user-level conveniences (auto-reply, auto-forward, fetched accounts, managesieve), admin functions (global admins, announcements, per-domain delegation), security (enforced TLS, DANE, MTA-STS, Letsencrypt, outgoing DKIM, an antivirus scanner, Snuffleupagus, malicious attachment blocking) and antispam (auto-learn, greylisting, DMARC and SPF, anti-spoofing). The README also lists full-text search of email attachments.
One detail matters for evaluation: the repository states that all components are free software and compatible with the MIT license, while the GitHub licence field reads NOASSERTION. Those two statements are not the same thing. If licence terms decide your adoption, read LICENSE.md and the per-component licences rather than the summary sentence.
This is infrastructure software for an operator, not a product for an end user. If nobody on your side can read a Compose file and debug a container, the feature list will not help you.
How the Docker image split shapes the deployment
The repository layout is the architecture. Top-level entries include core/, optional/, setup/, webmails/, docs/, scripts/, tests/ and design/. The naming is informative: core/ holds the components a working mail server needs, optional/ holds the ones you can add or leave out, setup/ holds the configuration path, and webmails/ holds the webmail front ends.
The README says the project provides "multiple Webmails and administration interface", which is why webmails/ is a directory rather than a single bundled client. Mailu is not opinionated about the webmail choice in the way a monolithic distribution would be.
Data flow follows the standard mail path, with each stage in its own container. Mail arrives over SMTP, passes through the antispam path (the README lists greylisting, auto-learn, DMARC and SPF and anti-spoofing), then delivery into IMAP storage. Users read mail through IMAP or a webmail container. Outgoing mail passes DKIM signing, and the README names Letsencrypt for certificates. The administration interface sits alongside these and manages domains, users, aliases, quotas and delegation.
The optional/ directory is the honest part of the design. Features such as the antivirus scanner and fetched accounts are not forced on every deployment. The cost is that the operator has to know which optional components are present, because a missing container is a missing capability, and the failure appears at runtime rather than at install time.
Because the pieces are separate images, upgrades are not one operation. Version skew between containers is possible, and the release history reflects that: the recent releases are 2024.06.58 (2026-08-12), 2024.06.57 (2026-07-26) and 2024.06.56 (2026-07-24). Patch releases arrive frequently on the same 2024.06 line, which suggests the maintenance model is incremental fixes on a stable series rather than constant major reworking. The last push to the repository was on 2026-09-16.
Installing Mailu and getting a first domain working
The README does not contain installation steps. It points to the project website at mailu.io for most of the documentation and offers a demo server at mailu.io/master/demo.html to try before setting up your own. The setup/ directory in the repository is where the configuration path lives, and the documentation on the website is the authoritative source for the exact commands for your release.
What can be said from the repository is the shape of the process. Configuration is generated rather than hand-written, which is what the setup/ directory exists for. The generated output is consumed by Docker Compose, and the resulting stack is the running mail server. Treat the generated configuration as the source of truth and keep it under version control; it is what you will diff when a release changes a default.
A minimal Compose file follows the pattern the project uses: named services, each built from a Mailu image, with persistent volumes for mail data and a reverse proxy in front for TLS termination. The service and image names below are illustrative of the structure, not copied from the README, so check the generated file from your own setup run before relying on any of it.
yaml services: imap: image: mailu/imap:2024.06.58 restart: always volumes: - "./data/mail:/mail" smtp: image: mailu/smtp:2024.06.58 restart: always ports: - "25:25" - "587:587"
Once the stack is up, the first real task is creating a domain and a user in the administration interface, then pointing an MX record at the host. Only after that does mail flow. The README's feature list mentions auto-configuration profiles for clients, which is what you use to configure a mail client against the new account without guessing server names and ports.
Expect the first successful inbound message to be the real milestone, not a running container. A mail server that accepts connections but fails SPF, DKIM or reverse DNS checks will look healthy in `docker compose ps` and still land in spam folders.
Where Mailu stops helping you
Mailu automates the software. It does not automate reputation, and the README does not claim otherwise. Deliverability depends on DNS records, reverse DNS on the sending IP, and the reputation of that IP, none of which a container can fix. A fresh VPS IP with no sending history is a common way to end up in spam folders no matter how correct the DKIM and SPF configuration is.
The project's own framing is a warning as much as a promise. "Easily maintained" is relative to running the same components by hand, not relative to a hosted mailbox. You are the operator of record: when the queue backs up, when a certificate renewal fails, when a container restarts into an inconsistent state, the project's issue tracker is not a support desk.
The licence situation is the second place where you have to do your own work. The README states all components are free software and compatible with the MIT license, and all specific configuration files, Dockerfiles and code are placed under the MIT license. The GitHub licence field for the repository reads NOASSERTION. If your organisation has a licence review process, the README sentence will not satisfy it. Read LICENSE.md and the component licences.
Finally, the README's own scope statement is a limitation for some buyers. Mailu deliberately does not ship "unrelated features often found in popular groupware". If you need calendars, shared documents or an integrated collaboration suite, you are looking at the wrong project, and no amount of optional/ components will change that.
Mailu against Docker Mailserver and Mailcow
The two comparisons people search for are Mailu versus Docker Mailserver and Mailu versus Mailcow, and the difference is in how much the project decides for you.
Docker Mailserver takes the opposite approach to component separation. It is a single container running multiple services, configured through environment variables. Mailu splits those services across images and generates configuration from a setup step. The trade-off is direct: a single container is simpler to start and simpler to reason about as one unit, while Mailu's split lets you replace or omit individual components and gives each service its own lifecycle. If you want the smallest possible moving surface, the single-container model wins. If you want to swap a webmail or drop an optional scanner, Mailu's layout is the one that accommodates it.
Mailcow is the comparison for operators who want more of the surrounding product: a broader management surface and a more integrated administrative experience. Mailu's README explicitly distances itself from that direction, promising mail rather than groupware features. That is a real difference in scope, not a difference in quality, and it should decide the choice more than any feature checklist.
The honest summary is that all three run the same underlying open source mail components. What differs is the packaging philosophy and how much of the operational surface the project tries to own. Mailu's answer is: the images and the configuration generator, and nothing beyond that.
Maintenance, upgrades and what to check before you commit
The release cadence is the strongest signal available. Three releases landed within roughly three weeks in mid-2026: 2024.06.56 on 2026-07-24, 2024.06.57 on 2026-07-26 and 2024.06.58 on 2026-08-12. All three sit on the 2024.06 series. That pattern points to a stable series receiving fixes rather than a project that reworks its structure every few months. The repository's last push was on 2026-09-16, and it is not archived.
Patch releases on a stable line are easier to consume, but they still require you to act. Because Mailu is a set of images, an upgrade means updating image references and recreating the affected containers, not upgrading one package. The pyproject.toml shows the project uses towncrier to generate CHANGELOG.md, with entries linking back to GitHub issues. That changelog is the place to look before upgrading, and the towncrier configuration means entries are assembled from issue references rather than written as a single narrative.
Upgrade cost is therefore mostly operational: read the changelog for the target version, update the image tags, recreate the stack, and verify that mail still flows in both directions. Budget time for the verification, not just the pull. A mail server that starts cleanly can still have a broken submission path or a certificate that did not renew.
On licensing, the repository states that all components are free software and compatible with the MIT license, and that configuration files, Dockerfiles and code are under the MIT license. The repository's licence field reads NOASSERTION. This is not legal advice: if the distinction matters to you, read LICENSE.md and the licences of the individual components, because the README sentence is a summary and the per-component terms are the binding ones.
Editorial conclusion
Adopt Mailu if you already run Docker Compose on a host you control, you are comfortable owning DNS, reverse DNS and certificates, and you want a mail stack with no proprietary components. Do not adopt it if you need a hosted service with a support contract, or if you cannot operate a mail server's networking and reputation yourself; Mailu automates configuration, not deliverability. Before committing, read the setup documentation at mailu.io for your release, confirm which optional images you actually need, and check the licence and the release notes for the version you install.
Frequently asked questions
Is Mailu free to use?
The README states that Mailu is free software "both as in free beer and as in free speech", that all components are free software and compatible with the MIT license, and that configuration files, Dockerfiles and code are placed under the MIT license. The repository's licence field reads NOASSERTION, so check LICENSE.md and the component licences if the exact terms matter to you.
How do I install Mailu?
The README does not include installation steps; it points to the project website at mailu.io for most of the documentation, and the repository has a setup/ directory that holds the configuration path. The README also offers a demo server at mailu.io/master/demo.html to try before setting up your own.
How do I set up Mailu?
Configuration is generated through the setup path in the repository's setup/ directory, and the resulting stack runs as Docker Compose services. The README directs you to mailu.io for the documentation that covers the exact steps for your release.
How does Mailu compare with Mailcow?
Mailu's README positions the project as a mail server that does not ship proprietary software or the unrelated features often found in popular groupware, while Mailcow is the comparison for operators who want a broader, more integrated management surface. The difference is scope rather than quality, and both run open source mail components underneath.
How does Mailu compare with Docker Mailserver?
Mailu ships as a set of Docker images with a generated configuration, so components such as webmail and optional scanners can be replaced or omitted individually. Docker Mailserver runs multiple services in a single container configured through environment variables, which is a smaller moving surface but a less granular one.
What alternatives to Mailu are there?
The two comparisons that come up most are Docker Mailserver, which runs the services in a single container configured by environment variables, and Mailcow, which offers a broader management surface. Mailu's own distinguishing choice is the split into core/ and optional/ images with a separate setup step.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/mailu-mailu)