Hosting Your Own Email Server on a VPS with Mailcow

Microsoft's price increase for Microsoft 365, effective 1 July 2026 — up to 43% depending on the plan was a wake-up call for many SMBs. An organization with 20 employees that was paying around €200 per month now faces bills of €285 or more, with no meaningful improvement in features. And that is not all: Microsoft has officially scheduled the shutdown of Exchange Web Services (EWS) for October 2026, making obsolete dozens of third-party integrations that relied on this protocol — shared calendars, CRM tools, in-house automations.

Faced with these pricing and technical disruptions, self-hosted email has returned to the conversation with renewed legitimacy. Hosting your own mail server on a VPS offers three major advantages: full cost control (a properly sized VPS costs between €15 and €40 per month for 20 to 50 mailboxes), data sovereignty (your messages do not transit through a hyperscaler's datacenters), and simplified GDPR compliance (you know exactly where your data is stored and processed). For law firms, healthcare professionals, communication agencies, or any organization handling sensitive data, this last argument is often decisive.

Before starting the installation, make sure your VPS and network configuration meet the following requirements. On the hardware side, the Mailcow documentation asks for at least 6 GB of RAM plus 1 GB of swap in the default configuration: below that, you are outside what the authors plan for, and the hungriest containers (antispam, antivirus, database) are the first to suffer. Plan for 2 vCPUs and at least 20 GB of disk space for containers and emails — 50 GB is a reasonable starting point for a small organization.

On the network side, several points are non-negotiable. First, port 25 must be open outbound: many hosting providers block it by default to fight spam. Check with your provider before ordering. Second, you must be able to configure the rDNS (reverse DNS / PTR record) for your IP: this allows recipient servers to verify that your IP actually maps to your mail hostname — without a correct PTR, your emails will land in spam at most major providers. Third, you need a domain name whose DNS you control (adding MX, A, and TXT records). Finally, a VPS running Debian 12 or Ubuntu 24.04 LTS is recommended for optimal compatibility with Docker and the Mailcow scripts. The Mailcow documentation lists Debian 11 to 13, Ubuntu 22.04 and newer, AlmaLinux 8 and 9, and Rocky Linux 9 as compatible; Alpine appears only with limited compatibility and manual adjustments.

A technically correct mail server can still have its messages land in spam if certain network and DNS conditions are not met. Here are the most common mistakes.

Blacklists: your VPS IP may be listed in blacklists like Spamhaus or Barracuda if it was previously used for spam — this is common with datacenter IP ranges. Check your IP on mxtoolbox.com/blacklists.aspx before installation. If listed, request delisting from each organization or switch IPs.

Port 25 blocked: some hosting providers block outbound port 25 on all new IPs for a probation period. Contact support before starting.

Missing or misconfigured DKIM: an email without a valid DKIM signature is treated with suspicion by Gmail and Outlook. Verify with dig TXT dkim._domainkey.yourdomain.com that the record is visible.

DMARC too permissive: start with p=none to collect reports without blocking, then move to p=quarantine and p=reject once you are confident all legitimate mail streams are covered by SPF and DKIM.

Missing PTR record: the most commonly forgotten point. Without a PTR record resolving to your mail hostname, Microsoft Outlook will reject your emails with a 550 error.

Migrating existing emails is often what holds organizations back. Mailcow includes IMAP sync jobs directly in its interface, making the operation accessible without advanced technical skills.

The basic procedure is: (1) create the destination mailboxes in Mailcow, (2) open *E-Mail Configuration → Synchronizations* in the admin interface (a user has the same tool under *User Settings → Sync Jobs*), (3) enter the host, port, username and password of the source server, choose the encryption — TLS usually fits port 143, SSL fits port 993, and PLAIN is strongly discouraged — then enable the job. It copies messages folder by folder. The migration can be run multiple times before the final cutover (already-copied messages are skipped on subsequent passes), enabling a progressive cutover: you continue receiving mail on the old address while data migrates, then switch the MX record in a single operation. Once the switch is done, disable or delete the job.

For Microsoft 365, do not count on EWS: according to Microsoft's documentation, it starts being disabled for all organizations in October 2026 and will be fully disabled in April 2027, so migration tools that rely on it will stop working. Mailcow uses IMAP, not EWS, and is therefore unaffected — yet another reason to migrate early.

For email clients, Thunderbird, Apple Mail, and mobile apps (iOS, Android) configure via standard IMAP/SMTP. Outlook works too, including calendar and contact sync via ActiveSync (SOGo).

Mailcow is not the only Docker-based self-hosted email solution. Here is how it compares to its main competitors.

Mailu is lighter on resources (runs with 1 GB of RAM) and suits personal use or very small organizations. Its interface is minimalist, it does not include SOGo, and its feature set is more limited. It is an excellent choice when simplicity is a priority over features.

iRedMail is a mature solution, available as a community edition and a paid Pro version (iRedMail Pro). It supports multiple database backends (MySQL, PostgreSQL, LDAP) and installs directly on the host system without Docker. Its configuration curve is steeper, and updates are less automated. iRedMail Pro adds a paid web management interface that competes with Mailcow's.

Mailcow stands out for the richness of its features, the quality of its administration interface, the frequency of its updates (monthly releases), and the size of its community (13,200+ GitHub stars). It is the natural choice for an SMB that wants a complete, actively maintained solution with abundant documentation. The trade-off is RAM consumption: 6 GB minimum is a non-negotiable requirement.

Mailcow publishes one release per month, and its tag carries the year and month (2026-10 for the one of 21 October 2026). They fix security vulnerabilities, improve spam filters, and add features. The official update procedure is straightforward and well-documented.

From the /opt/mailcow-dockerized directory, run ./update.sh. This script pulls the new Docker images, applies any configuration migrations, and restarts the affected containers. The operation typically takes 5 to 15 minutes with less than a minute of service interruption for the restarted containers.

Do not use Watchtower (the automatic Docker container update tool) with Mailcow. Mailcow updates sometimes involve database migrations or configuration changes that require running update.sh in the correct order. Letting Watchtower pull and restart images autonomously can corrupt your installation.

Schedule updates during a known maintenance window (for example, Saturday morning), read the release note on the Mailcow repository's releases page before applying, and verify container status with docker compose ps after each update. Take a full backup right before each update. When the release is a security update, do not wait: the next section gives the emergency procedure.

Mailcow is not a PHP application sitting on your system: it ships its own PHP, in the php-fpm-mailcow container, which runs the admin interface. Your distribution's PHP fixes therefore do not apply to it, and an apt upgrade on the VPS changes nothing about the version Mailcow uses. That is what prompted thread #7533, opened on 21 October 2026 under the title "[UPDATE NOW] PHP RCE Vulnerability (CVE-2026-109618 and CVE-2026-109619)": administrators there ask for a fix from Mailcow itself. Both flaws are detailed in our article [PHP2Shell: fixing CVE-2026-109618 and CVE-2026-109619](/blog/php2shell-cve-2026-109618-109619-mettre-a-jour-php).

On the version side, the 2026-10 release, published on 21 October 2026, is titled "Security Update: PHP 8.2.35, SOGo 5.12.12 & Nginx 1.30.6". Its notes do not cite the CVE numbers: the link is made through the PHP version, since 8.2.35 is the fixed version of the 8.2 branch in the PHP project's advisory of the same day, and the phpfpm image shipped with that release carries the tag 8.2.35-1. Read the release note before acting: a newer release may have changed these numbers.

On a VPS that already hosts other Docker containers, the netfilter-mailcow container can start restarting endlessly. The visible symptom: the web interface stops responding, the unbound-mailcow container is reported as failing ("dependency failed to start: container mailcowdockerized-unbound-mailcow-1 is unhealthy") and netfilter's logs repeat "MAILCOW target not found in ip forward table, restarting container to fix it...".

Reported cause: at startup, netfilter checks the position of its MAILCOW chain in the FORWARD table. According to thread #6795, the code in NFTables.py assumes the chain sits in first position and places it by insertion; if Docker has already created its own chains, the check fails, the container exits, and each restart adds one more MAILCOW jump. In #6995, one participant counts more than 9,000 of them, and another describes the same effect after a Docker update on Debian.

What we know about the status: #6795, opened in September 2025, was closed as "not planned" in December 2025 after a "stale" label; #6995, opened in January 2026, was closed the same way in October 2026. No maintainer confirms a fix there, and one participant believes the root cause needs a refactor. What follows is therefore a community workaround, not an official procedure.

Self-hosting email is not a universal answer. There are situations where Google Workspace or Microsoft 365 remains the more sensible choice, even after the price increase.

If you lack in-house technical expertise: managing a mail server requires regular security monitoring, proactive updates, and the ability to diagnose deliverability issues. Without these skills, you risk being left without email during a critical incident.

If deliverability is absolutely critical: large-scale transactional email operations (banks, insurers, high-volume e-commerce platforms) benefit from the reputation of shared IPs professionally managed by ESPs (Mailgun, Postmark, Brevo). A solo VPS starts with a fresh IP whose reputation must be built from scratch.

If your hosting provider blocks port 25: some cloud operators (particularly on entry-level plans) permanently block this port to combat spam. Verify before committing.

If you operate in a strictly regulated industry: some sectors (finance, healthcare) impose certification or audit requirements for email infrastructure that can be difficult to satisfy with self-hosting without specialized support.

Self-hosting your email server with Mailcow on a VPS is now within reach of any organization with a minimum of technical maturity. The solution is mature, actively maintained, and delivers a functional level that honestly competes with commercial offerings — at a fraction of the cost.

Microsoft 365's price increase and the end of EWS in 2026 have transformed self-hosting from a fringe option into a strategic alternative for thousands of SMBs and agencies. With a properly sized VPS (6 GB RAM, dedicated IP with configured rDNS), a Mailcow installation takes less than an hour, and the migration of existing mailboxes can be done progressively without service interruption.

Three things to remember before getting started: verify that port 25 is open with your hosting provider, configure the PTR record for your IP before sending your very first email, and set up external backups from day one. With these foundations in place, your email server will be just as reliable — and far more cost-effective — than a cloud subscription.

Add a fourth reflex to these three: Mailcow carries its own PHP, so every PHP security advisory is handled with ./update.sh followed by a check inside the container, as with PHP2Shell in October 2026.