Make room for your mail.
The binary simplifies the application stack. Your domain, network, HTTPS boundary and data lifecycle still need a deliberate setup.
Give your domain a clear route
- Create an A record for your mail hostname and an MX record that points to it.
- Publish the SPF, DKIM and DMARC records appropriate to your sending setup. Quickstart prints an initial DNS guide.
- Ask your IP provider to configure reverse DNS (PTR) to match your mail hostname.
- Confirm inbound and outbound port 25 is permitted. Network access and correct DNS do not guarantee deliverability.
Follow the official DNS setup guide. Preserve existing mail records when changing unrelated website hosting records.
Know which doors are open
These are configuration defaults, not an instruction to expose every port. Enable only the services you use and review the current defaults.
Put HTTPS at the web edge
The current web and admin servers speak HTTP. Terminate HTTPS at a reverse proxy, then forward to a loopback listener. Mail protocol TLS is configured separately.
server:
hostname: mail.example.com
data_dir: /var/lib/umailserver
http:
enabled: true
bind: "127.0.0.1"
port: 8880
trusted_proxies: ["127.0.0.1"]
admin:
enabled: true
bind: "127.0.0.1"
port: 8443Configure your reverse proxy, mail TLS certificates, domains, storage permissions and secrets separately. In a container network, loopback and proxy trust must be adapted to the actual network boundary.
Forwarded client IP headers are trusted only from peers listed in http.trusted_proxies. Restrict that list to your actual proxy addresses; arbitrary client-supplied headers must not become the audit identity.
See the complete configuration example and production container stack.
Plan the machine and the data
The deployment documentation suggests at least two CPU cores, 4 GB RAM and 20 GB SSD storage. Treat these as documented planning guidance, not a measured capacity guarantee. Size the disk for mail volume, retention, indexes and backups.
- Keep configuration, certificates and mail data on persistent storage.
- Run one instance per data directory; bbolt files are local, single-process stores.
- Stop the server before direct-database CLI backup or maintenance commands. Test restore procedures before relying on them.
- Use the REST API to administer a running server.
Observe, update, verify
Metrics default to http://127.0.0.1:8080/metrics; monitoring health is /healthz. The web listener also exposes /health and /health/ready. Keep internal observability endpoints protected.
Back up data and configuration, build the intended source revision, stop the old process and replace the executable. Restart after configuration changes: SIGHUP only rechecks manually managed TLS certificates.
A binary refuses databases written by a newer schema version; do not downgrade against the same data files. CLI backups require a stopped server. Restore extracts into restore_temp/; inspect the result and follow the runbook before moving data into service.
Consult the deployment guide and operational runbook for further detail.
