Pourquoi un serveur email sur VPS en 2026
Les grandes messageries — Gmail et Outlook en tête — ont durci leurs règles d'authentification. Gmail a activé son rejet strict des expéditeurs non conformes en novembre 2025 ; Microsoft Outlook a emboîté le pas en mai 2025 pour les volumes supérieurs à 5 000 messages par jour. Un email envoyé sans SPF, DKIM et DMARC correctement configurés finit aujourd'hui en spam ou en bounce.
Pour les agences et les développeurs qui gèrent plusieurs domaines clients, un serveur email self-hosted sur VPS présente un avantage concret : une infrastructure centralisée, une réputation d'IP maîtrisée, et un contrôle total sur les enregistrements DNS d'authentification. Le coût d'une réputation d'IP dégradée — des semaines de warm-up, voire une liste noire — justifie d'investir dans une configuration rigoureuse dès le premier envoi.
Ce que Stalwart apporte par rapport à une stack classique
- Binaire unique : SMTP, IMAP4, POP3, JMAP, ManageSieve et WebAdmin dans un seul processus — pas de Docker Compose multi-conteneurs à orchestrer.
- Écrit en Rust : sécurité mémoire par construction, faible empreinte RAM, démarrage rapide.
- SPF, DKIM et DMARC intégrés : vérification entrante et signature sortante configurables depuis l'interface WebAdmin, sans plugin tiers.
- JMAP : protocole moderne qui réduit la latence client par rapport à IMAP seul — supporté nativement par Stalwart.
- AGPL-3.0 : code auditable, aucune dépendance à un service cloud propriétaire.
- WebAdmin intégrée : gestion des domaines, des comptes, des règles de filtrage et des rapports DMARC depuis un navigateur.
Prérequis avant de commencer
Stalwart fonctionne sur tout VPS Linux 64 bits. Pour une production stable, prévoir au moins 2 vCPU et 2 Go de RAM — le binaire lui-même est léger, mais la gestion des files SMTP et des index IMAP consomme de la mémoire sous charge.
Deux points bloquants à vérifier avant toute installation :
Le port 25 doit être ouvert vers l'extérieur. De nombreux hébergeurs bloquent ce port sur les offres VPS d'entrée de gamme pour limiter le spam. Vérifier auprès du fournisseur que le port 25 sortant est débloqué — sans lui, Stalwart peut recevoir du courrier, mais ne peut pas en émettre vers d'autres serveurs.
L'IP du VPS doit avoir un PTR (enregistrement DNS inverse) correct. Un PTR manquant ou incohérent avec le nom de domaine de l'enveloppe SMTP est l'une des premières causes de rejet par les grandes messageries. La plupart des hébergeurs VPS permettent de définir ce PTR depuis leur panneau de contrôle.
Liste des prérequis
- VPS Linux 64 bits (Debian 12 ou Ubuntu 22.04 recommandés), minimum 2 vCPU / 2 Go RAM.
- IP dédiée — jamais une IP partagée pour un serveur email de production.
- PTR DNS configuré sur l'IP du VPS : doit correspondre au hostname du serveur mail.
- Port 25 sortant débloqué par l'hébergeur (vérifier avant commande).
- Ports 465 (SMTPS), 587 (submission), 993 (IMAPS) et 143 (IMAP) ouverts dans le pare-feu.
- Un nom de domaine avec accès à la gestion des enregistrements DNS (ajout de TXT pour SPF, DKIM, DMARC).
- Un certificat TLS valide — Let's Encrypt via ACME est supporté nativement par Stalwart.
Installation de Stalwart sur VPS
Stalwart propose un script d'installation officiel qui télécharge le binaire précompilé, crée un utilisateur système dédié, installe un service systemd et guide la configuration initiale en mode interactif.
Déploiement pas à pas
Télécharger et lancer le script d'installation
Se connecter au VPS en root ou avec sudo, puis lancer le script officiel :
curl -fsSL https://get.stalw.art/install.sh | sudo bashLe script détecte l'architecture, télécharge le binaire de la dernière version stable (v0.16.19 au moment de cet article), crée l'utilisateur stalwart-mail, installe le binaire dans /usr/local/bin/stalwart-mail et génère la configuration initiale dans /etc/stalwart/.
Configurer le domaine et les paramètres SMTP
Le script propose un assistant interactif. Renseigner le nom de domaine principal (mail.votredomaine.com), le domaine d'envoi et le chemin de stockage des boîtes. La configuration est écrite en TOML dans /etc/stalwart/config.toml.
Pour activer Let's Encrypt, s'assurer que le port 443 est accessible et que l'enregistrement DNS mail.votredomaine.com pointe vers l'IP du VPS avant de lancer le script.
Démarrer le service et vérifier les logs
sudo systemctl enable --now stalwart-mail
sudo systemctl status stalwart-mail
journalctl -u stalwart-mail -fLe service écoute sur les ports configurés. Les logs indiquent si le certificat TLS a été obtenu et si les sockets SMTP et IMAP sont actifs.
Configurer SPF, DKIM et DMARC dans le DNS
Se connecter à la WebAdmin (port 8080 par défaut, à protéger derrière un reverse proxy ou par IP allowlist) et naviguer vers Gestion → Domaines.
Stalwart génère la clé DKIM et affiche les enregistrements DNS à ajouter. Publier dans le gestionnaire DNS :
# SPF — autoriser le VPS à envoyer pour le domaine
votredomaine.com. TXT "v=spf1 mx a:mail.votredomaine.com ~all"
# DKIM — clé publique générée par Stalwart (valeur fournie dans WebAdmin)
default._domainkey.votredomaine.com. TXT "v=DKIM1; k=rsa; p=<clé publique>"
# DMARC — politique de rejet avec adresse de rapport
_dmarc.votredomaine.com. TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"Démarrer avec p=none (mode surveillance) pendant 48 à 72 heures, analyser les rapports agrégés, puis passer à p=quarantine puis p=reject.
Créer les premiers comptes et tester l'envoi
Dans la WebAdmin, créer un domaine et les comptes utilisateurs associés. Tester l'envoi avec swaks depuis le VPS :
swaks --to [email protected] --from [email protected] \
--server mail.votredomaine.com --port 587 \
--auth LOGIN --auth-user [email protected]Vérifier la réception et l'en-tête Authentication-Results du message reçu — il doit indiquer spf=pass, dkim=pass et dmarc=pass.
Protéger la WebAdmin et durcir le pare-feu
La WebAdmin ne doit pas être exposée publiquement. Deux options : la restreindre à une IP de gestion dans la configuration Stalwart, ou la mettre derrière un reverse proxy nginx avec authentification basique.
Côté pare-feu, n'autoriser que les ports strictement nécessaires :
# Exemple avec ufw
ufw allow 25/tcp # SMTP entrant
ufw allow 465/tcp # SMTPS
ufw allow 587/tcp # Submission
ufw allow 993/tcp # IMAPS
ufw allow 143/tcp # IMAP (si nécessaire)
ufw deny 8080/tcp # WebAdmin — accès restreint, pas publicSe référer à l'article sur le durcissement VPS Linux pour la configuration complète du pare-feu et la gestion des clés SSH.
Réputation IP : le facteur souvent négligé
Une installation techniquement parfaite ne suffit pas si l'IP du VPS est déjà listée dans une base de réputation négative (Spamhaus, Barracuda, SORBS). Avant de mettre en production, vérifier l'IP sur MXToolbox Blacklists et sur Spamhaus Checker. Si l'IP est listée, ouvrir une demande de délistage auprès de chaque base — un processus qui prend entre 24 heures et deux semaines selon la liste. Demander une IP fraîche à l'hébergeur est parfois plus rapide.
Stalwart vs Mailcow : deux approches du serveur email self-hosted
| Critère | Stalwart Mail Server | Mailcow |
|---|---|---|
| Architecture | Binaire unique Rust (un seul processus) | Stack Docker multi-conteneurs (Postfix, Dovecot, Rspamd, SOGo...) |
| Protocoles | SMTP, IMAP4, POP3, JMAP, ManageSieve, CalDAV, CardDAV | SMTP, IMAP4, POP3, ManageSieve, CalDAV, CardDAV |
| RAM minimale recommandée | 2 Go en production | 4 à 6 Go recommandés (plusieurs conteneurs) |
| SPF/DKIM/DMARC | Intégrés nativement dans le binaire | Via Rspamd et OpenDKIM (configuration séparée) |
| Interface d'administration | WebAdmin intégrée (HTTP, REST API) | SOGo + interface Mailcow dédiée |
| Licence | AGPL-3.0 | MIT (mais dépendances sous licences variées) |
| Maturité | Stable, v0.16.x, pré-1.0 | Mature, déployé en production depuis 2016 |
Les pièges courants à éviter
PTR manquant ou incohérent. C'est la cause la plus fréquente de rejet silencieux par Gmail et Outlook. Le PTR doit résoudre vers le hostname utilisé dans le EHLO SMTP, qui lui-même doit correspondre au domaine d'envoi. Vérifier avec dig -x <IP-du-VPS>.
Port 25 bloqué par l'hébergeur. Certains fournisseurs VPS bloquent le port 25 sortant par défaut pour contenir le spam. Stalwart peut toujours recevoir du courrier, mais l'envoi vers des serveurs externes échoue. La vérification préalable évite de découvrir ce blocage après l'installation.
Passer trop vite à p=reject sur DMARC. Une politique DMARC restrictive posée sans période de surveillance préalable peut bloquer des flux légitimes (newsletters, formulaires de contact) si SPF ou DKIM ne couvrent pas tous les chemins d'envoi. Les 48 à 72 premières heures en p=none avec rapports agrégés sont nécessaires.
Warm-up de l'IP négligé. Une IP fraîche qui envoie brutalement des centaines de messages par jour est signalée comme suspect par les filtres anti-spam. Monter progressivement le volume sur une à deux semaines, en commençant par les destinataires les plus engagés.
Mises à jour et maintenance
Stalwart publie des mises à jour régulières sur son dépôt GitHub. La v0.16.19 (août 2026) est la version stable courante — le projet vise la v1.0 après la finalisation du schéma de base de données et les optimisations de performance.
Pour mettre à jour le binaire :
sudo systemctl stop stalwart-mail
sudo curl -fsSL https://get.stalw.art/install.sh | sudo bash
sudo systemctl start stalwart-mailLes fichiers de configuration dans /etc/stalwart/ et les données dans le répertoire de stockage ne sont pas écrasés par le script de mise à jour. Conserver une sauvegarde des clés DKIM avant toute opération — la perte de la clé privée DKIM force la rotation de l'enregistrement DNS et une période de propagation.
Suivre les releases sur github.com/stalwartlabs/stalwart/releases pour être alerté des correctifs de sécurité.
