Self-Host Mailcow on a VPS for Domain Email Hosting

Email is still the fastest way to lose trust when it fails. One bad DNS record can push order confirmations into spam. One missed update can turn a mail server into a liability.

If you want hosted-style control without handing inboxes to a third party, self-host Mailcow on a VPS. You get a complete mail stack, a solid admin UI, and sensible defaults. You also get an ops model that matches real infrastructure.

This is an open-source spotlight, not a wall of copy-paste commands. You’ll get the “why,” a realistic comparison to hosted providers, and a deployment outline.

We’ll cover Docker Compose on a VPS, DNS (SPF/DKIM/DMARC), HTTPS for the admin UI, backups, and updates that don’t surprise you.

Mailcow in one sentence (and who it’s for)

Mailcow is a self-hosted email server suite. It bundles SMTP, IMAP/POP, spam filtering, antivirus, webmail options, and an admin UI into a Docker Compose deployment.

It’s a good fit if you:

• Run one or more domains and want mailboxes like you@yourdomain.com without per-user SaaS pricing.
• Need control over retention, aliases, catch-alls, and mailbox provisioning for a team.
• Prefer an “appliance-like” approach (a known-good stack) instead of assembling Postfix/Dovecot/Rspamd by hand.

If your business depends on email delivery, treat this like production infrastructure. Use a VPS with enough RAM, publish DNS correctly, and keep backups offsite.

License and what you actually get

Mailcow is open source (Mailcow: Dockerized). It ships as a set of containers plus the wiring to run the full mail flow end-to-end.

You also get a browser-based admin interface for domains, mailboxes, aliases, and policies.

Feature highlights operators usually care about:

• Modern spam filtering: Rspamd-based filtering with tunable policies.
• TLS everywhere: SMTP/IMAP encryption plus HTTPS for the UI, typically with Let’s Encrypt.
• DKIM signing: per-domain DKIM keys and DNS guidance.
• Admin UX: create mailboxes, aliases, and limits without editing ten config files.
• Docker Compose operations: predictable updates and easier rollback thinking than “pets” built by hand.

How Mailcow compares to hosted email (Google Workspace, Microsoft 365, and “cPanel mail”)

Hosted providers win on global deliverability tuning, enterprise SSO, and not running a mail server. Self-hosting wins on predictable costs, tighter control, and clean portability.

• Versus Google Workspace / Microsoft 365: You won’t get the surrounding ecosystem (Docs/Teams/SharePoint). You also won’t pay per-seat indefinitely, and your mailbox data stays under your policies.
• Versus “just use cPanel email”: cPanel can work, but Mailcow is built for mail operations. It gives you a focused UI, clear defaults, and a stack that’s designed to live as a unit. If your hosting server also runs customer sites, moving email onto its own VPS often reduces risk and cuts troubleshooting time.
• Versus transactional email services (SendGrid/Mailgun/etc.): Those are for application delivery, not inbox hosting. You can still pair a Mailcow inbox domain with a relay for app sends if you want.

If you’re already running production workloads, don’t put email on the same box as your app. Email attracts abuse, generates noisy logs, and carries its own reputation risk.

A dedicated mail VPS keeps that blast radius contained.

What you need before you deploy (VPS sizing, IP reputation, and OS)

Mail servers rarely burn CPU. They depend more on memory, disk I/O, and long-term stability.

• Minimum (small team): 2 vCPU, 4 GB RAM, 60–80 GB SSD/NVMe.
• Comfortable (multiple domains, active filtering): 4 vCPU, 8 GB RAM, 120+ GB SSD/NVMe.
• Network: one dedicated public IPv4 is strongly recommended for deliverability. IPv6 helps, but don’t rely on it alone.

Stick to a stable Linux base. Ubuntu LTS and Debian stable are common choices.

Patch the host and lock it down.

If you want the server tuned and monitored without losing weekends to maintenance, consider managed VPS hosting from HostMyCode—Mailcow is exactly the kind of critical service that benefits from consistent upkeep.

Two practical deliverability notes:

• Reverse DNS (rDNS/PTR): Your VPS IP should resolve back to a hostname you control (for example, mail.example.com), and that hostname should resolve to the same IP (A record). Skip this and some receivers will distrust you immediately.
• Fresh IP reality: New IPs sometimes start with weak reputation. Warm up gradually (normal human mail, not blasts) and watch bounces.

Deploy Mailcow with Docker Compose on a VPS (the operator’s outline)

Mailcow works because the project ships a known set of containers and scripts. Those components are designed to run together.

