Mailcow Dockerized : stack mail self-hosted complète et maintenable

Self-host son mail en 2026, ça reste possible. Pas confortable, mais possible. Le sujet revient à chaque fois qu'une boîte tape contre les limites de Microsoft 365 (coût utilisateur, conformité RGPD) ou de Google Workspace (souveraineté, audit, ingestion data). Mailcow Dockerized est aujourd'hui la stack auto-hébergée la plus mature pour cette migration.

Pas un fork de Postfix, pas un produit propriétaire emballé. C'est un assemblage Docker Compose de composants open source connus : Postfix pour le SMTP, Dovecot pour l'IMAP/POP3, Rspamd pour l'antispam, ClamAV pour l'antivirus, SOGo pour le webmail et la collaboration, ACME pour les certificats, MySQL pour la base, Redis pour le cache, Nginx en frontend. L'ensemble est packagé proprement avec des scripts de build, de mise à jour et de sauvegarde.

L'intérêt côté ops : on opère un mail serveur de prod sans réinventer chaque pièce. Le coût : il faut comprendre ce que fait chaque conteneur, et accepter que le mail sortant reste un sujet politique (réputation IP, deliverability vers Gmail et Outlook).

• Pourquoi Mailcow plutôt qu'autre chose
• Architecture des 18 conteneurs
• Prérequis hardware, réseau, DNS
• Déploiement initial et premier mail
• Configuration anti-abus et deliverability
• Opérations courantes : backup, update, scale
• Limites connues et signaux d'alerte

Trois alternatives sérieuses circulent.

Postfix + Dovecot + Rspamd à la main reste l'école classique. On comprend tout, on contrôle tout. Coût : maintenance lourde, on réinvente le tooling backup, monitoring, webmail, ACME.

Stalwart est l'option moderne tout-en-un en Rust. Maturité réelle, mais l'écosystème de plugins, la doc et les retours prod sont encore plus jeunes que Mailcow.

iRedMail et Mailu existent. iRedMail est solide mais moins actif. Mailu est plus jeune avec moins de retours prod.

Mailcow gagne sur trois axes :

• Communauté large, doc mature, channel Telegram réactif.
• Releases régulières, intégration ACME native, support des standards modernes (DKIM, DMARC, ARC, MTA-STS, TLS-RPT).
• Surface "tout-en-un" qui rend la prod opérable par une équipe qui n'est pas dédiée mail-only.

Pour une PME qui veut sortir de M365 ou un éditeur SaaS qui veut un MX souverain, Mailcow est le défaut raisonnable en 2026.

Une installation Mailcow standard fait tourner 18 à 20 conteneurs. Vue rapide :

Le fichier mailcow.conf centralise les variables. Le docker-compose.yml est versionné et patché par script à chaque update. On ne le modifie pas à la main : on utilise docker-compose.override.yml pour les surcharges locales.

Pour un opérateur qui sort de Postfix/Dovecot manuel, la transition mentale prend une journée. Pour quelqu'un qui n'a jamais opéré du mail, prévoir une à deux semaines de courbe d'apprentissage.

Hardware : 6 Go de RAM minimum, 8 Go confortable, 16 Go si Solr et 200+ comptes. CPU 2 coeurs minimum, 4 confortable. Disque : SSD obligatoire, prévoir taille maildir + DB + Solr index. Pour 50 utilisateurs avec 5 Go de quota chacun, prévoir 300 Go utiles.

Réseau : IPv4 publique propre. Une IP "résidentielle" ou avec PTR générique sera blacklistée d'office par Spamhaus, Microsoft et UCEPROTECT. C'est rédhibitoire. Pour une boîte qui sort sur du dédié OVH, Scaleway, Hetzner, vérifier l'historique de l'IP avant déploiement (mxtoolbox, dnsbl.info).

DNS : la liste minimale.

mail.exemple.fr.        IN A      203.0.113.42
mail.exemple.fr.        IN AAAA   2001:db8::42
exemple.fr.             IN MX 10  mail.exemple.fr.
exemple.fr.             IN TXT    "v=spf1 mx -all"
default._domainkey.exemple.fr.  IN TXT  "v=DKIM1; k=rsa; p=..."
_dmarc.exemple.fr.      IN TXT    "v=DMARC1; p=quarantine; rua=mailto:dmarc@exemple.fr"
_mta-sts.exemple.fr.    IN CNAME  ...

Le PTR (reverse DNS) sur l'IP doit pointer mail.exemple.fr. Sans PTR aligné, deliverability cassée vers Microsoft. La gestion DNSSEC complète est documentée dans notre guide DNSSEC.

Le flux nominal :

git clone https://github.com/mailcow/mailcow-dockerized
cd mailcow-dockerized
./generate_config.sh
# Saisir hostname, ex: mail.exemple.fr
docker compose pull
docker compose up -d

Sur un VPS basique 4 coeurs / 8 Go, l'install prend 8 à 15 minutes. L'admin web sort sur https://mail.exemple.fr avec couple par défaut admin / moohoo (à changer immédiatement).

Étapes ordonnées juste après :

