Mailcow : l'email open source auto-hébergé qui remplace Google Workspace

On a déporté beaucoup de choses chez les hyperscalers américains sans trop se poser de questions. Les fichiers sont partis chez Dropbox, la visio chez Zoom, le CRM chez Salesforce. Puis on a commencé à rapatrier : Nextcloud pour les fichiers, Jitsi pour la visio, Dolibarr ou des ERP européens pour le CRM. Il reste un morceau, souvent le dernier qu'on ose toucher : la messagerie.

C'est aussi le plus sensible. Chaque email envoyé à un collègue transite par Google ou Microsoft, chaque pièce jointe s'accumule dans leurs data centers, chaque utilisateur est facturé au même tarif sur le bulletin mensuel. Et le Cloud Act américain n'a pas disparu : un juge fédéral peut exiger l'accès à vos emails, même stockés en Europe, dès lors que le prestataire est américain.

Mailcow est aujourd'hui la meilleure réponse technique à ce problème. Voici ce que c'est, comment ça se compare à Google Workspace et Microsoft 365, et comment on migre sans tout casser.

Pourquoi l'email est le dernier bastion à reprendre

L'argument financier saute aux yeux quand on fait l'addition. Pour une PME de 30 personnes, ce sont près de 4 500 € par an qui partent chez un fournisseur étranger, pour un service que vous ne contrôlez pas.

L'argument juridique est plus profond. Le Cloud Act (2018) permet aux autorités américaines de réclamer vos données à Google, Microsoft ou AWS, peu importe où le data center est localisé. Le FISA 702 permet une surveillance électronique de masse sur les entreprises étrangères. La CNIL et le Comité européen de la protection des données (EDPB) ont répété à plusieurs reprises que l'utilisation de services cloud américains pour des données personnelles pose un problème de conformité RGPD. Notre article Cloud Act et RGPD détaille le raisonnement.

L'argument opérationnel, enfin. Vos échanges internes, vos devis, vos contrats, vos échanges avec vos avocats, tout passe par là. C'est la base de données la plus sensible de l'entreprise. La laisser chez un tiers américain n'est pas une option neutre.

Mailcow, c'est quoi exactement ?

Mailcow (plus précisément mailcow: dockerized) est une suite serveur mail open source, maintenue par la société allemande Servercow EU SE, basée en Rhénanie-du-Nord-Westphalie. Le code est publié sous licence GPLv3 sur GitHub (mailcow/mailcow-dockerized), avec des releases fréquentes, généralement plusieurs par mois. Le rythme de mise à jour est l'un des points forts du projet : les patchs de sécurité Postfix, Dovecot ou Rspamd sont typiquement intégrés dans les jours qui suivent leur publication amont.

Techniquement, c'est un orchestrateur de stack mail : un docker-compose.yml qui assemble une dizaine de conteneurs coopérant pour fournir un serveur mail complet, prêt à l'emploi.

Les badges de la stack :

Postfix Dovecot SOGo Rspamd ClamAV Redis MariaDB nginx Unbound acme-mailcow

Les composants assemblés

• Postfix : le MTA (Mail Transfer Agent) qui gère l'envoi et la réception SMTP.
• Dovecot : le serveur IMAP/POP3/ManageSieve qui stocke et sert les boîtes aux clients.
• SOGo : le webmail, qui fournit aussi un serveur CalDAV, CardDAV et ActiveSync (EAS) nativement intégrés.
• Rspamd : le moteur antispam (filtrage bayésien, scoring, greylisting, DKIM/ARC signing).
• ClamAV : l'antivirus, optionnel mais activé par défaut.
• Redis : cache pour Rspamd, SOGo et les sessions.
• MariaDB : base de données de configuration et de métadonnées.
• nginx : reverse proxy HTTP/HTTPS pour SOGo, l'UI admin et les endpoints publics.
• Unbound : résolveur DNS récursif local avec DNSSEC, pour valider les enregistrements SPF, DKIM et DMARC des messages entrants.
• acme-mailcow : client Let's Encrypt intégré pour les certificats TLS.

Un point important : le support ActiveSync (pour les iPhone, Android natifs et Outlook mobile) est fourni par SOGo directement, pas par Z-Push ou DavMail. SOGo implémente ActiveSync nativement (protocole Exchange), ce qui évite une couche de traduction supplémentaire et donne une expérience plus stable sur mobile.