Keep the host boring: Docker + Mailcow, not a grab bag of unrelated services fighting over ports.

1) Baseline host setup

On a fresh VPS:

• Set the hostname to your mail host, such as mail.example.com.
• Ensure correct time sync (systemd-timesyncd or chrony).
• Install Docker Engine and Docker Compose plugin (from upstream packages where possible).
• Open only the ports you need (SMTP/Submission/IMAPS/HTTPS, plus SSH).

If you want a clean security baseline before exposing mail ports, the workflow in Set Up UFW Firewall on Ubuntu for a Web Server transfers well—just adjust the allowed ports for mail services.

2) Get the Mailcow stack and generate config

Mailcow’s installer generates a mailcow.conf file. Treat it as your single source of truth for core settings like hostname, timezone, and options.

A typical layout looks like:

• /opt/mailcow-dockerized (project directory)
• docker-compose.yml and environment/config files inside it

You’ll set at least:

• Mail hostname: mail.example.com
• Timezone: match your ops team, not your customers
• Let’s Encrypt settings: valid email + hostname that resolves correctly

3) Bring it up and verify services

Once the stack is up, confirm the basics before you onboard users:

• The admin UI loads over HTTPS.
• IMAP and SMTP ports accept TLS connections.
• Mailcow can issue certificates (or you use your reverse proxy strategy; more on that below).

Don’t create ten domains on day one. Start with one domain and get clean delivery first.

Use correct DNS and send real test messages to multiple providers.

DNS records you must set (A, MX, SPF, DKIM, DMARC)

Most “email is broken” tickets come down to DNS. Mailcow can generate DKIM keys and show record snippets.

You still have to publish them correctly at your DNS provider.

Baseline records for a domain example.com with a mail host mail.example.com:

• A/AAAA: mail.example.com → your VPS IP(s).
• MX: example.com → mail.example.com with priority 10 (or similar).
• SPF (TXT): allow only your mail server (and any legitimate senders you use). Start simple and expand carefully.
• DKIM (TXT): publish the selector record Mailcow gives you for example.com.
• DMARC (TXT): start with p=none to monitor, then move to quarantine/reject once aligned.

Two rules prevent a lot of self-inflicted pain:

• One SPF record per domain: multiple SPF records are treated as a permanent error by receivers.
• DMARC needs alignment: SPF or DKIM must align with the From domain, not just appear “somewhere in the headers.”

If you want a compact, operator-focused reference for email authentication records, use Set Up DKIM, SPF, And DMARC For A Domain. It’s the difference between “arrives sometimes” and consistent delivery.

Reverse proxy + HTTPS for the UI (and a sane port strategy)

Mail traffic (SMTP/IMAP) doesn’t get “reverse proxied” like HTTP does. The admin UI is web-based, though.

You may want a standard reverse proxy in front of it. This can help with consistent TLS policy, HSTS, and centralized certificate management.

You have two common patterns:

• Let Mailcow manage its own TLS: simplest operationally because the stack expects to request and renew certificates. This works well when the UI is directly exposed.
• Terminate TLS at Nginx/Caddy for the UI only: useful if you already run a central proxy on the VPS, or you want extra controls like basic auth or IP allowlists for the admin endpoint.

If you prefer a modern proxy that plays nicely with Docker, the approach in Set Up Caddy Reverse Proxy for Docker on a VPS is a solid model.

Keep the scope tight: proxy only the Mailcow UI and any webmail container you enable. Don’t try to push SMTP/IMAP through HTTP proxy tooling.

Security baseline for the admin UI:

• Use HTTPS only, with HSTS once you’re confident.
• Restrict admin access by IP (office VPN, WireGuard, or a small allowlist) if possible.
• Enable 2FA for admin users and use long unique passwords (a password manager helps).

Backups that actually restore (mail data, configs, and the “oops” test)

Mail servers create two things you can’t afford to lose: mailbox content and configuration/state (domains, users, keys). Back up both.

Then prove you can restore. A backup you’ve never restored is just storage you pay for.

Mailcow includes a backup mechanism designed around its container layout. Your job is to make it routine:

• Frequency: daily is a sensible default for most teams; increase it if volume is high.
• Retention: keep at least 7–14 daily restore points, plus a few weekly snapshots.
• Offsite copy: sync backups off the VPS (object storage, another server, or a hardened backup box).

A straightforward offsite approach is to generate backups locally and push them with rclone or rsync to a second VPS.

Aim for isolation. If the mail VPS is compromised, the attacker shouldn’t be able to delete your only backup set.

Do a quarterly “oops” test:

