Installer mailcow sur un VPS accepté par Gmail

Ce que vous allez mettre en place

Un serveur de messagerie complet sur une machine qui vous appartient : SMTP pour envoyer et recevoir, IMAP pour que votre téléphone et votre ordinateur portable restent synchronisés, un client de webmail et un filtre antispam qui attribue un score à chaque message dans les deux sens. mailcow-dockerized regroupe Postfix, Dovecot, Rspamd, le webmail SOGo, MariaDB, Redis et un client ACME dans une seule stack Docker Compose. Le logiciel n’est donc pas la partie la plus difficile. Vous l’aurez opérationnel en une demi-heure.

La difficulté vient de tout ce qui l’entoure. La messagerie est le seul service pour lequel le reste d’Internet se méfie activement d’un serveur neuf. L’écart entre « ça fonctionne » et « Gmail supprime silencieusement tous les messages » dépend surtout de 4 enregistrements DNS et d’un paramètre de réputation IP que vous ne contrôlez peut-être pas entièrement. Lisez les prérequis ci-dessous avant de louer quoi que ce soit. Si, après cette lecture, vous concluez que le travail nécessaire pour établir une bonne réputation n’en vaut pas la peine, c’est une réponse parfaitement valable : notre bilan de ce qu’il vaut réellement la peine d’auto-héberger en 2026 classe la messagerie dans la catégorie « uniquement si c’est vraiment votre objectif » pour ces raisons précises.

Les prérequis SONT le projet

Si l’un d’eux manque, vous enverrez des e-mails qui n’arriveront jamais. Voici les points classés approximativement selon la fréquence à laquelle ils bloquent les utilisateurs :

Le port sortant 25 doit être ouvert. Votre serveur remet les e-mails à Gmail et Microsoft via TCP sur le port 25. De nombreux fournisseurs de VPS et de cloud bloquent par défaut le port sortant 25 pour lutter contre le spam. Ce blocage est silencieux : aucune erreur ne s’affiche au démarrage, tout semble fonctionner et les e-mails restent en attente dans la queue jusqu’à ce que Postfix abandonne et les rejette avec un bounce. mailcow définit la durée de vie maximale de la queue à cinq jours. Testez ce point avant d’installer quoi que ce soit. S’il est bloqué, la seule solution consiste à ouvrir un ticket auprès de votre fournisseur pour lui demander de le débloquer. Certains le font pour les comptes suffisamment anciens, d’autres ne le feront jamais.

Une adresse IP propre, avec une réputation exploitable. Les adresses IP de VPS recyclées figurent souvent déjà sur des blocklists à cause du spam envoyé par un précédent locataire. Vérifiez la vôtre avec un service comme la lookup Spamhaus ou mxtoolbox avant de vous engager. Une adresse IP listée entraîne des rejets que vous ne pourrez pas résoudre par la configuration.

La maîtrise du DNS et un enregistrement PTR correct. Vous devez pouvoir ajouter des enregistrements à la zone de votre domaine et configurer le reverse DNS (PTR) de l’adresse IP du serveur pour qu’il pointe vers le hostname de messagerie. Le PTR se configure presque jamais dans votre panneau DNS. Il dépend du propriétaire de l’adresse IP et se définit donc dans le panneau de contrôle de votre fournisseur de VPS ou via un ticket.

6 GiB de RAM et 2 vCPU constituent une base confortable. Le minimum indiqué par mailcow est de 6 GiB de RAM, avec 1 GiB de swap, pour une installation privée. 8 GiB sont recommandés dès que plusieurs utilisateurs s’en servent. En dessous d’environ 2.5 GiB, generate_config.sh propose de désactiver l’antivirus ClamAV afin d’éviter que le kernel ne commence à tuer des conteneurs. Le minimum de disque documenté par mailcow est de 20 GiB avant même le stockage des e-mails. Prévoyez donc davantage dès le départ et laissez de la marge pour la croissance des mailboxes.

Un nom DNS, pas une simple adresse IP. Choisissez un hostname tel que mail.example.com. Ce nom devient votre MAILCOW_HOSTNAME, le sujet de votre certificat TLS, votre cible PTR et votre bannière SMTP. Utilisez-le partout de manière cohérente.

Étape 1 : vérifiez que le port sortant 25 est ouvert

Commencez par cette étape. Si elle échoue, tout le reste est inutile. Depuis le VPS fraîchement installé, essayez d’ouvrir une conversation SMTP avec un serveur de messagerie réel :

