How to Self-Host Mailcow Email Server 2026

TL;DR

Mailcow (GPL 2.0, ~8K GitHub stars) is the most complete self-hosted email server stack. It ships Postfix (SMTP), Dovecot (IMAP), SOGo (webmail + CalDAV/CardDAV), Rspamd (spam filtering), ClamAV (antivirus), and a polished web UI — all in one Docker Compose stack. Google Workspace charges $6/user/month ($72/year). Mailcow self-hosted is free for unlimited users on your own hardware. The DNS setup takes 30 minutes; after that, you have a production-grade email server.

Key Takeaways

Mailcow: GPL 2.0, ~8K stars — Postfix + Dovecot + SOGo + Rspamd in one Docker stack
DNS critical: SPF, DKIM, DMARC, and PTR records are required for email deliverability
SOGo webmail: Full webmail interface with calendar (CalDAV) and contacts (CardDAV)
Rspamd: AI-powered spam filter with web UI — much better than SpamAssassin
Email aliases: Unlimited aliases per domain, catchall addresses, per-mailbox limits
ClamAV optional: Disable on low-RAM servers (< 2GB) — uses ~700MB RAM

Prerequisites

VPS with static IP — cloud server at Hetzner, DigitalOcean, Vultr, etc.
Minimum specs: 2 CPU, 4GB RAM (6GB recommended if enabling ClamAV)
Port 25 unblocked — many residential ISPs block port 25; VPS providers usually allow it
A domain you control — e.g., yourdomain.com
Reverse DNS (PTR) record — set in your VPS control panel to match your hostname

Part 1: Docker Setup

# Install Mailcow (official installer):
cd /opt
git clone https://github.com/mailcow/mailcow-dockerized
cd mailcow-dockerized

# Generate configuration:
./generate_config.sh
# Prompts for:
# - Hostname: mail.yourdomain.com
# - Timezone: America/Los_Angeles

# Review mailcow.conf:
cat mailcow.conf

Key settings in mailcow.conf:

# mailcow.conf
MAILCOW_HOSTNAME=mail.yourdomain.com
TZ=America/Los_Angeles

# Disable ClamAV on low-RAM servers:
SKIP_CLAMD=y

# Skip unbound DNS resolver (use host DNS):
SKIP_UNBOUND=y

# HTTP/HTTPS ports (if Caddy/Nginx handles TLS):
HTTP_PORT=8080
HTTPS_PORT=8443
HTTP_BIND=127.0.0.1
HTTPS_BIND=127.0.0.1

# Start Mailcow:
docker compose pull
docker compose up -d

# Check all services are running:
docker compose ps

Services that start:

mailcow-postfix — SMTP (25, 587, 465)
mailcow-dovecot — IMAP/POP3 (143, 993, 110, 995)
mailcow-rspamd — Spam filtering
mailcow-sogo — Webmail
mailcow-nginx — Internal reverse proxy
mailcow-mysql — Database
mailcow-redis — Cache
mailcow-clamd — Antivirus (if enabled)

Part 2: Reverse Proxy with Caddy

mail.yourdomain.com {
    reverse_proxy localhost:8080 {
        header_up Host {host}
        header_up X-Real-IP {remote_host}
        header_up X-Forwarded-For {remote_host}
        header_up X-Forwarded-Proto {scheme}
    }
}

Visit https://mail.yourdomain.com — log in with admin / moohoo (change immediately).

Part 3: DNS Configuration

DNS is the most critical part of email deliverability. Configure all of these:

A and MX records

; A record for your mail server:
mail.yourdomain.com.    IN A     YOUR.SERVER.IP

; MX record — points to your mail server:
yourdomain.com.         IN MX 10 mail.yourdomain.com.

SPF record (prevents spoofing)

yourdomain.com.   IN TXT  "v=spf1 mx ~all"

This says: only servers listed in MX are allowed to send email for this domain.

DKIM record (cryptographic signing)