Les features qui comptent pour une PME

Mailcow vs Google Workspace vs Microsoft 365

Le vrai sujet quand on évalue une migration, c'est de comparer sur les bons critères. Voici le match sur les points qui intéressent un DSI et un dirigeant PME.

Notre position : Mailcow gagne sur la souveraineté, le coût au-delà de 10 utilisateurs, l'ouverture des protocoles. Il perd sur l'intégration suite bureautique clef-en-main (Docs, Sheets), et sur l'écosystème d'applications tierces. Pour une PME qui veut une messagerie pro robuste et souveraine, et qui accepte de composer sa suite avec du Nextcloud ou de l'OnlyOffice à côté, le compte est clair.

Architecture technique et dimensionnement

Mailcow tourne sur un serveur Linux standard (Debian, Ubuntu, Rocky) avec Docker et docker-compose. La config officielle minimale est un VM avec 6 Go de RAM, 2 vCPU et 20 Go de disque pour l'OS, plus le stockage des boîtes. En pratique, ces chiffres sont minimalistes : ClamAV mange 1 à 2 Go à lui tout seul, et pour une utilisation confortable à 20-30 utilisateurs actifs, on recommande plutôt 8 Go de RAM et 4 vCPU.

Dimensionnement réel observé

Sur nos clusters Proxmox, on déploie chaque instance Mailcow en VM dédiée, avec son volume sur stockage Ceph NVMe en réplica 3. Chaque instance a sa propre IP publique, sa propre réputation d'envoi, son propre reverse DNS. Pas de mutualisation des IPs sortantes, c'est une erreur classique qui fait plonger la délivrabilité quand un client envoie un burst mal fichu.

Haute disponibilité multi-nœuds

Mailcow n'est pas conçu nativement pour du HA actif-actif multi-nœuds comme un cluster Exchange DAG. Le projet documente une configuration de réplication entre deux instances (remote_attachments_enc_key, syncjobs dovecot, réplication MariaDB), qui permet un failover manuel ou automatisé relativement rapide.

Pour une vraie redondance, on combine trois briques.

• MX secondaire : postfix pur ou seconde instance Mailcow qui prend le relais si le primaire est injoignable. Les SMTP entrants bufferisent naturellement en cas de panne côté expéditeur.
• Réplication dovecot : les boîtes sont disponibles sur les deux instances, un failover applicatif ne fait pas perdre de données.
• DNS failover : priorités MX différentes, voire anycast pour les setups ambitieux.

On obtient un SLA de 99,9 % à 99,99 % selon le niveau de redondance. Pour le commun des PME, un Mailcow sur VPS infogéré avec sauvegarde 3-2-1 (voir la règle 3-2-1) suffit amplement.

Comment migrer depuis Google Workspace ou Microsoft 365

La migration suit toujours la même logique : préparer, répliquer, basculer, nettoyer. La bonne nouvelle : IMAP et CalDAV sont des standards, et les outils de synchronisation sont matures depuis des années.

$ git clone https://github.com/mailcow/mailcow-dockerized
$ cd mailcow-dockerized
$ ./generate_config.sh

1. Provisionner les boîtes côté Mailcow

On crée les domaines, les boîtes et les alias dans l'UI Mailcow (ou via API pour un gros volume). On définit les mots de passe provisoires qui seront communiqués aux utilisateurs.

2. Synchroniser les emails avec imapsync

imapsync est l'outil de référence pour transférer des boîtes IMAP d'un serveur à un autre. Il gère les doublons, les reprises sur erreur, les gros volumes.

$ imapsync \
    --host1 imap.gmail.com --port1 993 --ssl1 \
    --user1 jean@entreprise.fr --password1 'app_password_google' \
    --host2 mail.datacampus-exemple.fr --port2 993 --ssl2 \
    --user2 jean@entreprise.fr --password2 'mdp_mailcow' \
    --automap --skipcrossduplicates

Pour Google Workspace, on génère un mot de passe d'application (pas le mot de passe principal). Pour Microsoft 365, on désactive la sécurité moderne pour le compte ou on passe par OAuth2 (imapsync gère les deux).

3. Exporter les calendriers et contacts

