Ai-je besoin d'une IP dédiée pour faire tourner un serveur de mail ?

En pratique oui. La délivrabilité dépend d'un enregistrement DNS inverse (PTR) qui correspond au nom d'hôte de votre mail, et vous ne pouvez régler un PTR que sur une IP qui est exclusivement la vôtre. Sur une adresse partagée ou NAT, vous ne contrôlez pas le PTR, donc les serveurs récepteurs voient un nom d'hôte générique ou discordant et vous traitent comme suspect. Une IP dédiée est la base du mail sortant.

Qu'est-ce qu'un enregistrement PTR et pourquoi l'e-mail en a-t-il besoin ?

Un enregistrement PTR, c'est du DNS inverse — il fait correspondre votre IP à un nom d'hôte, l'inverse d'un enregistrement A normal. Quand votre serveur se connecte à Gmail ou Outlook, le côté récepteur cherche qui possède votre IP. Si le PTR est absent ou générique (comme static.203-0-113-19.rev.example-isp.net), c'est un mauvais point immédiat contre vous. Les serveurs de mail attendent que le PTR corresponde au nom que votre serveur annonce dans le HELO.

Pourquoi le port 25 sortant est-il bloqué par défaut chez la plupart des hébergeurs VPS ?

Le port 25 est le plus gros vecteur de spam, donc les hébergeurs le gardent fermé jusqu'à ce que vous le demandiez et expliquiez ce que vous envoyez. Ce n'est pas un bug — c'est de la prévention d'abus. Un seul script compromis crachant du spam peut cramer la réputation d'une IP, et sur un sous-réseau partagé ces dégâts éclaboussent les autres clients. Les hébergeurs sérieux, EQVPS compris, l'ouvrent sur demande plutôt que par défaut.

Puis-je faire tourner un serveur de mail sur une IP NAT ou partagée ?

Vous pouvez recevoir du mail via une redirection de port, mais envoyer de façon fiable est une autre histoire. Sans votre propre IP, vous ne pouvez pas régler un PTR correspondant, et vous héritez de la réputation que l'adresse partagée porte déjà — bonne ou mauvaise. Pour tout ce que vous avez besoin de faire délivrer, utilisez une IP dédiée avec un historique propre et un PTR que vous contrôlez.

Auto-héberger l'e-mail en vaut-il vraiment la peine en 2026 ?

Ça dépend du pourquoi. Si vous voulez le contrôle de vos données et de votre domaine sans tiers dans la boucle, c'est tout à fait faisable sur un petit VPS. Mais la délivrabilité est un travail continu — vous surveillez les listes de blocage, faites tourner les clés DKIM, et gardez l'IP propre. Pour un projet parallèle à faibles enjeux, transférer via un fournisseur existant fait moins mal. Auto-hébergez quand le contrôle compte plus que le confort.

Faire tourner un serveur de mail sur un VPS : ce qui vous garde vraiment hors du spam

Votre serveur de mail marche. Postfix démarre, les logs semblent propres, vous envoyez un message de test vers votre Gmail — et il atterrit dans le spam. Ou il disparaît simplement. Rien dans votre config n'est cassé. Le logiciel a fait exactement ce que vous lui avez dit.

Le problème, c'est que le serveur à l'autre bout ne fait pas encore confiance à votre IP, et l'e-mail cache toute une pile de petits contrôles de confiance qui doivent tous s'aligner avant que la boîte de réception d'un inconnu ne vous laisse entrer. Réglez-les bien et la délivrance se gère surtout toute seule. Ratez-en un et vous criez dans un dossier spam.

Trois choses portent l'essentiel du poids : le DNS inverse, l'authentification de l'expéditeur, et le fait que votre hébergeur vous laisse ou non parler sur le port 25. Aucune n'est difficile. Elles sont juste faciles à oublier, et chacune est un veto silencieux.

Celle que tout le monde oublie : le DNS inverse

Le DNS direct est la partie que vous connaissez — un nom pointe vers une IP. Le DNS inverse est le miroir : une IP repointe vers un nom. Cet enregistrement s'appelle un PTR, et il vit chez celui qui contrôle l'IP, pas dans la zone de votre domaine.

Voici pourquoi ça compte. Quand votre serveur ouvre une connexion vers le SMTP de Gmail, l'une des premières choses que fait le côté récepteur est une recherche inverse sur votre IP — qui est-ce ? Faites-la vous-même :

dig -x 203.0.113.19 +short

Si ça renvoie quelque chose comme static.203-0-113-19.rev.example-isp.net, ou revient vide, vous avez déjà perdu des points. Ce nom générique dit « un VPS au hasard », et pire, il ne correspond pas au nom d'hôte sous lequel votre serveur se présente dans le salut HELO. Les serveurs récepteurs signalent durement cette discordance. Certains rejettent d'emblée.