sudo apt update && sudo apt install -y netcat-openbsd
nc -vz -w 5 gmail-smtp-in.l.google.com 25

Un résultat positif est immédiat :

Connection to gmail-smtp-in.l.google.com (142.250.x.x) 25 port [tcp/smtp] succeeded!

Lorsque le port est bloqué, la commande attend pendant les cinq secondes complètes, puis échoue :

nc: connect to gmail-smtp-in.l.google.com port 25 (tcp) timed out: Operation now in progress

Sur un VPS fraîchement installé, sans règle de pare-feu sortant que vous auriez ajoutée, ce délai d’attente indique un blocage du fournisseur. Il s’agit d’un filtre réseau appliqué côté fournisseur, et non de votre pare-feu. Aucune modification locale ne peut donc le corriger. Ouvrez un ticket : « Please enable outbound TCP port 25 for my VPS at <IP>; I am running a legitimate mail server. » N’installez pas mailcow tant que la commande ne renvoie pas « succeeded ». Le port 25 entrant, qui permet aux autres serveurs de vous contacter, suit un chemin distinct et est généralement ouvert. C’est le trafic sortant que les fournisseurs limitent.

Étape 2, Créez maintenant les enregistrements DNS

Les modifications DNS prennent du temps à se propager. Publiez donc tout ce que vous pouvez avant l’installation. Supposons que votre domaine soit example.com, que votre hôte de messagerie soit mail.example.com et que l’adresse IP soit 10.0.0.10. Dans votre zone, créez :

mail.example.com.        A      10.0.0.10
mail.example.com.        AAAA   2001:db8::10          ; only if you have IPv6
example.com.             MX  10 mail.example.com.
example.com.             TXT    "v=spf1 mx -all"
_dmarc.example.com.      TXT    "v=DMARC1; p=none; rua=mailto:postmaster@example.com"

L’enregistrement SPF indique que seul votre MX peut envoyer des messages pour ce domaine et que les autres doivent être rejetés. Commencez avec DMARC à p=none pour consulter les rapports sans rejeter vos propres messages. Passez ensuite à p=quarantine, puis à p=reject, lorsque l’alignement est confirmé. Deux enregistrements manquent encore volontairement : DKIM, que mailcow génère à votre place à l’étape 6, et PTR, que vous configurez maintenant dans le panneau de votre fournisseur.

Définissez le PTR (DNS inverse) de 10.0.0.10 sur mail.example.com, c’est-à-dire la valeur exacte de MAILCOW_HOSTNAME. C’est l’enregistrement que la plupart des utilisateurs oublient, et les grands fournisseurs le contrôlent pour refuser les messages. Si votre panneau ne comporte aucun champ rDNS, ouvrez un ticket.

Étape 3, installer Docker

mailcow nécessite Docker Engine 24.0 ou une version ultérieure, ainsi que Docker Compose 2.0 ou une version ultérieure. Le plugin Compose (docker compose) est la méthode la plus simple, mais mailcow prend également en charge le binaire autonome docker-compose. Utilisez le script officiel de Docker plutôt que le paquet docker.io d’Ubuntu, qui ne fournit aucun plugin Compose :

curl -fsSL https://get.docker.com | sudo sh
sudo docker compose version

Vous devriez voir une ligne Docker Compose version indiquant v2.x ou v5.x. Compose v5, publié en 2025, est fonctionnellement identique à v2, et les deux versions sont compatibles avec mailcow. Si docker compose version affiche docker: 'compose' is not a docker command, Docker Engine est installé, mais pas le plugin Compose. Installez le plugin depuis le dépôt de Docker, réexécutez le script ci-dessus ou consultez notre guide sur les bases de Docker Compose, qui installe les deux composants depuis le dépôt apt de Docker.

Étape 4, Cloner mailcow et générer la configuration

cd /opt
sudo git clone https://github.com/mailcow/mailcow-dockerized
cd mailcow-dockerized
umask
sudo ./generate_config.sh

Vérifier que umask affiche 0022 respecte les propres étapes d’installation de mailcow, qui définissent umask 0022 avant le clonage. mailcow ne teste pas cette valeur, et un shell root Ubuntu 24.04 fraîchement ouvert fournit déjà 0022. Le script demande ensuite la seule information importante : le nom d’hôte pleinement qualifié. Saisissez mail.example.com ; cette valeur doit correspondre exactement à vos enregistrements A et PTR. Le script écrit mailcow.conf, l’unique fichier d’environnement lu par toute la stack. Ouvrez-le si vous devez modifier les ports web (HTTP_PORT, HTTPS_PORT) ou désactiver ClamAV sur une petite machine :

