Mailu Self-Hosted: Docker Setup, Requirements, and Beginner Guide
A documentation-based Mailu self-hosted email guide covering Docker Compose, requirements, DNS, home vs VPS, administration, backups, updates, deliverability, and Mailu vs Mailcow.
If you want to run email on infrastructure you control, Mailu is a focused option: a full-featured mail server assembled from Docker images rather than a broad groupware suite. This guide covers the decisions that matter before deployment - hardware, DNS, networking, Compose, administration, backups, updates, and deliverability.
Documentation basis: This is a research-led guide based on the official Mailu documentation and the official mailcow repository. No first-hand installation, ownership, or delivery testing is claimed. Verify the instructions against the Mailu version you plan to deploy, because the project publishes versioned documentation.
Key takeaways
Mailu fits operators who want a self-hosted mail stack with IMAP, SMTP, webmail, administration, aliases, quotas, TLS, SPF, DKIM, DMARC, and antispam components in one Docker-based project.[1]
A small deployment needs a public, dedicated-looking mail hostname, stable IP addressing, reverse DNS, open mail ports, and control of the domain's DNS. Mailu's documented minimum is 1 GB RAM plus 1 GB swap without ClamAV, or 3 GB RAM plus 1 GB swap with ClamAV.[2]
A home connection can be useful for learning and internal mail, but a VPS is usually the safer beginner recommendation for Internet-facing delivery because residential IP reputation, port-25 blocking, changing addresses, and reverse-DNS limitations are common operational barriers.
The comparison page on this site covers four self-hosted email projects. This article is narrower: it is a Mailu deployment and suitability guide, not another four-way roundup.
What Mailu is
Mailu is an open-source mail server distributed as a set of Docker images. Its official documentation describes standard IMAP and SMTP services, submission, client auto-configuration, aliases, domain aliases, webmail, an administration interface, quotas, enforced TLS, DKIM, SPF, DMARC, and antispam features.[1]
That scope makes Mailu more than a single SMTP container. It is a coordinated service stack with persistent mail data, configuration, certificates, a database, filtering services, and a web administration surface. The benefit is a coherent deployment model. The cost is that you are operating an Internet-facing mail system, not just starting one container.
Who Mailu fits - and who should avoid it
Mailu is a good fit when you want:
mailboxes and aliases for a domain you control;
Docker Compose as the operational model;
a web UI for domains, users, aliases, quotas, and related settings;
a self-hosted learning project where DNS, TLS, backups, and reputation are part of the work;
a focused mail platform instead of a large collaboration suite.
It is a poor fit when you need guaranteed inbox placement, have no control over reverse DNS, cannot expose the required ports, or want a maintenance-free mailbox provider. For family or business-critical mail, keep an independent backup or hosted mailbox while you learn. Self-hosting mail gives you control, not immunity from spam filtering or provider policy.
Home server or VPS?
Home deployment
A home server can work for a lab or controlled experiment if your ISP permits inbound and outbound mail traffic, your router forwards the required ports, your public address is stable, and your ISP or dynamic-DNS setup gives you usable reverse DNS. Mailu's requirements documentation recommends a public IP, a dedicated hostname, and matching forward and reverse DNS, and warns that the host must not already be using Mailu's service ports.[2]
transmission signup
article_topic // Mailu Self-Hosted
Don't leave without the setup notes.
Get practical homelab guides, failure logs, and beginner-friendly build notes in your inbox.
Enter your email address to receive the Homelab Addiction newsletter.
Weekly only. No spam. Unsubscribe anytime.
The main risk is deliverability. Large providers evaluate the sending IP, reverse DNS, domain authentication, message patterns, and reputation. A residential address may be blocked, have poor reputation, or be impossible to configure with matching PTR records. A home deployment is therefore best treated as a learning environment unless you already understand those constraints.
VPS deployment
A VPS is the better starting point for public mail when the provider gives you a static IPv4 address, configurable PTR/reverse DNS, usable IPv6 or a clear IPv6 policy, and permits mail traffic. Choose the provider before you write the Compose file. Confirm port 25 policy, abuse rules, snapshots or backup options, and whether the assigned IP has a clean enough reputation for your use case.
A VPS does not solve deliverability automatically. You still need correct DNS, authentication records, TLS, sensible sending behavior, monitoring, and a recovery plan. It simply removes several common home-network obstacles.
Requirements checklist
Before deployment, prepare:
A domain whose DNS zone you can edit.
A mail hostname such as mail.example.com.
A public server IP and a provider that permits the required ports.
Linux with Docker Engine from the official Docker repositories and Docker Compose v2, as recommended by Mailu's Compose documentation.[2]
At least 1 GB RAM and 1 GB swap without ClamAV, or 3 GB RAM and 1 GB swap with ClamAV.[2]
Storage for mail, indexes, configuration, logs, and backups. Mailu's persistent data is stored under a directory such as /mailu.[3]
A plan for TLS certificates, updates, off-host backups, and recovery testing.
Mailu uses ports including 25, 80, 110, 143, 443, 465, 587, 993, 995, and 4190. Do not deploy it on a host where another service already owns those ports unless you have deliberately designed an external reverse-proxy or port-binding arrangement.[2]
DNS prerequisites
DNS is the part that makes or breaks a mail deployment. Start with the server hostname:
mail.example.com. IN A 203.0.113.10
example.com. IN MX 10 mail.example.com.
Mailu's DNS guide says every domain handled by the server needs an MX record pointing to the mail server hostname, while that hostname needs an address record pointing to the server IP.[4] Configure reverse DNS with the hosting provider so the IP resolves back to the same mail hostname. Incorrect reverse DNS can cause receiving systems to reject or heavily filter messages.[4]
After the Mailu admin interface generates the domain keys, publish the requested SPF, DKIM, and DMARC records. These records authenticate the sending domain and tell recipient systems how to handle messages that fail authentication. They improve legitimacy signals, but they do not guarantee inbox placement.[4]
Also check that the A and AAAA records for hostnames listed in HOSTNAMES match the server when using Mailu's Let's Encrypt TLS flavor. A mismatch can prevent certificate generation.[3]
Docker Compose deployment overview
Mailu's documented flow is deliberately configuration-first:
mkdir /mailu
cd /mailu
# Generate docker-compose.yml and mailu.env with https://setup.mailu.io/
# Review mailu.env before starting services
docker compose up -d
The setup utility generates docker-compose.yml and mailu.env; the official setup page then instructs you to review the variables, finish TLS configuration, and start the stack with docker compose up -d.[3] Select a stable Mailu documentation branch rather than blindly copying examples from the moving master branch.
At minimum, review the hostname, domain, bind addresses, TLS flavor, database choice, administrator settings, and persistent paths. Do not paste a real administrator password into shell history or commit mailu.env to a public repository.
Once services are running, create the initial administrator using the documented automatic environment variables or the admin container command. Immediately replace any temporary credential with a strong, unique password and store recovery information securely.[3]
Administration after the first start
Use the web administration interface to add the mail domain, create users and aliases, set quotas, and retrieve the generated authentication records. Mailu also documents command-line operations for domains, users, aliases, passwords, configuration export, and configuration import.[1]
Keep administrative access separate from ordinary mailbox access. Limit the admin hostname or path with your reverse-proxy and firewall policy where practical, enforce TLS, and monitor authentication failures. Treat the admin interface as part of your attack surface, not as a setup page you can forget.
Backups and updates
A mail backup is more than a copy of one Docker volume. Include the Mailu persistent data directory, mailu.env, Compose files, certificate material or certificate-recovery process, and any external database data. Store at least one backup off the mail host and encrypt it if it contains mailbox content.
A practical maintenance cycle is:
Read the release notes for the exact Mailu branch you run.
Take and verify a restorable backup.
Record the current image versions and configuration.
Pull the documented update changes and recreate services using the project instructions.
Check login, SMTP submission, IMAP, webmail, queues, TLS, and DNS authentication.
Keep a rollback path and document what changed.
Mailu's maintenance documentation includes upgrading and migrating an instance, so use it instead of treating docker compose pull as a complete upgrade procedure.[1]
From the lab
Deliverability limits you should expect
Mailu can provide the technical building blocks for authenticated mail, but no self-hosted package can promise that Gmail, Outlook, Yahoo, or other providers will accept every message. Deliverability depends on IP and domain reputation, reverse DNS, SPF, DKIM, DMARC, TLS, content, complaint rates, bounce handling, list hygiene, and provider-specific filtering.
For a beginner, the safest expectation is: first make receiving mail reliable, then test low-volume sending to accounts you control, inspect authentication results, and monitor bounces. Do not use a fresh residential IP or VPS as a bulk-sending platform. Keep a hosted fallback for critical communication.
Mailu vs Mailcow
Mailu and mailcow are both Docker-oriented self-hosted mail platforms, but they present different trade-offs. Mailu's official positioning emphasizes a focused, full-featured mail server built from Docker images and avoids unrelated groupware features.[1] The official mailcow repository describes mailcow: dockerized as a broader stack with its own web interface, documentation, and a collection of integrated services.[5]
Choose based on
Mailu
Mailcow
Project shape
Focused mail-server distribution
Larger integrated mail platform
Deployment model
Docker images with generated Compose configuration
Dockerized stack with a project-specific setup/update workflow
Best starting point
Operators who want a comparatively focused mail deployment
Operators who want a richer integrated platform and accept more components
Evidence basis here
Official Mailu docs
Official mailcow repository
This is a documentation-based comparison, not a side-by-side benchmark. Choose Mailu when its focused scope and Compose workflow match your needs. Choose mailcow when you specifically need its broader integrated feature set and are comfortable operating the larger stack.
Beginner recommendation
Start with Mailu on a small VPS, not your primary home connection, if your goal is to learn Internet-facing self-hosted email. Use a disposable or secondary domain first. Confirm the provider's port-25 and reverse-DNS policies before provisioning. Deploy one domain, one mailbox, and one alias; configure TLS and SPF/DKIM/DMARC; test receiving and low-volume sending; then build backups and update procedures before adding more users.
If your actual goal is dependable personal or business email rather than learning mail operations, use a managed provider and keep Mailu as a lab project. The software can be approachable; the surrounding reputation and DNS work is the real commitment.
FAQ
Can Mailu run at home?
Yes, technically, if your ISP, router, IP address, reverse DNS, and firewall support the required services. For public delivery, a VPS is usually the more predictable beginner path.
How much RAM does Mailu need?
The official Compose requirements list 1 GB RAM plus 1 GB swap without ClamAV, and 3 GB RAM plus 1 GB swap with ClamAV.[2]
Is Mailu easier than Mailcow?
That depends on the operator and required features. Mailu is the better fit when you want a focused Docker mail stack. Mailcow may fit better when you want its broader integrated platform. This guide does not claim a hands-on ease-of-use test.
Will Mailu emails reach Gmail?
Sometimes, when DNS, authentication, reverse DNS, IP reputation, message practices, and recipient policies are all favorable. Mailu alone cannot guarantee inbox placement.
Sources and version note
This article was reviewed against the official Mailu documentation pages linked below and the official mailcow repository. Mailu documents multiple version branches; re-check the stable branch and release notes before deploying.