# Get your DKIM public key from Mailcow UI:
# Configuration → Domains → yourdomain.com → DKIM → Show public key

; DKIM record (long TXT record from Mailcow UI):
dkim._domainkey.yourdomain.com.  IN TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9..."

DMARC record (policy enforcement)

; Start with p=none (monitoring only), upgrade after confirming delivery:
_dmarc.yourdomain.com.  IN TXT  "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com"

; After 2-4 weeks, upgrade to quarantine:
_dmarc.yourdomain.com.  IN TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com"

; After confirming no legitimate email is failing, upgrade to reject:
_dmarc.yourdomain.com.  IN TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com"

Reverse DNS (PTR) — set in VPS control panel

YOUR.SERVER.IP → mail.yourdomain.com

Autoconfiguration records (for email clients)

; Mozilla Thunderbird/GNOME Evolution autodiscover:
autoconfig.yourdomain.com.  IN CNAME  mail.yourdomain.com.

; Outlook autodiscover:
autodiscover.yourdomain.com.  IN CNAME  mail.yourdomain.com.

; SRV records for IMAP/SMTP:
_imap._tcp.yourdomain.com.    IN SRV  0 1 143  mail.yourdomain.com.
_imaps._tcp.yourdomain.com.   IN SRV  0 1 993  mail.yourdomain.com.
_submission._tcp.yourdomain.com.  IN SRV  0 1 587  mail.yourdomain.com.
_submissions._tcp.yourdomain.com. IN SRV  0 1 465  mail.yourdomain.com.

Test your DNS

# Verify all records:
dig MX yourdomain.com
dig TXT yourdomain.com     # SPF
dig TXT dkim._domainkey.yourdomain.com  # DKIM
dig TXT _dmarc.yourdomain.com           # DMARC
dig -x YOUR.SERVER.IP                   # PTR/reverse DNS

# Send a test email and check score:
# mail-tester.com — aim for 10/10

Part 4: Admin UI — Domains and Mailboxes

Add a domain

Configuration → Domains → Add domain
Domain: yourdomain.com
Max mailboxes, quota, aliases
Enable DKIM: generate 2048-bit key → copy TXT record to DNS

Create mailboxes

Configuration → Mailboxes → Add mailbox
Username: hello (creates hello@yourdomain.com)
Quota: 10GB (or 0 for unlimited)
Active: yes

Create aliases

# Example aliases via UI:
# postmaster@yourdomain.com → hello@yourdomain.com
# abuse@yourdomain.com → hello@yourdomain.com
# info@yourdomain.com → hello@yourdomain.com

# Catchall — catch all unmatched addresses:
# @yourdomain.com → hello@yourdomain.com

Part 5: Email Clients

Desktop (Thunderbird)

Autoconfiguration usually works automatically:

Thunderbird → Add account
Enter name, email, password
Thunderbird auto-discovers IMAP/SMTP settings

Manual settings:

IMAP: mail.yourdomain.com:993 (SSL/TLS)
SMTP: mail.yourdomain.com:587 (STARTTLS)
Username: hello@yourdomain.com

iOS / macOS

Settings → Mail → Add Account → Other
Add Mail Account → name, email, password
IMAP server: mail.yourdomain.com, SSL, port 993
SMTP server: mail.yourdomain.com, STARTTLS, port 587

Webmail (SOGo)

Access at https://mail.yourdomain.com/SOGo — full webmail with:

Email composer with rich text
Calendar (CalDAV — sync to iOS/macOS/Android)
Address book (CardDAV)

Part 6: Rspamd (Spam Filtering)

Rspamd is Mailcow's spam engine — far superior to SpamAssassin:

Access Rspamd web UI

https://mail.yourdomain.com/rspamd

Default password in mailcow.conf → RSPAMD_PASSWORD

Train the spam filter

# Mark email as spam (trains Rspamd):
# In webmail: move message to Junk folder → Rspamd learns

# Via CLI:
docker exec -it mailcow-rspamd rspamc learn_spam < /path/to/spam.eml
docker exec -it mailcow-rspamd rspamc learn_ham < /path/to/legitimate.eml