Ce qu'ils veulent voir, c'est un PTR qui correspond au nom d'hôte de votre mail. Si votre serveur dit HELO mail.example.com, la recherche inverse sur son IP devrait renvoyer mail.example.com. Direct et inverse concordent, l'histoire est cohérente, et vous ressemblez à un vrai serveur de mail plutôt qu'à une machine détournée.

Régler un PTR a traditionnellement signifié ouvrir un ticket de support auprès de celui qui possède le bloc d'IP et attendre. Sur les plans à IP dédiée d'EQVPS, c'est un champ dans votre tableau de bord — tapez le nom d'hôte, ça s'écrit directement dans le registre via l'API du fournisseur, et c'est en ligne en quelques secondes. C'est tout l'intérêt de le faire en libre-service : le DNS inverse est l'étape que les gens sautent parce qu'elle était pénible.

Authentification : SPF, DKIM, DMARC

Ces trois enregistrements DNS disent aux serveurs récepteurs que le mail prétendant venir de votre domaine en vient vraiment. Sautez-les et vous êtes un inconnu non vérifié.

SPF est un enregistrement TXT listant quels serveurs sont autorisés à envoyer pour votre domaine. Gmail le vérifie et demande : ce message est-il venu d'une IP que vous avez autorisée ?
DKIM signe cryptographiquement chaque message sortant. Le récepteur tire votre clé publique du DNS et vérifie que la signature n'a pas été falsifiée en transit.
DMARC lie les deux ensemble et dit aux récepteurs quoi faire quand un contrôle échoue — rien, mettre en quarantaine, ou rejeter — et où envoyer les rapports.

Vous voulez les trois. SPF et DKIM prouvent que le mail est légitimement le vôtre ; DMARC transforme cette preuve en politique. C'est peut-être vingt minutes d'éditions DNS, et c'est la différence entre « expéditeur vérifié » et « qui ? ».

Le port 25, et pourquoi il est fermé

Voici celle qui surprend les gens. Le port 25 sortant — le port que les serveurs de mail utilisent pour se parler — est bloqué par défaut chez pratiquement tous les hébergeurs VPS. Nous aussi.

C'est délibéré. Le port 25 est le canon à spam classique, donc il reste fermé jusqu'à ce que vous le demandiez et disiez ce que vous envoyez réellement. On l'ouvre sur demande plutôt que de le laisser ouvert pour quiconque monte un serveur.

Et il y a ici une mise en garde honnête qui vaut la peine d'être dite clairement : avec un port 25 ouvert vient la responsabilité. Un seul script compromis ou un relais mal configuré crachant du spam, et la réputation de votre IP est perdue — parfois pour des semaines. Sur un sous-réseau partagé, ce gâchis éclabousse vos voisins, ce qui est exactement pourquoi les hébergeurs sont prudents. Si vous nous demandez d'ouvrir le 25, gardez votre serveur propre, parce que la réputation que vous protégez est en partie la nôtre aussi.

Pourquoi l'IP dédiée n'est pas optionnelle

Tout cela revient à une exigence : l'IP doit être la vôtre. Sur une configuration NAT ou une adresse partagée, vous ne pouvez pas régler votre propre PTR, parce que l'adresse n'est pas exclusivement la vôtre à pointer. Vous héritez aussi de la réputation que l'IP partagée porte déjà — et vous n'avez aucune idée de ce que le locataire précédent en a fait.

Une IP dédiée vous donne un PTR que vous contrôlez, une réputation qui est la vôtre à bâtir, et un point de départ propre. Pour le mail sortant, ce n'est pas un bonus ; c'est le plancher.

Le bilan honnête

Auto-héberger l'e-mail en 2026 est un vrai travail continu. Ce n'est pas configurer-et-oublier — vous surveillerez les listes de blocage, ferez tourner les clés DKIM, et découvrirez de temps en temps pourquoi un fournisseur précis s'est mis à vous mettre en liste grise. Si c'est un projet parallèle à faibles enjeux, honnêtement, transférer via un fournisseur de mail existant vous épargnera des maux de tête.

Mais si vous voulez un vrai contrôle — vos données, votre domaine, personne d'autre pour lire les en-têtes — c'est tout à fait faisable sur un petit VPS. La plomberie de confiance ci-dessus, c'est environ 90 % de la bataille, et rien de tout ça n'est exotique. Prenez une IP dédiée, réglez le PTR pour qu'il corresponde à votre nom d'hôte, publiez SPF/DKIM/DMARC, demandez-nous d'ouvrir le port 25, puis envoyez un test à travers un outil comme mail-tester.com et corrigez ce qu'il signale. Faites ça et vous ne criez plus dans un dossier spam — vous êtes un serveur de mail auquel les boîtes de réception des gens font vraiment confiance.