1. Spin up a small temporary VPS.
2. Deploy the same Mailcow version.
3. Restore from backup.
4. Verify at least one mailbox (IMAP login and message visibility).

If you want a broader recovery mindset (runbooks, cutover, and verifying restores), adapt the checklist from Disaster recovery tutorial (2026) to your mail environment. Email is a business system; run it like one.

Updates and maintenance: how to keep Mailcow stable

Mailcow upgrades usually mean pulling updated container images and running the project’s update scripts from the Mailcow directory. That part is often painless.

The risk comes from treating upgrades like a casual chore.

Use a repeatable maintenance routine:

• Read release notes: focus on breaking changes and security fixes.
• Snapshot first: take a VPS snapshot (or filesystem snapshot) before a major upgrade.
• Upgrade in a window: warn your team and expect short IMAP reconnections.
• Watch logs after: confirm SMTP acceptance, outbound delivery, and queue health.

Keep the host OS current as well. Mail servers sit on the internet’s rough side, and patch lag attracts abuse.

For Ubuntu-based hosts, the workflow in Set Up Automated Security Updates on Ubuntu VPS is a sensible baseline (with reboots scheduled, not random).

Common pitfalls (and quick diagnostics)

Most Mailcow “bugs” are really environment issues. Run through these checks before you blame the stack.

• Wrong MX target: MX must point to a hostname (like mail.example.com) that has a correct A/AAAA record.
• No PTR/rDNS: outbound delivery suffers, and some servers reject outright.
• Port 25 blocked: some networks and some providers restrict outbound SMTP. If your VPS can’t deliver directly, you may need a relay (and correct SPF to include it).
• SPF failures from “helpful” records: marketing tools often ask you to add SPF includes; too many includes can exceed DNS lookup limits.
• Low disk space: mailboxes grow slowly… until they don’t. Set alerts and watch volume.

Quick checks you can run from your laptop:

• dig MX example.com +short to confirm MX.
• dig TXT example.com +short to confirm SPF/DMARC presence.
• openssl s_client -connect mail.example.com:465 -servername mail.example.com to confirm SMTPS TLS and certificate chain.
• openssl s_client -connect mail.example.com:993 -servername mail.example.com to confirm IMAPS TLS.

Where Mailcow fits in a real hosting setup

If you run websites and apps, email usually splits into two streams:

• Human email: inboxes, team mailboxes, and support addresses (Mailcow’s sweet spot).
• Application email: password resets, receipts, and notifications (often better through an SMTP relay or specialist sender).

A clean pattern is to run Mailcow on its own VPS and keep your web stack separate.

That way, a noisy PHP process can’t starve your mail queue. It also keeps a mail incident from taking down your storefront.

If you’re already planning a move, pair it with a DNS cutover plan. This helps you avoid losing inbound mail during propagation.

The steps in DNS Cutover Tutorial (2026) map well to mail migrations too: lower TTL, run in parallel, verify delivery, then switch.

FAQ: Self-hosting Mailcow for domain email

Do I need a dedicated IP to self-host Mailcow?

It’s strongly recommended. Many receivers weigh IP reputation heavily, and shared outbound IPs can inherit other senders’ problems. A dedicated IPv4 plus correct rDNS gives you a cleaner baseline.

Can I run Mailcow on the same VPS as my website?

You can, but it’s not ideal. Email has different risk and traffic patterns, and it needs stable resources. Separate VPS instances make troubleshooting and incident containment much simpler.

What’s the minimum DNS setup for good deliverability?

At minimum: correct A/MX, SPF, DKIM, DMARC, and PTR/rDNS. Then verify alignment and test sends to multiple providers before onboarding your whole team.

How do I back up Mailcow safely?

Back up mailbox data and configuration/state, then copy the backups offsite. Schedule restore drills on a temporary VPS so you know your backups are usable under pressure.

How often should I update Mailcow?

Check for updates regularly and apply security updates promptly, ideally in a maintenance window. Take a snapshot first, and validate inbound/outbound mail flow right after the upgrade.

Summary: the practical case for running your own email

If you want domain email hosting with hosted-style control—and you’re willing to own DNS hygiene and patch routines—Mailcow is one of the more operator-friendly ways to do it.

Put it on a properly sized VPS, publish SPF/DKIM/DMARC correctly, lock down the admin surface, and treat backups as a first-class feature.

When you’re ready to put it on stable infrastructure, start with a HostMyCode VPS and scale up as your mailbox count grows. If email is mission-critical and you want fewer operational surprises, managed VPS hosting is the calmer option.