Spam action thresholds

Score	Action
< 5	Deliver normally
5-10	Add [SPAM] header, deliver
> 10	Reject
Greylisting	Hold 5 min then retry

Adjust in Configuration → Configuration files → rspamd/local.d/actions.conf:

reject = 15;
add_header = 6;
greylist = 4;

Part 7: Backup and Restore

# Backup script (add to cron):
cd /opt/mailcow-dockerized

# Export all data:
./helper-scripts/backup_and_restore.sh backup all

# Backup created in: /opt/mailcow-dockerized/backups/

# Restore:
./helper-scripts/backup_and_restore.sh restore

# Manual MySQL backup:
docker exec mailcow-mysql mysqldump -u root --password="$(grep DBPASS mailcow.conf | cut -d= -f2)" mailcow \
  | gzip > mailcow-db-$(date +%Y%m%d).sql.gz

# Backup mail data (Dovecot volumes):
tar -czf mailcow-mail-$(date +%Y%m%d).tar.gz \
  $(docker volume inspect mailcow-dockerized_vmail-vol-1 --format '{{.Mountpoint}}')

Part 8: Maintenance and Updates

# Update Mailcow (run monthly):
cd /opt/mailcow-dockerized
./update.sh

# Check mail queue:
docker exec mailcow-postfix mailq

# Flush the queue:
docker exec mailcow-postfix postfix flush

# Postfix logs:
docker compose logs postfix -f

# Dovecot logs (IMAP):
docker compose logs dovecot -f

# Check TLS/certificate expiry:
docker exec mailcow-postfix openssl s_client -connect mail.yourdomain.com:993 </dev/null 2>&1 | grep -E "notAfter|subject"

Deliverability Checklist

Before sending to real recipients, verify:

MX record resolves to your server IP
PTR/reverse DNS matches your hostname
SPF includes your server
DKIM key published and signing works
DMARC policy set (start with p=none)
Port 25 not blocked by VPS provider
mail-tester.com score: 9+/10
Not on blocklists: check at mxtoolbox.com/blacklists

Why Self-Host Mailcow?

The case for self-hosting Mailcow comes down to three practical factors: data ownership, cost at scale, and operational control.

Data ownership is the fundamental argument. When you use a SaaS version of any tool, your data lives on someone else's infrastructure subject to their terms of service, their security practices, and their business continuity. If the vendor raises prices, gets acquired, changes API limits, or shuts down, you're left scrambling. Self-hosting Mailcow means your data and configuration stay on infrastructure you control — whether that's a VPS, a bare metal server, or a home lab.

Cost at scale matters once you move beyond individual use. Most SaaS equivalents charge per user or per data volume. A self-hosted instance on a $10-20/month VPS typically costs less than per-user SaaS pricing for teams of five or more — and the cost doesn't scale linearly with usage. One well-configured server handles dozens of users for a flat monthly fee.

Operational control is the third factor. The Docker Compose configuration above exposes every setting that commercial equivalents often hide behind enterprise plans: custom networking, environment variables, storage backends, and authentication integrations. You decide when to update, how to configure backups, and what access controls to apply.

The honest tradeoff: you're responsible for updates, backups, and availability. For teams running any production workloads, this is familiar territory. For individuals, the learning curve is real but the tooling (Docker, Caddy, automated backups) is well-documented and widely supported.

Server Requirements and Sizing

Before deploying Mailcow, assess your server capacity against expected workload.

Minimum viable setup: A 1 vCPU, 1GB RAM VPS with 20GB SSD is sufficient for personal use or small teams. Most consumer VPS providers — Hetzner, DigitalOcean, Linode, Vultr — offer machines in this range for $5-10/month. Hetzner offers excellent price-to-performance for European and US regions.

Recommended production setup: 2 vCPUs with 4GB RAM and 40GB SSD handles most medium deployments without resource contention. This gives Mailcow headroom for background tasks, caching, and concurrent users while leaving capacity for other services on the same host.

