📍 Article principal : Mailcow vs Mailu vs Stalwart pour PME. Ce tutoriel guide pas à pas le déploiement Mailcow sur un VPS Hetzner avec Coolify et Caddy comme reverse-proxy.
Mailcow est le choix de référence pour une PME ouest-africaine qui démarre l’auto-hébergement de sa messagerie. Sa stack Docker complète, son interface française d’administration et son écosystème SOGo intégré offrent une expérience proche de Microsoft 365 sans abonnement mensuel. Ce tutoriel pose le déploiement complet sur un VPS Hetzner CCX13 avec Coolify pour l’orchestration et Caddy pour les certificats Let’s Encrypt automatiques. À la fin, la PME dispose d’un serveur de messagerie professionnel en moins de quatre heures, prêt à recevoir ses utilisateurs.
Prérequis
- VPS Hetzner CCX13 fraîchement provisionné (4 vCPU, 16 Go RAM, 80 Go SSD minimum)
- Domaine principal de la PME (par exemple masociete.sn) avec accès aux DNS
- Sous-domaine mail.masociete.sn pointé vers l’IP publique du VPS
- Accès SSH durci en clé Ed25519
- Niveau : intermédiaire
- Temps estimé : 3 à 4 heures
Étape 1 — Vérifier les prérequis réseau
Avant tout déploiement, vérifier que les ports email sortants ne sont pas bloqués par l’hébergeur. Hetzner bloque par défaut le port 25 (SMTP sortant) sur les nouveaux comptes pour limiter le spam — il faut ouvrir un ticket support qui valide l’identité du client et débloque le port en quelques heures. Le port 25 est strictement nécessaire pour envoyer des courriels vers d’autres serveurs (Gmail, Microsoft, etc.). Sans ce déblocage, le serveur reçoit les messages mais ne peut pas en envoyer.
Configurer aussi le reverse DNS (PTR) du VPS pour qu’il pointe vers mail.masociete.sn. Cette opération se fait dans le panel Hetzner Console pour chaque IP. Sans reverse DNS correct, les serveurs Gmail et Microsoft rejettent automatiquement les courriels comme spam — paramètre non négociable. Vérifier avec dig -x <ip-vps> que le reverse DNS retourne bien le FQDN attendu avant de continuer.
Configurer enfin le DNS du domaine. Créer les enregistrements suivants : A pour mail.masociete.sn vers l’IP publique, MX pour masociete.sn vers mail.masociete.sn avec priorité 10, A ou CNAME pour autoconfig.masociete.sn et autodiscover.masociete.sn (autoconfiguration des clients). Les enregistrements SPF, DKIM, DMARC se configureront plus tard, après l’installation Mailcow.
Étape 2 — Préparer le VPS et installer Coolify
Sur le VPS fraîchement provisionné, créer un compte admin non-root, désactiver l’authentification SSH par mot de passe, ouvrir uniquement les ports SSH custom, 25 SMTP, 80 HTTP, 110 POP3, 143 IMAP, 443 HTTPS, 465 SMTPS, 587 submission, 993 IMAPS, 995 POP3S. Activer Fail2ban avec une politique stricte sur SSH et SMTP. Ces opérations de durcissement basique évitent que les bots automatiques compromettent le serveur dans les premières heures de production.
Installer ensuite Coolify avec la commande officielle curl -fsSL https://cdn.coollabs.io/coolify/install.sh | sudo bash. Le script déploie Docker, Docker Compose, Caddy reverse-proxy et l’interface Coolify sur le port 8000. Après cinq minutes, accéder à http://<ip-vps>:8000, créer le compte administrateur initial, configurer le domaine principal Coolify (par exemple coolify.masociete.sn) qui servira ensuite à publier les services via Caddy.
Étape 3 — Déployer Mailcow via Docker Compose
Mailcow propose un script d’installation officiel qui génère le fichier mailcow.conf personnalisé selon les paramètres du déploiement. Cloner le dépôt GitHub officiel et lancer le générateur de configuration.
git clone https://github.com/mailcow/mailcow-dockerized /opt/mailcow cd /opt/mailcow ./generate_config.sh # Renseigner mail.masociete.sn comme FQDN # Choisir le timezone Africa/Dakar ou Africa/Abidjan
Le fichier mailcow.conf contient toutes les variables clés : FQDN, mots de passe générés, ports exposés, options de fonctionnalités (Watchdog, Skip ClamAV pour économiser RAM, etc.). Pour une PME modeste, désactiver SOLR (recherche full-text avancée) et limiter ClamAV à 1 Go de mémoire suffit largement et libère de la RAM pour les autres services.
Lancer ensuite le déploiement : docker compose pull && docker compose up -d. Le téléchargement initial des images prend quelques minutes selon la bande passante. Une fois tous les conteneurs démarrés, l’interface admin de Mailcow est accessible sur https://mail.masociete.sn/ avec les identifiants par défaut admin / moohoo. Première action obligatoire : changer ce mot de passe immédiatement.
Étape 4 — Configurer le premier domaine et la première boîte
Dans l’interface admin Mailcow, naviguer dans Configuration → Domaines, ajouter masociete.sn comme domaine principal. Définir le quota par défaut par boîte (par exemple 10 Go), activer le webmail SOGo, valider. Le domaine apparaît dans la liste avec un statut « actif ». Mailcow génère automatiquement la clé DKIM associée — la copier pour la publier ensuite dans le DNS.
Créer ensuite la première boîte utilisateur dans Configuration → Boîtes : nom complet, adresse mail (par exemple contact@masociete.sn), mot de passe fort généré aléatoirement, quota personnalisé si nécessaire. La boîte est immédiatement accessible via webmail SOGo sur https://mail.masociete.sn/SOGo/ et via IMAP/SMTP depuis n’importe quel client (Outlook, Thunderbird, Apple Mail, application mobile). L’autoconfiguration via les enregistrements DNS autoconfig et autodiscover permet aux clients de se configurer automatiquement avec juste l’email et le mot de passe.
Étape 5 — Configurer SPF, DKIM, DMARC dans le DNS
Sans configuration SPF/DKIM/DMARC, les courriels sortants finissent en spam chez les destinataires Gmail et Microsoft. Trois enregistrements DNS à publier au niveau du domaine principal. SPF (TXT à la racine) déclare quelles IP sont autorisées à envoyer des courriels au nom du domaine : v=spf1 mx ~all autorise les serveurs MX déclarés. DKIM (TXT sur un sélecteur dédié) publie la clé publique générée par Mailcow pour signer les courriels — la clé est visible dans Configuration → Domaines → DKIM. DMARC (TXT sur _dmarc) définit la politique en cas d’échec SPF ou DKIM.
; SPF masociete.sn. TXT "v=spf1 mx ~all" ; DKIM (sélecteur dkim, clé publique fournie par Mailcow) dkim._domainkey.masociete.sn. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgk..." ; DMARC en mode quarantine progressif _dmarc.masociete.sn. TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@masociete.sn; pct=100"
Démarrer DMARC en mode none (monitoring uniquement) pendant deux à quatre semaines pour collecter les rapports et identifier d’éventuels usages légitimes oubliés (newsletter, notifications, services tiers). Une fois les rapports stables, basculer en quarantine puis reject pour la protection maximale. Le tutoriel délivrabilité dédié détaille cette progression.
Étape 6 — Vérifier la délivrabilité avec mail-tester
L’outil mail-tester.com propose un score de délivrabilité gratuit. Envoyer un email de test depuis la nouvelle boîte vers l’adresse fournie par mail-tester, attendre quelques secondes, consulter le score. Cible : 9 ou 10 sur 10. Les points perdus typiques : SPF mal configuré, DKIM signature absente, contenu trop pauvre (un email vide est suspect), reverse DNS manquant. Corriger chaque point identifié avant la mise en production réelle.
Tester aussi l’envoi vers Gmail et Microsoft 365 avec des comptes externes. Vérifier que le message arrive dans la boîte de réception et non dans le dossier Spam. Si le message tombe en spam malgré une bonne configuration, c’est probablement un problème de réputation IP — démarrer doucement avec quelques messages par jour, monter progressivement le volume sur deux à quatre semaines. Cette phase de warmup de la réputation IP est cruciale et souvent négligée.
Erreurs fréquentes
| Erreur | Cause | Solution |
|---|---|---|
| Port 25 SMTP bloqué | Politique anti-spam Hetzner par défaut | Ouvrir un ticket support Hetzner pour déblocage |
| Reverse DNS générique (static.X.Y.Z) | PTR par défaut hébergeur | Configurer manuellement vers mail.masociete.sn dans le panel |
| Certificat Let’s Encrypt non délivré | DNS non propagé | Vérifier dig avant le déploiement, attendre 1h en cas de rate-limit |
| Conteneurs ClamAV qui crashent | Mémoire insuffisante | Désactiver ClamAV ou monter le VPS en CCX13 minimum |
| Webmail SOGo très lent | Index SOLR non optimisé | Réindexer SOGo ou désactiver SOLR si non utilisé |
Adaptation au contexte ouest-africain
Pour les déploiements souverains au Sénégal ou en Côte d’Ivoire, la procédure reste identique mais quelques adaptations valent la peine. D’abord, vérifier que l’hébergeur local n’a pas de blocage SMTP — la plupart sont moins restrictifs que Hetzner mais demandent quand même validation. Ensuite, configurer un fallback DNS via Cloudflare ou un autre fournisseur fiable : les DNS opérateurs locaux peuvent avoir des indisponibilités ponctuelles qui rendent le serveur injoignable. Enfin, prévoir un backup MX en Europe pour absorber les courriels entrants pendant les éventuelles coupures du serveur principal — Hetzner peut justement servir de backup secondaire pour un déploiement principal au Sénégal.
Sauvegarde et plan de restauration
Une instance Mailcow sans sauvegarde testée est un château de sable. Mailcow propose un script backup_and_restore.sh dans le dépôt qui sauvegarde l’ensemble : configurations, base de données MariaDB, queue Postfix, vmail (les boîtes utilisateur), Redis. Lancer ce script chaque nuit via cron, archiver le résultat avec Restic vers Hetzner Storage Box ou un bucket S3 chiffré. La rétention recommandée : 14 jours quotidiens, 8 hebdomadaires, 12 mensuels — soit deux ans d’historique grâce à la déduplication Restic.
Tester la restauration sur un VPS bac à sable au moins une fois par trimestre. La procédure complète : provisionner un nouveau VPS, installer Coolify, cloner Mailcow, restaurer les volumes Docker depuis Restic, redémarrer les conteneurs. Une PME bien préparée tient le RTO sous 90 minutes. Sans ces tests, l’incident réel se déroule dans la panique avec un risque significatif de perte de données. Documenter chaque test avec timestamp et observations dans un journal qui devient précieux pour les audits qualité.
Mises à jour et maintenance
Mailcow publie des mises à jour fréquentes — correctifs de sécurité tous les mois, mises à jour mineures plusieurs fois par an. La procédure tient en trois commandes : ./update.sh -c vérifie les changements à venir, ./update.sh applique la mise à jour avec sauvegarde automatique préalable, ./update.sh --gc nettoie les anciennes images Docker. La fenêtre de coupure tient en moins de cinq minutes sauf cas exceptionnel.
Tester systématiquement les mises à jour majeures sur un VPS bac à sable avant la production. Les mises à jour Mailcow incluent parfois des migrations de base de données ou des changements de configuration qui demandent une attention particulière. Pour les déploiements critiques, attendre une à deux semaines après chaque release pour laisser la communauté identifier d’éventuels problèmes. Suivre le canal officiel Telegram et le forum Mailcow pour rester informé des éventuels correctifs urgents.
Monitoring et alerting
Un serveur email demande une supervision continue. Configurer Uptime Kuma pour surveiller cinq dimensions. Premier : santé HTTPS du webmail (vérification toutes les minutes). Deuxième : santé SMTP via une connexion TCP sur le port 25 et 587. Troisième : santé IMAP sur le port 993. Quatrième : certificat Let’s Encrypt qui doit rester valide (alerte 30 jours avant expiration). Cinquième : utilisation disque qui doit rester sous 80 %.
Pour le monitoring applicatif fin, intégrer le module Mailcow Watchdog qui surveille en interne chaque composant et redémarre automatiquement les services en panne. Activer aussi les alertes via webhook Discord, Telegram ou e-mail externe (sur une autre infrastructure pour éviter le piège auto-référent). Cette double couche supervision externe et watchdog interne offre une fiabilité opérationnelle digne d’une infrastructure professionnelle, accessible à n’importe quelle PME.
Configurer SOGo et calendrier partagé
SOGo, intégré nativement dans Mailcow, fournit un webmail riche avec calendrier et carnet d’adresses partageables entre utilisateurs. La configuration par défaut est fonctionnelle mais quelques ajustements améliorent l’expérience. Activer le partage CalDAV pour que les calendriers d’équipe soient consultables depuis Outlook, Apple Calendar ou Google Calendar via les protocoles standards. Configurer les invitations de réunion automatiques par email, avec rappels SMTP intégrés.
Pour les PME qui veulent un look plus moderne que SOGo, deux alternatives intégrables : Roundcube qui offre une interface plus légère et personnalisable, ou Cypht qui propose une expérience radicalement différente avec multi-comptes natifs. Ces alternatives se déploient en parallèle de SOGo dans des conteneurs Coolify additionnels — chaque utilisateur peut choisir son webmail favori selon ses préférences.
Bonnes pratiques opérationnelles
Au-delà du déploiement initial, plusieurs pratiques opérationnelles maintiennent un Mailcow en bonne santé sur la durée. Tenir à jour la liste des comptes utilisateurs en synchronisation avec les RH : désactiver immédiatement les comptes des anciens collaborateurs, archiver leurs courriels selon la politique de rétention. Auditer trimestriellement les permissions et les groupes pour détecter les configurations obsolètes accumulées au fil des arrivées et départs.
Établir une politique de mots de passe stricte : minimum 14 caractères, rotation annuelle obligatoire, interdiction des 100 mots de passe les plus communs. Activer 2FA SOGo pour les comptes sensibles (direction, finance, RH). Ces mesures simples préviennent l’écrasante majorité des compromissions de comptes par bruteforce ou phishing. Pour les services qui veulent passer au niveau supérieur, intégrer un SSO Keycloak qui centralise la sécurité d’authentification pour tous les services de la PME, pas seulement la messagerie.
Pour aller plus loin
🔝 Retour à l’article principal : Mailcow vs Mailu vs Stalwart pour PME. La suite logique aborde la délivrabilité avancée — SPF, DKIM, DMARC, MTA-STS, ARC, BIMI — sujet du tutoriel suivant. Documentation officielle Mailcow : docs.mailcow.email, dépôt GitHub : github.com/mailcow/mailcow-dockerized.
Documenter en interne le déploiement effectué : version Mailcow installée, paramètres choisis, mots de passe stockés en coffre, contacts du prestataire, procédure de mise à jour. Cette documentation devient précieuse trois ans plus tard quand un nouvel administrateur reprend le serveur ou quand la PME doit migrer vers une nouvelle version majeure. Sans ce travail simple, le savoir-faire reste fragile et personnel — avec lui, la plateforme email devient un actif transmissible et durable.