MAILCOW_HOSTNAME=mail.example.com
HTTP_PORT=80
HTTPS_PORT=443
SKIP_CLAMD=n          # set to y to drop the virus scanner on a <2.5 GiB box

SKIP_FTS=y est l’autre réglage important sur une machine disposant de peu de RAM : la recherche en texte intégral est le deuxième consommateur de mémoire cité dans la documentation de mailcow, et la désactiver vous prive uniquement de la recherche dans le contenu des messages du webmail.

Conservez HTTP_PORT=80 et HTTPS_PORT=443, sauf si un autre service de l’hôte les utilise déjà. Le client ACME intégré de mailcow utilise par défaut le challenge HTTP-01, qui exige que le port 80 soit accessible depuis Internet pour obtenir le certificat. (mailcow 2026-03 et les versions ultérieures peuvent utiliser à la place un challenge DNS-01 avec ACME_DNS_CHALLENGE=y. Cette méthode n’a pas besoin du port 80, mais elle nécessite un accès à l’API de votre hébergeur DNS.) C’est pourquoi l’architecture simple n’installe pas une configuration nginx-Certbot séparée sur la même machine : mailcow émet et renouvelle lui-même ses certificats TLS en interne, et un second service qui monopolise les ports 80/443 provoque un conflit. mailcow documente aussi l’alternative : lier localement ses listeners web avec HTTP_BIND=127.0.0.1 HTTP_PORT=8080 HTTPS_BIND=127.0.0.1 HTTPS_PORT=8443, placer un reverse proxy sur les ports 80 et 443 et, si vous voulez confier les certificats à un Certbot local, indiquer ces certificats à mailcow et ajouter un hook de renouvellement. Cela ajoute davantage de composants sur un serveur de messagerie. Le même compromis s’applique donc à tout autre service qui veut exposer une interface web publiquement : une configuration comme Halcyon, qui transforme une bibliothèque Jellyfin en vidéoclub des années 90, et qui attend son propre reverse proxy sur le port 443, doit être installée sur une autre machine, sauf si vous placez mailcow derrière ce proxy. L’exception concerne un service qui ne demande jamais de port web public : un relais RustDesk auto-hébergé écoute uniquement sur sa plage de ports 21115 à 21119. Il peut donc partager la machine, à condition de disposer d’une marge suffisante en bande passante.

Étape 5, Démarrer la stack et se connecter

sudo docker compose pull
sudo docker compose up -d
sudo docker compose ps

Le pull récupère environ deux douzaines d’images ; comptez quelques minutes. Lorsque docker compose ps indique que chaque conteneur est running (ou healthy), ouvrez https://mail.example.com/admin dans un navigateur. Les identifiants admin par défaut sont le nom d’utilisateur admin et le mot de passe moohoo. Modifiez immédiatement ce mot de passe dans l’interface d’administration, sous System → Configuration, puis Access → Administrators. Si le navigateur affiche un avertissement NET::ERR_CERT_AUTHORITY_INVALID, le certificat ACME n’a pas encore été délivré. Consultez l’échec ACME ci-dessous avant de conclure à un problème ; un certificat autosigné temporaire est normal pendant la première ou les deux premières minutes.

Étape 6, Ajouter un domaine, une boîte aux lettres et publier DKIM

Dans l’interface d’administration, ouvrez E-Mail → Configuration. Dans l’onglet Domains, cliquez sur Add domain et saisissez example.com. Ensuite, dans Mailboxes, cliquez sur Add mailbox pour créer you@example.com avec un mot de passe. Vous disposez alors d’une boîte aux lettres fonctionnelle, déjà accessible via IMAP.

Passons maintenant à la clé DKIM. Accédez à System → Configuration, puis à Options → ARC/DKIM keys. mailcow a peut-être déjà généré une clé lorsque vous avez ajouté le domaine. Sinon, générez-la à cet endroit, sélectionnez le domaine, conservez le sélecteur dkim, choisissez 2048-bit, puis cliquez sur Add. Copiez la longue valeur TXT affichée et publiez-la ainsi :

dkim._domainkey.example.com.  TXT  "v=DKIM1;k=rsa;t=s;s=email;p=MIIBIjANBgkqh...long-key...QAB"