Storage planning: The Docker volumes in this docker-compose.yml store all persistent Mailcow data. Estimate your storage growth rate early — for data-intensive tools, budget for 3-5x your initial estimate. Hetzner Cloud and Vultr both support online volume resizing without stopping your instance.

Operating system: Any modern 64-bit Linux distribution works. Ubuntu 22.04 LTS and Debian 12 are the most commonly tested configurations. Ensure Docker Engine 24.0+ and Docker Compose v2 are installed — verify with docker --version and docker compose version. Avoid Docker Desktop on production Linux servers; it adds virtualization overhead and behaves differently from Docker Engine in ways that cause subtle networking issues.

Network: Only ports 80 and 443 need to be publicly accessible when running behind a reverse proxy. Internal service ports should be bound to localhost only. A minimal UFW firewall that blocks all inbound traffic except SSH, HTTP, and HTTPS is the single most effective security measure for a self-hosted server.

Backup and Disaster Recovery

Running Mailcow without a tested backup strategy is an unacceptable availability risk. Docker volumes are not automatically backed up — if you delete a volume or the host fails, data is gone with no recovery path.

What to back up: The named Docker volumes containing Mailcow's data (database files, user uploads, application state), your docker-compose.yml and any customized configuration files, and .env files containing secrets.

Backup approach: For simple setups, stop the container, archive the volume contents, then restart. For production environments where stopping causes disruption, use filesystem snapshots or database dump commands (PostgreSQL pg_dump, SQLite .backup, MySQL mysqldump) that produce consistent backups without downtime.

For a complete automated backup workflow that ships snapshots to S3-compatible object storage, see the Restic + Rclone backup guide. Restic handles deduplication and encryption; Rclone handles multi-destination uploads. The same setup works for any Docker volume.

Backup cadence: Daily backups to remote storage are a reasonable baseline for actively used tools. Use a 30-day retention window minimum — long enough to recover from mistakes discovered weeks later. For critical data, extend to 90 days and use a secondary destination.

Restore testing: A backup that has never been restored is a backup you cannot trust. Once a month, restore your Mailcow backup to a separate Docker Compose stack on different ports and verify the data is intact. This catches silent backup failures, script errors, and volume permission issues before they matter in a real recovery.

Security Hardening

Self-hosting means you are responsible for Mailcow's security posture. The Docker Compose setup provides a functional base; production deployments need additional hardening.

Always use a reverse proxy: Never expose Mailcow's internal port directly to the internet. The docker-compose.yml binds to localhost; Caddy or Nginx provides HTTPS termination. Direct HTTP access transmits credentials in plaintext. A reverse proxy also centralizes TLS management, rate limiting, and access logging.

Strong credentials: Change default passwords immediately after first login. For secrets in docker-compose environment variables, generate random values with openssl rand -base64 32 rather than reusing existing passwords.

Firewall configuration:

ufw default deny incoming
ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable

Internal service ports (databases, admin panels, internal APIs) should only be reachable from localhost or the Docker network, never directly from the internet.

Network isolation: Docker Compose named networks keep Mailcow's services isolated from other containers on the same host. Database containers should not share networks with containers that don't need direct database access.

VPN access for sensitive services: For internal-only tools, restricting access to a VPN adds a strong second layer. Headscale is an open source Tailscale control server that puts your self-hosted stack behind a WireGuard mesh, eliminating public internet exposure for internal tools.

Update discipline: Subscribe to Mailcow's GitHub releases page to receive security advisory notifications. Schedule a monthly maintenance window to pull updated images. Running outdated container images is the most common cause of self-hosted service compromises.

Troubleshooting Common Issues

Container exits immediately or won't start

Check logs first — they almost always explain the failure:

docker compose logs -f mailcow

Common causes: a missing required environment variable, a port already in use, or a volume permission error. Port conflicts appear as bind: address already in use. Find the conflicting process with ss -tlpn | grep PORT and either stop it or change Mailcow's port mapping in docker-compose.yml.

