Mailu packages mail delivery and web administration together
Mailu combines email protocols, webmail and a browser administration interface in a set of Docker images. Its README names per-domain delegation, aliases and quotas. That combination is useful when you need someone to administer mailboxes without editing every account through server configuration files.
The project deliberately focuses on email and avoids unrelated groupware features. I'd consider it for an organization that wants to operate its own domains and has a named mail administrator. Choosing it only because Docker is familiar would miss the harder decision. Someone still needs to own the domain's configuration and investigate mail that fails to arrive.
What happened when we ran it
Our sandbox installed Mailu commit 5ccc8ab in 30 seconds and built it in 9 seconds. The dependency record contained 35 entries and reported 37 MB on disk. The October 23, 2026 run used a recorded configuration of 3 CPUs, 8 GB RAM and image ghcr.io/astral-sh/uv:python3.12-bookworm. The image label does not establish the actual interpreter or operating-system version.
The test step failed after 6 seconds with exit 4. Pytest was loading tests/conftest.py when it imported create_app_from_config and models from the mailu package. That import reached core/admin/mailu/init.py, where import flask raised ModuleNotFoundError: No module named 'flask'. This is a failure during configuration loading; the supplied record gives no passing or failing assertion count.
The missing import is the diagnostic we have. The tail does not establish why Flask was absent or which dependency-management step should have supplied it. Installation and build success therefore did not produce a runnable suite in this sandbox. They also did not exercise the Docker mail service or establish that released mail delivery is broken.
Pip-audit reported 0 known vulnerabilities. That result applies to the Python audit in the supplied run, not to every component shipped in Mailu's container deployment. The lab gives no complete image-security assessment. Treat the audit as one bounded observation alongside the configuration-loading failure, rather than as clearance to put a mail server on the internet.
DNS and external delivery checks remain the operator's work
Mailu's setup guide requires a DNS hostname and a DNS name for receiving email. It then directs operators through DNS configuration and administrator steps for mail-authentication records. Docker images package the services; they cannot make those domain-level choices for you.
The same guide tells operators to send mail to an external service, verify SPF and DKIM there, and receive mail back. It also calls for inspecting service logs and checking for an open relay. Those checks answer questions our source build cannot: whether mail leaves through the intended route, whether another provider accepts its authentication and whether outside senders can reach a mailbox.
Before moving users, perform that rehearsal with a domain and mailbox you control. Retain the delivery results and log evidence so a later failure has something concrete to compare against. If nobody can take responsibility for that work, stop the selection process here. A web administration interface cannot substitute for an operator who can explain why a message was rejected.
The stable branch has current patches despite its older name
GitHub recorded a last push on October 23, 2026, and published release 2024.06.67 that day. Its notes describe a patched PHP runtime for webmail and link the change to a project issue. The dated release ties that update to issue-driven webmail maintenance. The year in the release name is therefore poor evidence of abandonment; dated maintenance tells a different story.
The setup guide recommends the stable 2024.06 branch and explicitly warns against using latest, which follows the development branch, for production. Release notes distinguish a moving branch tag from an immutable patch tag. Choose the update behavior deliberately and read the relevant changes before refreshing images. Our Python audit did not assess the webmail runtime discussed in those release notes.
Configuration files and commercial support separate the alternatives
Docker Mailserver describes configuration-file administration without an SQL database. Evaluate it when that operating model fits your team better than Mailu's web administration. This is a management preference, not evidence of a smaller footprint or faster deployment. We have no comparative measurements for either mail stack here.
mailcow links a paid support contract in its README. That deserves investigation when an accountable commercial support route is part of the purchase decision. Check the actual agreement and coverage before relying on it. Mailu's own setup guide directs readers seeking long-term professional support elsewhere, so that requirement should affect the shortlist early.
Domain delegation is useful when someone owns delivery
Mailu's per-domain administration and mailbox features give it a practical audience: people who need to operate email for others while keeping routine account work in a browser. That is a clearer reason to adopt it than a short source-install timing. The supplied run reached a Flask import failure before it could tell us how the admin application behaved.
I'd trial Mailu on a separate domain before moving an organization's inboxes. Make external delivery and authentication checks the acceptance evidence, and resolve the Python environment separately if you intend to contribute code. The next milestone is a message accepted outside your server and a reply received back, with an operator able to trace both.