La page Domains de mailcow contient un bouton DNS qui répertorie tous les enregistrements attendus et indique, par une coche verte ou une croix rouge, ce qui est effectivement publié. Utilisez cette page comme liste de contrôle et attendez que chaque ligne soit verte avant de tester la délivrabilité. Une ligne DKIM rouge après la publication signifie généralement que la clé a été découpée incorrectement entre plusieurs fragments TXT. Une clé 2048-bit dépasse la limite de 255 caractères d’une seule chaîne TXT. Collez-la donc comme une valeur logique unique et laissez votre fournisseur DNS la découper en fragments.

Étape 7 : testez la délivrabilité et visez 10/10

Accédez à mail-tester.com, copiez l’adresse aléatoire affichée, puis envoyez-lui un message depuis votre nouvelle boîte aux lettres. Connectez-vous à la messagerie web SOGo à l’adresse https://mail.example.com/SOGo et envoyez le message depuis cette interface. Cliquez ensuite sur « Then check your score ».

Visez 10/10. Voici les déductions les plus fréquentes et leurs causes :

• SPF non aligné : votre enregistrement MX/SPF est absent ou l’adresse IP d’envoi n’est pas couverte. Vérifiez à nouveau l’enregistrement TXT SPF.
• La signature DKIM n’est pas vérifiée : l’enregistrement TXT dkim._domainkey est absent, sa propagation n’est pas terminée ou son contenu est incorrect. C’est l’erreur la plus fréquente.
• PTR absent / PTR incohérent : le reverse DNS ne résout pas vers mail.example.com. Corrigez ce paramètre auprès du fournisseur.
• Adresse IP présente sur une blocklist : la réputation antérieure de votre adresse IP est en cause. Demandez son retrait de la liste ou demandez une adresse IP avec une meilleure réputation.

N’envoyez pas de vrais e-mails vers Gmail ou Outlook tant que le score n’est pas de 10/10. Un score faible associé à une nouvelle adresse IP peut entraîner le signalement de votre domaine dès le premier jour.

Étape 8, Connecter un véritable client de messagerie

Configurez Thunderbird, Apple Mail ou votre téléphone avec ces paramètres. Le serveur est mail.example.com dans tous les cas :

• IMAP : port 993, SSL/TLS (ou 143 avec STARTTLS)
• Envoi SMTP : port 465, SSL/TLS (ou 587 avec STARTTLS)
• Nom d’utilisateur : l’adresse complète, you@example.com
• Mot de passe : le mot de passe de la boîte aux lettres que vous avez défini

N’envoyez jamais les messages d’un client sur le port 25. Ce port est réservé aux échanges entre serveurs. mailcow n’y propose pas d’envoi authentifié, et les clients qui l’utilisent sont refusés. Si un client affiche Relay access denied, il essaie d’envoyer les messages sur le port 25 ou sans authentification. Configurez-le sur le port 465 ou 587 avec les identifiants de votre boîte aux lettres.

Étape 9 : sauvegardez ce qui compte vraiment

mailcow fournit un script de sauvegarde qui capture l’état de chaque volume persistant. Exécutez-le vers un disque externe ou un emplacement distant monté :

sudo MAILCOW_BACKUP_LOCATION=/opt/mailcow-backups \
  ./helper-scripts/backup_and_restore.sh backup all

all capture six éléments. La perte de l’un d’eux entraîne une perte de données : vmail (les boîtes aux lettres elles-mêmes), crypt (les clés qui déchiffrent vmail, inutiles sans celui-ci), mysql (MariaDB, qui contient les domaines, les utilisateurs, les alias et les paramètres), redis (l’état de la file d’attente et du cache), rspamd (les données apprises sur les spams et les messages légitimes) et postfix (la file d’attente des messages). Le script s’exécute dans un conteneur auxiliaire qui écrit des archives compressées. Les sauvegardes restent ainsi cohérentes, même lorsque la stack est en fonctionnement. Automatisez-le avec une tâche cron quotidienne et ajoutez --delete-days 14 pour supprimer les anciens jeux de sauvegardes. Une tâche cron qui ne fonctionne plus échoue silencieusement. Envoyez donc le code de sortie du script vers un système de notification que vous consultez réellement ; un serveur ntfy auto-hébergé accepte une commande curl sur une seule ligne dans la même entrée cron et vous signale l’échec sur votre téléphone la nuit où il survient. La restauration utilise le même script avec restore. Cette option affiche les snapshots et vous permet de choisir les éléments à restaurer. Une sauvegarde dont vous n’avez jamais testé la restauration n’est qu’un espoir, pas une sauvegarde. Effectuez un test à blanc sur un VPS de test.