Google Workspace exporte les calendriers en ICS depuis les paramètres Google Agenda, et les contacts en vCard. Microsoft 365 exporte depuis Outlook (fichier PST ou ICS/vCard). On importe ensuite dans SOGo via l'UI web ou via des outils CLI côté serveur.

4. Basculer les enregistrements DNS

C'est l'étape critique. On passe les MX de Google/Microsoft vers Mailcow, on met à jour SPF, DKIM (clé générée côté Mailcow), DMARC et le reverse DNS (PTR) sur l'IP publique. On baisse le TTL à 300 s la veille pour que la bascule soit quasi instantanée.

entreprise.fr.         IN MX  10 mail.entreprise.fr.
entreprise.fr.         IN TXT "v=spf1 mx ~all"
default._domainkey     IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."
_dmarc.entreprise.fr.  IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@entreprise.fr"

5. Période de double accès

Pendant une à deux semaines, on laisse l'ancien compte actif en IMAP, avec un imapsync différentiel nocturne. Les éventuels emails qui arriveraient encore sur l'ancienne plateforme (pendant la propagation DNS) sont récupérés. Puis on coupe les licences Google ou Microsoft.

Garder son DNS chez OVH ou Gandi, pointer MX chez nous

Question fréquente : faut-il bouger tout le DNS quand on héberge son mail chez Datacampus ? Non. La zone DNS peut rester chez votre registrar habituel (OVH, Gandi, Infomaniak). Vous ajoutez simplement les enregistrements MX, SPF, DKIM, DMARC, et un A ou CNAME pour le hostname du serveur (mail.entreprise.fr).

On recommande quand même de vérifier que le registrar supporte DNSSEC et des TTL courts sur les enregistrements MX. Certains hébergeurs DNS bas de gamme ont des TTL minimaux de 3600 s, ce qui rallonge inutilement la bascule. Si vous voulez aller plus loin (zones DNS signées, automatisation, statistiques), on peut héberger la zone DNS avec Mailcow, mais ce n'est pas un prérequis.

RGPD et emails sortants : où transitent vraiment les messages ?

Un point souvent mal compris. Quand vous envoyez un email à client@gmail.com, le message transite par les serveurs Google. C'est inévitable, peu importe d'où vous écrivez. Héberger votre propre serveur ne change pas ce fait.

En revanche, ce que vous maîtrisez en auto-hébergeant :

• Stockage complet : vos propres emails (entrants et sortants) sont archivés chez vous.
• Métadonnées internes : qui parle à qui dans l'entreprise, quand, à quelle fréquence.
• Échanges internes : entre deux collaborateurs du même domaine, les messages ne sortent jamais de votre serveur.
• Sauvegardes et archives légales : rétention, conformité, restauration, tout est sous votre contrôle.

Pour un échange interne à l'entreprise sur Google Workspace, Google voit le message. Sur Mailcow chez Datacampus, personne ne le voit en dehors de votre infra. C'est déjà énorme en volume, et c'est ce qui change le curseur de conformité RGPD.

L'offre Mailcow infogérée chez Datacampus

On déploie Mailcow sur VPS dédié depuis plus de 5 ans. Chaque instance est installée, monitorée et patchée par notre équipe à Niort, sans sous-traitance.

Sauvegardes : 4 niveaux au choix

Chez Datacampus, pas de snapshots : de vraies sauvegardes applicatives chiffrées, avec rétention contrôlée. Quatre niveaux, du socle minimal au plan de reprise multi-site.

Vous pouvez aussi compléter la suite : Nextcloud pour les fichiers et l'agenda avancé, OnlyOffice pour le bureautique collaboratif, Element pour la messagerie instantanée chiffrée, Jitsi Meetings pour la visio. Toute la suite GAFAM remplacée, bloc par bloc.

« La messagerie, c'est le dernier endroit où on continue de faire transiter le cœur de l'entreprise par un tiers américain. Le plus absurde, c'est qu'on sait comment s'en passer depuis 15 ans. »

Conclusion

Mailcow n'est pas un projet expérimental. C'est une suite mature, maintenue par une équipe allemande solide, déployée par des milliers d'organisations en Europe, basée sur les standards ouverts qui font tourner l'email depuis 40 ans (Postfix, Dovecot). Pour une PME ou une ETI qui veut reprendre le contrôle de sa messagerie sans payer 150 € par utilisateur et par an à un prestataire américain, c'est aujourd'hui la réponse la plus évidente.