Cannot reach the web interface

Work through this checklist:

Confirm the container is running: docker compose ps
Test locally on the server: curl -I http://localhost:PORT
If local access works but external doesn't, check your firewall: ufw status
If using a reverse proxy, verify it's running and the config is valid: caddy validate --config /etc/caddy/Caddyfile

Permission errors on volume mounts

Some containers run as a non-root user. If the Docker volume is owned by root, the container process cannot write to it. Find the volume's host path with docker volume inspect VOLUME_NAME, check the tool's documentation for its expected UID, and apply correct ownership:

chown -R 1000:1000 /var/lib/docker/volumes/your_volume/_data

High resource usage over time

Memory or CPU growing continuously usually indicates unconfigured log rotation, an unbound cache, or accumulated data needing pruning. Check current usage with docker stats mailcow. Add resource limits in docker-compose.yml to prevent one container from starving others. For ongoing visibility into resource trends, deploy Prometheus + Grafana or Netdata.

Data disappears after container restart

Data stored in the container's writable layer — rather than a named volume — is lost when the container is removed or recreated. This happens when the volume mount path in docker-compose.yml doesn't match where the application writes data. Verify mount paths against the tool's documentation and correct the mapping. Named volumes persist across container removal; only docker compose down -v deletes them.

Keeping Mailcow Updated

Mailcow follows a regular release cadence. Staying current matters for security patches and compatibility. The update process with Docker Compose is straightforward:

docker compose pull          # Download updated images
docker compose up -d         # Restart with new images
docker image prune -f        # Remove old image layers (optional)

Read the changelog before major version updates. Some releases include database migrations or breaking configuration changes. For major version bumps, test in a staging environment first — run a copy of the service on different ports with the same volume data to validate the migration before touching production.

Version pinning: For stability, pin to a specific image tag in docker-compose.yml instead of latest. Update deliberately after reviewing the changelog. This trades automatic patch delivery for predictable behavior — the right call for business-critical services.

Post-update verification: After updating, confirm Mailcow is functioning correctly. Most services expose a /health endpoint that returns HTTP 200 — curl it from the server or monitor it with your uptime tool.

Frequently Asked Questions

How much does it cost to self-host Mailcow?

The primary cost is your server. A Hetzner CAX11 (2 vCPU ARM, 4GB RAM) runs about $5/month — enough for Mailcow plus a few companion services. Add a domain ($12/year) and you're under $75/year for a complete self-hosted deployment. Compare that to SaaS pricing that typically starts at $5-15/user/month.

Can I run Mailcow on a VPS with other services?

Yes. The docker-compose.yml above isolates Mailcow on its own named Docker network. As long as your server has sufficient RAM and disk — 4GB RAM and 20GB disk handles most combinations — running multiple self-hosted services on one VPS is both practical and common. Tools like Dozzle and Portainer make monitoring multi-container setups manageable.

How do I migrate data if I switch servers?

Stop the Mailcow container, export the Docker volumes (using docker run --rm -v VOLUME:/data -v $(pwd):/backup alpine tar czf /backup/backup.tar.gz /data), transfer to the new server, restore the volumes, and update your DNS. Most migrations complete in under an hour. Test the restoration on the new server before decommissioning the old one.

What happens if Mailcow releases a breaking update?

Pin your docker-compose.yml to a specific image tag (e.g., image: mailcow:1.2.3 instead of latest). Subscribe to the GitHub releases page for advance notice. When you're ready to upgrade, read the release notes, back up first, test on a staging instance, then update production.

Is Mailcow suitable for production use?

Yes, with the hardening described above: reverse proxy for HTTPS, firewall rules, regular backups, and a pinned image tag. Many teams run Mailcow in production successfully. The main requirement is treating your self-hosted instance with the same operational discipline you'd apply to any business-critical service.

See all open source email tools at OSSAlt.com/categories/email.

The SaaS-to-Self-Hosted Migration Guide (Free PDF)