Étape 10 : mettre à jour selon un calendrier

mailcow se met à jour avec son propre script. Celui-ci récupère le nouveau code, effectue les migrations de mailcow.conf, télécharge les images à l’avance et redémarre les conteneurs dans l’ordre :

cd /opt/mailcow-dockerized
sudo ./update.sh --check   # reports whether an update exists, changes nothing
sudo ./update.sh           # applies it

Effectuez d’abord une sauvegarde (étape 9), car il est difficile d’annuler une migration de schéma. Les mises à jour sont fréquentes et incluent des correctifs de sécurité pour les daemons exposés à Internet. Ne laissez donc pas un serveur de messagerie accumuler plusieurs mois de retard. Si une mise à jour laisse un conteneur en état unhealthy, sudo docker compose logs --tail=50 <service>-mailcow indique le daemon qui n’a pas redémarré correctement.

Une note sur le durcissement

mailcow exécute son propre service netfilter (netfilter-mailcow), qui bannit les adresses IP martelant les ports de messagerie et de webmail. La messagerie est donc protégée par défaut. Cela ne protège pas SSH sur l’hôte lui-même : le service reste exposé et continue de subir des attaques par force brute. Complétez cette configuration avec Fail2ban qui surveille le journal d’authentification SSH et une connexion reposant uniquement sur des clés. Protégez l’interface d’administration mailcow avec un mot de passe robuste et, dans l’idéal, ne l’exposez pas sur Internet ou placez-la derrière un VPN.

Modes de panne, avec les chaînes exactes

Files d’attente mail et aucun message n’est distribué. Exécutez sudo docker compose exec postfix-mailcow postqueue -p ou consultez la file d’attente mail dans l’interface d’administration. Les entrées restent différées pendant cinq jours au maximum, avant que Postfix ne les rejette, avec :

status=deferred (connect to gmail-smtp-in.l.google.com[142.250.x.x]:25: Connection timed out)

La cause est presque toujours le port sortant 25 bloqué par votre fournisseur (étape 1). Une règle sortante dans le pare-feu de votre propre hôte produit le même délai d’attente. Écartez donc d’abord cette possibilité. Si l’hôte est correctement configuré, aucune modification de configuration ne résoudra le problème : ouvrez un ticket. Le problème ne vient ni du DNS ni de TLS. L’indice est le mot timed out associé à un MX distant sur le port 25.

Gmail classe tous les messages comme spam ou les rejette. Ouvrez le message dans Gmail, sélectionnez « Show original » et consultez les résultats d’authentification. dkim=fail ou dkim=none signifie que votre enregistrement TXT dkim._domainkey est absent, incorrect ou pas encore propagé. Republiez exactement ce qu’indique la page ARC/DKIM, puis attendez l’expiration du TTL. spf=fail signifie que les enregistrements SPF/MX ne couvrent pas votre adresse IP. L’alignement est essentiel : un seul contrôle en échec suffit pour que le message soit classé comme spam.

Rejet par les grands fournisseurs lors de la connexion. Les messages de rejet ou les journaux Postfix contiennent le rejet PTR de Gmail :

550-5.7.25 [10.0.0.10] The IP address sending this message does not have a PTR
550-5.7.25 record setup, or the corresponding forward DNS entry does not match
550 5.7.25 the sending IP. As a policy, Gmail does not accept messages from IPs
550 5.7.25 with missing PTR records.

Le code 550 5.7.25 signifie que le reverse DNS est absent ou incorrect. Configurez le PTR de votre adresse IP vers mail.example.com chez le fournisseur (étape 2). Les résolutions directe (A) et inverse (PTR) doivent correspondre, et toutes deux doivent désigner le même hôte que celui présenté par mailcow aux autres serveurs.

Le navigateur affiche un avertissement de certificat qui ne disparaît jamais. Le conteneur acme-mailcow n’a pas réussi à obtenir un certificat valide. Consultez son journal :

sudo docker compose logs acme-mailcow | tail -n 40