1. Changer le mot de passe admin et activer la 2FA TOTP.
2. Ajouter le domaine exemple.fr, créer une boîte de test.
3. Vérifier la génération automatique du certificat ACME (acme-mailcow doit logguer "issued and installed"). Pour les domaines en split DNS, voir DNS-01 via Cloudflare.
4. Récupérer la clé DKIM dans l'UI, la pousser en TXT DNS.
5. Tester l'envoi entrant via mail-tester.com et l'envoi sortant via une boîte Gmail externe.
6. Activer ARC, MTA-STS, TLS-RPT depuis l'UI Rspamd.
7. Configurer le backup (voir plus bas).

Tester avant de migrer une boîte de prod. Toujours.

C'est la partie qui distingue un MX qui survit d'un MX qui se fait bannir au bout de trois jours.

Côté entrée (anti-spam), Rspamd applique par défaut un score baseline avec RBL Spamhaus, SURBL, DKIM/SPF/DMARC validation, et un filtre bayésien apprenant. On peut affiner les seuils dans rspamd-mailcow via l'UI. Activer phishtank et urlhaus pour les RBL URL.

Côté sortie (deliverability), trois leviers.

• DKIM signing propre, clé 2048 bits, rotation annuelle.
• SPF strict avec -all, jamais ~all sur un domaine de prod.
• DMARC progressif : p=none pendant deux semaines pour collecter les rapports rua=, puis p=quarantine, puis p=reject après vérification.

Rate limiting sortie. Mailcow expose un ratelimit par compte dans l'UI. Limiter à 100 messages par minute par défaut évite qu'un compte compromis ne brûle la réputation IP en spammant 50 000 messages. Le rate limit global sortie est aussi configurable.

Monitoring deliverability. Forcer un compte dmarc@exemple.fr qui reçoit les rapports rua quotidiens, et un dashboard qui en extrait les volumes refus. Un signal d'alerte fiable : un pic de bounces vers Outlook = on est probablement listé. Réagir sous 24h.

Pour le hardening conteneur global, nos articles hardening Docker et profils de sécurité Docker restent applicables au stack Mailcow.

Backup. Mailcow fournit helper-scripts/backup_and_restore.sh. Trois cibles à sauvegarder :

• volumes Docker (vmail, MySQL dump, Redis dump, postfix queue, Rspamd data, SOGo data)
• configuration (mailcow.conf, docker-compose.override.yml, certificats ACME)
• DKIM keys (Redis ou export Rspamd)

Backup nightly vers du S3 distant (MinIO local ou cloud) avec rétention 30 jours quotidiens + 12 mensuels. Aligner sur stratégie 3-2-1 avec une copie offline immutable. Tester la restauration trimestriellement, sinon le backup n'existe pas.

Update. update.sh fait le travail : git pull, regénère le compose, pull les nouvelles images, redémarre les conteneurs touchés. Toujours faire un snapshot ZFS ou volume avant. Lire le changelog GitHub avant les majors.

Scale. Mailcow standard tient confortablement jusqu'à 200-500 comptes sur un serveur correct. Au-delà, deux options : scale verticalement (plus de RAM, NVMe rapide) ou découper par domaine sur plusieurs instances. Le multi-noeud Mailcow n'est pas natif, c'est une limite assumée du projet.

Monitoring. Exposer les métriques Prometheus du watchdog, alerter sur mailq qui grossit, sur taux DKIM-fail entrant, sur disques volumes >85%. Intégrer dans un stack Prometheus + Grafana classique.

À documenter avant l'engagement.

Pas de HA native. Une instance Mailcow = un serveur. La HA passe par DRBD + bascule manuelle ou par un MX backup tiers, pas par du failover automatique multi-noeud.

Réputation IP. Si l'IP est neuve, compter 4 à 8 semaines pour atteindre la deliverability cible (Microsoft est le plus lent à warmup). Pendant cette période, alimenter avec du trafic légitime progressif, surveiller chaque rapport DMARC.

Microsoft 365 reste capricieux. Même avec SPF/DKIM/DMARC verts, des messages sortants peuvent atterrir en Junk Outlook sans raison documentée. Ouvrir un ticket SNDS et vérifier qu'on est sur la JMRP est utile mais lent.

Charge SOGo. Le webmail consomme. Si la majorité des utilisateurs ouvrent SOGo en permanence, dimensionner CPU/RAM en conséquence ou imposer des clients IMAP natifs.

Mises à jour majeures. Les changements de schéma MySQL Mailcow ont par le passé demandé des interventions manuelles. Toujours snapshot avant, et lire le changelog.

Sur les déploiements qu'on opère pour nos clients souverains, Mailcow couvre 80% des cas (PME, agences, éditeurs). Pour les 20% restants (très haute charge, multi-pays, exigence HA stricte), on bascule sur du Postfix custom avec architecture relais ou sur une plateforme commerciale spécialisée. Si vous évaluez un Mailcow de prod et que vous voulez sécuriser le déploiement (DNS, IP, deliverability, runbook restauration) sans découvrir les écueils en live, on peut auditer la cible et opérer la mise en production sur l'infrastructure que vous avez choisie.

• Mailcow documentation officielle : référence pour install, ops, troubleshooting.
• GitHub mailcow/mailcow-dockerized : code, releases, issues actives.
• Rspamd documentation : moteur antispam au coeur de Mailcow.
• DMARC.org guide : référence DMARC, ARC, TLS-RPT.
• M3AAWG sender best practices : pratiques deliverability validées par l'industrie.
• MTA-STS RFC 8461 : spécification du standard de transport TLS strict.