Deploy docker-mailserver with persistent configuration and mail
Pin a supported image, use version-matched Compose settings, and separate durable data from a disposable container.
Reviewed
docker-mailserver assembles conventional SMTP/mailbox components without requiring a SQL account database. The container image is not the persistence boundary: account configuration, mail, and relevant state need explicit host volumes.
Still deciding which Docker stack to operate? See docker-mailserver in our Linux mail-server comparison.
Prepare the Compose deployment
- Follow the versioned usage guide, selecting documentation matching the pinned image rather than mixing releases.
- Use the published Compose/environment example and review hostname, port bindings, volume paths, and optional services.
- Configure a controlled domain’s MX/A/AAAA/PTR and the actual TLS hostname. Verify host/network firewall behavior for the selected container runtime.
- Protect configuration files and persistent mail directories; back them up outside the container host.
Do not expose an unauthenticated relay or assume rebuilding the container will recreate mailbox contents. Avoid logging rendered Compose configuration if it contains secrets.
Validate a restart-safe deployment
Check container health/logs and client-visible TLS. Provision one controlled account in the next guide, then verify mail and account state survive a planned container recreation using the same volumes.
Before production MX changes, test incoming receipt, authenticated submission, and unknown-recipient/unauthorized-relay rejection. A healthy container is not proof that external SMTP reachability or DNS is correct. Keep the previous DNS/configuration and backup available for rollback.