Une ligne comme Cannot validate any hostnames, skipping Let's Encrypt for 1 hour. ou un échec du challenge signifie que le port 80 n’est pas accessible depuis Internet ou que l’enregistrement A ne pointe pas vers ce serveur. Si vous avez publié un enregistrement AAAA, vérifiez-le également : mailcow effectue d’abord la validation avec l’enregistrement AAAA et ignore le contrôle A lorsqu’il existe. Un enregistrement AAAA incorrect ou un chemin IPv6 qui ne peut pas atteindre le port 80 fait donc échouer la validation, même si l’enregistrement A est correct. Vérifiez que mail.example.com se résout vers le serveur, autorisez les ports 80 et 443 dans tous les pare-feu de l’hôte et assurez-vous qu’aucun autre service n’écoute sur ces ports. Après avoir corrigé la cause, redémarrez le client avec sudo docker compose restart acme-mailcow au lieu d’attendre la fin du délai de reprise d’une heure.

FAQ

L’auto-hébergement de la messagerie en vaut-il vraiment la peine ?

Si vous voulez garder la maîtrise de vos données, disposer d’un nombre illimité d’alias et contrôler entièrement la configuration, oui : mailcow fournit une stack professionnelle au prix d’un VPS. Mais la délivrabilité demande une surveillance continue : réputation de l’adresse IP, alignement DNS et suivi des blocklists ne s’arrêtent jamais complètement. Pour une adresse professionnelle critique, lorsque perdre un seul jour dans le dossier spam de quelqu’un vous coûte cher, un fournisseur managé est le choix pragmatique. Auto-hébergez votre messagerie si vous privilégiez le contrôle au confort et si vous êtes prêt à l’administrer régulièrement. Si votre objectif réel est de conserver vos données hors des serveurs d’un tiers plutôt que d’héberger spécifiquement votre messagerie, commencez par un service dont personne d’autre ne peut bloquer les messages : une photothèque ne rencontre aucun problème de délivrabilité, et notre comparatif de PhotoPrism et Immich couvre la mémoire RAM minimale et les commandes de sauvegarde pour ce type d’installation sur un VPS comparable.

Comment savoir si le port sortant 25 est bloqué ?

Exécutez nc -vz -w 5 gmail-smtp-in.l.google.com 25 depuis le serveur. Le message « succeeded! » signifie que le port est ouvert ; un timed out après la pause signifie que le port est bloqué. Si aucune règle de firewall sortant ne s’applique à votre serveur, le blocage vient de votre fournisseur. C’est la raison la plus fréquente pour laquelle un serveur auto-hébergé peut recevoir des messages, mais jamais en envoyer. En cas de blocage par le fournisseur, la seule solution consiste à lui demander d’ouvrir le port ; aucune modification locale ne peut le faire.

Pourquoi mes messages arrivent-ils toujours dans le dossier spam de Gmail ?

Il s’agit presque toujours d’une chaîne d’authentification mal configurée. Dans Gmail, utilisez « Show original » et recherchez spf=pass, dkim=pass et dmarc=pass. Un dkim=fail indique généralement l’absence ou la mauvaise configuration d’un enregistrement TXT dkim._domainkey ; une incohérence PTR ou une nouvelle adresse IP sans historique d’envoi nuit également à la délivrabilité. Commencez par obtenir une note de 10/10 sur mail-tester.com, puis augmentez progressivement le volume d’envoi, de quelques messages par jour à davantage, au lieu d’envoyer un grand volume dès le premier jour.

Que dois-je sauvegarder exactement ?

Exécutez backup_and_restore.sh backup all et conservez l’ensemble des sauvegardes hors du serveur. Cette commande sauvegarde vmail (les boîtes aux lettres), crypt (les clés qui permettent de les déchiffrer), la base de données MariaDB (domaines, utilisateurs, alias et paramètres), Redis, les données apprises par Rspamd et la file d’attente Postfix. Le volume crypt est souvent oublié. Sans lui, la sauvegarde vmail n’est qu’un texte chiffré illisible. Testez au moins une fois une restauration sur un serveur de test.

Puis-je exécuter mailcow sur un VPS de 2 GB ?

Pas dans de bonnes conditions. generate_config.sh propose de désactiver ClamAV en dessous d’environ 2.5 GiB. Même avec ClamAV désactivé, Rspamd, Dovecot, MariaDB et le reste de la stack se disputent la mémoire. Vous subirez donc du swap et des arrêts OOM dès que la charge deviendra réelle. Considérez 6 GiB de mémoire et 1 GiB de swap comme le minimum pour une installation stable destinée à un seul utilisateur. Passez à 8 GiB dès que plus de deux personnes environ en dépendent.