Pourquoi l'IP partagée du mutualisé sabote vos emails
Sur un hébergement mutualisé cPanel, des dizaines, parfois des centaines de comptes coexistent sur la même IPv4. Chacun envoie du courrier avec cette IP — newsletters, confirmations de commande, alertes de stock, factures PDF. La réputation de l'IP est commune : si un seul compte envoie du spam, est compromis ou dépasse un quota d'envoi, l'ensemble de la plage d'adresses peut être inscrite sur une liste noire.
Le mécanisme est mécanique : les récepteurs comme Gmail ou Outlook évaluent l'IP de l'enveloppe SMTP. Quand cette IP figure dans une blacklist (Spamhaus, Barracuda, Invaluement…), tous les messages qui en proviennent sont rejetés ou relégués en spam — peu importe la qualité du contenu ou la réputation individuelle du domaine expéditeur. En termes SMTP, votre client reçoit un 550 5.7.1 Message rejected ou un 421 Try again later directement dans les logs du serveur.
Pour une agence ou un revendeur gérant un portefeuille de sites, l'exposition est proportionnelle au nombre de clients hébergés sur le même pool. Une campagne mal configurée d'un voisin pénalise l'ensemble du parc. C'est une fragilité structurelle du mutualisé que le relay SMTP sur VPS élimine complètement.
Ce que vous gagnez avec un relay SMTP dédié
- IPv4 propre et exclusive : vous êtes le seul expéditeur, vous maîtrisez intégralement la réputation de l'IP.
- DKIM signé à la source : chaque message porte une signature cryptographique vérifiable, indépendante de l'infrastructure mutualisée.
- SPF et DMARC alignés : les trois enregistrements DNS peuvent pointer vers votre VPS, ce qui satisfait les exigences de Google et Outlook pour les volumes supérieurs à 5 000 emails par jour.
- Un relay pour tout le parc : les sites mutualisés, les applications Laravel, Node.js ou WordPress du portefeuille envoient tous via
localhost:587du VPS, sans modifier leur logique applicative. - Contrôle par compte SASL : créez un identifiant distinct par domaine client — si un compte est compromis, vous le révoquez sans impacter les autres.
- Indépendance des tarifs tiers : vous sortez de la dépendance aux fournisseurs de relay SMTP facturés à la tranche de volume, dont les grilles tarifaires ont été revalorisées courant 2025-2026.
- Observabilité complète :
/var/log/mail.logvous donne la trace exacte de chaque envoi, chaque rebond, chaque rejet — impossible à obtenir sur un mutualisé partagé.
Architecture : relay-only, pas un serveur MX complet
Il est important de distinguer deux rôles. Un serveur MX complet (comme Mailcow, couvert dans notre article dédié) gère les boîtes aux lettres, la réception du courrier entrant et l'interface webmail. C'est une autre problématique.
Un relay SMTP ne fait qu'une seule chose : relayer l'envoi sortant. Il ne reçoit pas de courrier externe, n'héberge aucune boîte, n'expose pas d'interface webmail. Postfix configuré en relay-only est minimaliste : il écoute uniquement sur localhost ou 127.0.0.1, accepte les connexions SASL authentifiées depuis les applications locales ou depuis les serveurs mutualisés autorisés, signe avec OpenDKIM, et transmet au destinataire final.
Cette architecture a trois avantages pratiques pour une agence :
— Surface d'attaque réduite : sans exposition sur le port 25 depuis Internet, le risque d'open relay ou d'abus est quasi nul.
— Pas de gestion de boîtes : vos clients conservent leurs boîtes Gmail, Microsoft 365 ou cPanel Mail inchangées. Seul le chemin d'envoi applicatif change.
— Déploiement en moins d'une heure : la procédure ci-dessous a été conçue pour être reproductible sur n'importe quel VPS Linux (Debian 12 / Ubuntu 22.04) par un administrateur ayant un niveau système intermédiaire.
Prérequis avant de commencer
Vérifiez ces quatre points avant de lancer l'installation.
1. Un VPS avec au moins 1 Go de RAM. Postfix et OpenDKIM sont légers. Un plan Start suffit amplement pour un portefeuille de 20 à 50 sites clients.
2. Port 587 ouvert, jamais le port 25. Les opérateurs de VPS cloud bloquent le port 25 sortant pour lutter contre le spam. Utilisez le port 587 (SMTP avec STARTTLS et authentification SASL).
3. Un enregistrement PTR configuré sur l'IPv4 du VPS. Le PTR (ou rDNS) est l'enregistrement qui associe votre IPv4 à un nom d'hôte lisible. Gmail et Outlook vérifient systématiquement ce PTR et rejettent les connexions provenant d'IP sans rDNS valide.
4. Un domaine dédié au relay avec accès à ses DNS. Vous aurez besoin de publier un enregistrement SPF et un enregistrement DKIM TXT sur ce domaine.
Installation et configuration pas à pas
Installer Postfix et OpenDKIM
Connectez-vous en root sur votre VPS puis lancez :
apt update && apt install -y postfix opendkim opendkim-tools swaks libsasl2-modulesLors de l'installation, dpkg-reconfigure postfix propose un assistant. Choisissez Internet Site et entrez le nom d'hôte de votre relay (relay.monagence.com).
Configurer /etc/postfix/main.cf
Remplacez le contenu de /etc/postfix/main.cf par la configuration suivante :
myhostname = relay.monagence.com
mydomain = monagence.com
myorigin = $mydomain
inet_interfaces = all
inet_protocols = ipv4
mydestination =
relayhost =
mynetworks = 127.0.0.1/32 [::1]/128 VOTRE_IP_MUTUALISE/32
smtp_use_tls = yes
smtp_tls_security_level = may
smtpd_use_tls = yes
smtpd_tls_cert_file = /etc/letsencrypt/live/relay.monagence.com/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/relay.monagence.com/privkey.pem
smtpd_sasl_auth_enable = yes
smtpd_sasl_type = cyrus
smtpd_sasl_path = smtpd
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, rejectGénérer et déployer les clés DKIM avec OpenDKIM
mkdir -p /etc/opendkim/keys/monagence.com
opendkim-genkey -s mail -d monagence.com -b 2048 -D /etc/opendkim/keys/monagence.com/
chown -R opendkim:opendkim /etc/opendkim/keys/
chmod 700 /etc/opendkim/keys/monagence.com/Puis éditez /etc/opendkim.conf pour ajouter :
Domain monagence.com
KeyFile /etc/opendkim/keys/monagence.com/mail.private
Selector mail
Socket inet:12301@localhost
UMask 002Relier Postfix à OpenDKIM via milter
Ajoutez ces lignes à la fin de /etc/postfix/main.cf :
milter_protocol = 6
milter_default_action = accept
smtpd_milters = inet:localhost:12301
non_smtpd_milters = inet:localhost:12301Redémarrez les deux services :
systemctl enable --now opendkim
systemctl restart postfixPublier les enregistrements DNS
Récupérez la clé publique DKIM à publier :
cat /etc/opendkim/keys/monagence.com/mail.txtCréez l'enregistrement TXT mail._domainkey.monagence.com. Publiez le SPF :
monagence.com IN TXT "v=spf1 ip4:VOTRE_IP_VPS ~all"Et le DMARC :
_dmarc.monagence.com IN TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]; fo=1"Tester le relay et valider la signature
swaks --to [email protected] --server localhost:587 \
--auth PLAIN --auth-user [email protected] \
--auth-password VOTREMOTDEPASSE \
--tlsVérifiez dans /var/log/mail.log la ligne status=sent. Pour valider la signature DKIM côté destinataire, envoyez un message à [email protected].
Configurer les sites clients pour utiliser le relay
Côté cPanel / WHM : dans WHM, *Exim Configuration Manager* → *Basic Editor* → *Outgoing Mail*, activez le smart host sur l'IPv4 de votre VPS, port 587.
Côté application Laravel :
MAIL_MAILER=smtp
MAIL_HOST=IP_VPS
MAIL_PORT=587
[email protected]
MAIL_PASSWORD=VOTREMOTDEPASSE
MAIL_ENCRYPTION=tlsCôté WordPress / WooCommerce : installez le plugin *WP Mail SMTP* ou *Post SMTP* avec les mêmes paramètres.
Côté Node.js / Nodemailer : host: 'IP_VPS', port: 587, secure: false, auth: { user: '[email protected]', pass: 'VOTREMOTDEPASSE' }.
Pour un portefeuille de plus de 20 sites clients, créez un compte SASL distinct par domaine client. Si un client est compromis, vous révoquez uniquement son identifiant sans interrompre le service pour les autres. Avec OpenDKIM en mode SigningTable, chaque domaine client peut aussi signer avec sa propre clé DKIM — l'alignement DMARC devient parfait pour chaque expéditeur du portefeuille.
Post-installation : surveiller la réputation et anticiper les problèmes
Surveillez /var/log/mail.log quotidiennement. Les lignes status=sent indiquent un acheminement réussi. Les lignes status=bounced ou status=deferred méritent une lecture immédiate.
Abonnez-vous aux Postmaster Tools de Google et Microsoft. Google Postmaster Tools vous donne un dashboard de réputation de domaine et d'IP. Microsoft SNDS offre une vue équivalente pour Outlook et Hotmail.
Vérifiez les blacklists au moins une fois par semaine. L'outil MXToolbox Blacklist Check contrôle votre IP contre plus de 100 listes en quelques secondes.
Limitez le débit par compte SASL. Postfix propose smtpd_client_message_rate_limit et anvil_rate_time_unit pour limiter le nombre de messages par unité de temps.
Dépannage : les cinq erreurs les plus fréquentes
1. status=bounced (host said: 550 5.7.1 Message rejected as spam) — votre IPv4 est inscrite sur une liste noire, ou le PTR record est absent. Vérifiez sur mxtoolbox.com/blacklists.
2. DKIM=fail — vérifiez avec dig TXT mail._domainkey.monagence.com. Assurez-vous que la valeur DNS est sur une seule ligne sans coupure.
3. Port 587 connexion refusée — ufw status doit montrer le port 587 en ALLOW. Vérifiez que Postfix écoute : ss -tlnp | grep :587.
4. Emails alignés DKIM mais toujours en spam — l'alignement DMARC exige que le domaine du From: corresponde au domaine couvert par DKIM. Configurez un sélecteur DKIM par domaine client.
5. /var/log/mail.log silencieux — vérifiez que le service Postfix est démarré : systemctl status postfix.
Un relay mutualisé pour tout le parc, une réputation maîtrisée
En deux heures de configuration, un VPS Start héberge un relay Postfix prêt à acheminer le transactionnel de l'ensemble d'un portefeuille client. L'IPv4 dédiée reste sous votre contrôle exclusif, la signature DKIM est vérifiable, et SPF comme DMARC sont alignés dès la première mise en service.
Pour aller plus loin, notre article sur SPF, DKIM et DMARC couvre les enregistrements DNS en détail. Si vous souhaitez également héberger les boîtes mail de vos clients, notre guide Mailcow décrit la mise en place d'un serveur MX complet sur VPS.
