Serveur mail auto-hébergé sur VPS : port 25, PTR et pourquoi vos mails finissent en spam

Ce qu'un serveur destinataire décide vraiment, et dans quel ordre

Un serveur de messagerie destinataire prend une série de décisions, et il en prend l'essentiel avant même d'avoir lu le moindre octet de votre message. Cet ordre est ce qui compte, car un problème au niveau de la connexion ne se corrige pas avec un meilleur contenu, et un message parfaitement authentifié envoyé depuis une adresse sans historique atterrit quand même dans les indésirables. Lire cette chaîne dans l'ordre indique où porter ses efforts — ce qui n'est presque jamais là où les gens les mettent.

La première décision se joue sur la connexion TCP : qui est-ce, et dois-je même leur parler ? À ce moment-là, le destinataire dispose de votre adresse IP, de son DNS inverse, et de la réputation que lui attribuent ses propres listes ou celles de ses fournisseurs de blocklists. La deuxième se joue sur l'enveloppe SMTP — HELO et MAIL FROM — où le SPF est évalué par rapport à l'IP qui se connecte. La troisième arrive avec les données du message, où les signatures DKIM sont vérifiées et où le DMARC décide si l'un ou l'autre résultat d'authentification s'aligne avec le domaine indiqué dans l'en-tête visible From:. Ce n'est qu'après tout cela que commence quelque chose qui ressemble à un filtrage de contenu, et à ce stade l'essentiel du résultat est déjà joué.

Deux conséquences en découlent. Les gains les moins chers se trouvent en haut de la chaîne : un enregistrement PTR correct coûte un seul champ dans un panneau de contrôle et élimine toute une catégorie de rejets. Et le bas de la chaîne — la partie qui inquiète tout le monde, la formulation du message — est celle sur laquelle vous avez le moins de prise, et celle qui ne commence à compter qu'une fois que tout ce qui la précède est propre.

Le port 25 est la partie la moins chère du problème

Presque tous les grands clouds bloquent le port 25 sortant par défaut, et le débloquer suppose de le demander. AWS, Google Cloud, Azure, Oracle Cloud et la plupart des grandes marques de VPS livrent leurs machines avec le trafic sortant sur le 25 filtré, et la demande de déblocage est un formulaire rattaché à un compte qui porte déjà votre identité, votre carte bancaire et votre numéro de téléphone. C'est là qu'un projet d'auto-hébergement meurt le plus souvent, en silence, et c'est pourquoi la recherche qui amène le plus de monde sur une page comme celle-ci ressemble à quel VPS a le port 25 ouvert.

Mieux vaut être précis sur le rôle de chaque port, car les trois sont sans cesse confondus. Le port 25 est du serveur à serveur : c'est par lui qu'un MX remet un message à un autre, il n'est jamais authentifié, et c'est le seul port qui compte pour délivrer du courrier à des gens qui ne sont pas vos utilisateurs. Le port 587 est la soumission — vos propres clients qui s'authentifient auprès de votre serveur avant qu'il ne relaie pour eux. Le port 465 fait la même chose avec du TLS dès le premier octet ; il a été déprécié dans les années 90, puis officiellement réhabilité par la RFC 8314, et c'est aujourd'hui le choix par défaut raisonnable. Perdre le 25 sortant vous empêche d'envoyer vers le monde ; perdre le 25 entrant empêche le monde de vous envoyer du courrier, et il est tout à fait possible d'avoir l'un sans l'autre et de passer une après-midi à accuser le DNS.

Sur BitVPS, le 25 sortant est débloqué par défaut sur toutes les offres et dans tous les emplacements. Il n'y a ni formulaire ni procédure d'exception, parce qu'il n'y a rien à lever. Le 25, le 465 et le 587 entrants passent derrière un nettoyage conscient du protocole mail plutôt que derrière un filtre générique en couche 3, ce qui fait toute la différence pendant une attaque : un filtre qui comprend le SMTP peut absorber une inondation de trafic sans emporter avec elle la conversation MX légitime. La page serveur mail donne les détails, et le guide anti-DDoS explique plus généralement ce qu'un tel nettoyage protège et ne protège pas.

Un port 25 ouvert est une condition nécessaire, très loin d'être suffisante — et c'est bien pour ça que ce guide continue sur encore trois mille mots.

L'adresse qu'on vous attribue pèse plus lourd que votre configuration

Votre configuration, c'est une poignée d'enregistrements DNS et une journée de travail. L'adresse IP, elle, c'est un passé que vous n'avez pas écrit. Un /24 qui a passé 2019 à envoyer du spam pharmaceutique, on s'en souvient ; une adresse recyclée d'un client résilié le mois dernier arrive déjà jugée ; une plage dont les voisins sont bruyants est jugée par association chez les destinataires qui notent au niveau du /24. Rien de tout cela n'est visible depuis l'intérieur de la machine, et rien de tout cela ne se corrige avec un meilleur main.cf.

Mieux vaut donc vérifier avant de s'engager que après. Les listes noires publiques racontent une partie de l'histoire : Spamhaus est celle qui influence vraiment la délivrabilité, avec la SBL et la CSS qui listent les expéditeurs observés, la PBL qui liste les plages dont l'opérateur a déclaré qu'elles ne devraient pas envoyer de mail directement, et la DBL qui liste des domaines plutôt que des adresses. Barracuda et SpamCop valent le coup d'œil et se nettoient vite une fois la cause corrigée. Les deux réputations qui décident de l'essentiel de votre sort, en revanche, sont privées : Google et Microsoft tiennent chacun des scores par IP et par domaine que vous ne pouvez consulter que via Postmaster Tools et SNDS, et seulement une fois que vous envoyez assez de courrier pour qu'ils aient un avis.

Deux mises en garde sur les check-lists que vous trouverez ailleurs. La moitié d'entre elles vous disent encore de vérifier SORBS : SORBS a été mis hors service par son propriétaire le 5 juin 2024, et ses zones ne répondent plus rien désormais, si bien qu'une consultation dessus n'est pas un certificat de bonne santé mais une requête morte. Et traitez les niveaux 2 et 3 d'UCEPROTECT avec scepticisme — ils listent des voisins et des systèmes autonomes entiers par association, puis vous invitent à payer pour un retrait accéléré, ce qui explique que la plupart des destinataires sérieux les ignorent. Courir après un listage de niveau 3 est une façon de passer un week-end à ne rien accomplir. C'est le portail de réputation de Spamhaus lui-même qu'il faut prendre au sérieux.

C'est aussi là qu'un hébergeur aide, ou n'aide pas. BitVPS vérifie chaque adresse sur les principales listes lors du provisionnement et la remplace avant même votre première connexion si elle y figure, alloue les clients mail à partir de /29 qui n'ont pas servi à un précédent client mail depuis douze mois, et peut déplacer un /29 entre machines d'un même datacenter sans vous changer d'IP — ce qui compte énormément une fois qu'une adresse porte une réputation que vous avez mis six mois à construire. Rien de tout cela ne rend une adresse bonne ; cela la rend neutre, ce qui est le maximum qu'un hébergeur puisse honnêtement offrir.

Le PTR, le HELO et l'enregistrement A doivent raconter la même histoire

C'est la raison la plus fréquente pour laquelle un serveur mail pourtant bien installé se fait rejeter, et c'est aussi la chose la moins chère à corriger sur cette page. Trois noms doivent concorder. Votre serveur annonce un nom d'hôte dans le HELO ; ce nom d'hôte a un enregistrement A qui pointe vers l'adresse depuis laquelle il se connecte ; et cette adresse a un enregistrement PTR qui pointe en retour vers le nom d'hôte. Résolvez-le à l'aller, vous arrivez à l'adresse ; résolvez-le au retour, vous arrivez au nom. Cet aller-retour s'appelle le DNS inverse à confirmation directe (forward-confirmed reverse DNS), et depuis février 2024, un enregistrement PTR valide n'est plus un plus chez Gmail mais une exigence explicite pour tout expéditeur, en masse ou non.

Quatre façons pour que ça tourne mal, par ordre de fréquence décroissant. Il n'y a aucun PTR du tout, parce que l'hébergeur n'offre pas ce champ. Il y a un PTR, mais c'est le PTR générique du fournisseur — quelque chose qui se termine par le domaine de l'hébergeur, ce qui annonce à tout destinataire qu'il s'agit d'une adresse louée dans une plage qui, la plupart du temps, n'envoie pas de mail. Le nom HELO est faux : celui par défaut de l'installateur, un nom d'hôte court non qualifié, ou localhost, aucun des trois ne résolvant correctement. Et celle qui piège même les plus soigneux : la machine a de l'IPv6, le MTA préfère l'IPv6 quand le destinataire publie un enregistrement AAAA, et il n'y a pas de PTR sur l'adresse v6 — si bien que le mail vers Gmail en IPv4 fonctionne parfaitement pendant que le même mail en IPv6 est rejeté. Soit vous configurez correctement le PTR v6, soit vous forcez le transport avec smtp_address_preference = ipv4 en attendant.

Sur BitVPS, le champ PTR est en libre-service dans le panneau pour chaque adresse IPv4 et IPv6, il accepte n'importe quel FQDN de votre choix sans suffixe imposé par le fournisseur, les changements se propagent globalement en moins de cinq minutes, et l'édition en masse couvre jusqu'à dix adresses à la fois. La page réseau donne les détails, et voici pourquoi cela compte, exactement dans l'esprit de cette section : un hébergeur qui vous force à ouvrir un ticket pour régler le DNS inverse est un hébergeur qui vous fera ouvrir un ticket à chaque reconstruction.

SPF, DKIM et DMARC : ce que chacun prouve, et ce que signifie l'alignement

Ces trois mécanismes se publient sous forme d'enregistrements DNS, prennent une heure à mettre en place, et sont mal décrits à peu près partout — présentés comme trois amulettes anti-spam interchangeables plutôt que comme trois affirmations différentes. Le SPF (RFC 7208) indique quelles adresses ont le droit d'envoyer du mail portant un expéditeur d'enveloppe donné. Le DKIM (RFC 6376) attache une signature cryptographique sur les en-têtes et le corps, pour que le message puisse prouver quel domaine en a pris la responsabilité. Aucun des deux ne dit quoi que ce soit sur l'adresse que votre destinataire voit réellement.

C'est le rôle du DMARC (RFC 7489), et c'est pourquoi le mot qui compte est alignement. Le DMARC passe quand le SPF ou le DKIM passe et que le domaine authentifié correspond au domaine indiqué dans l'en-tête visible From:. C'est là que vit l'échec classique : votre mail passe le SPF parce que l'adresse de retour est sur un domaine que contrôle l'hébergeur d'envoi, mais ce domaine n'est pas celui du From:, donc ça ne s'aligne pas, et sans signature DKIM sur laquelle se rabattre, le DMARC échoue sur un message qui semblait pourtant parfaitement authentifié dans les logs. L'autre classique consiste à publier p=reject dès le premier jour, avant d'avoir lu le moindre rapport, et à découvrir un mois plus tard que le système de facturation a été rejeté en silence pendant tout ce temps. Commencez par p=none avec une adresse rua, lisez ce qui arrive, puis resserrez ensuite.

Deux notes opérationnelles qui valent plus qu'elles n'en ont l'air. Gardez l'enregistrement SPF sous les dix résolutions DNS — chaque include: en coûte une, et empiler trois fournisseurs SaaS dépasse la limite et se transforme en erreur permanente plutôt qu'en simple échec léger. Et faites tourner les sélecteurs DKIM de temps en temps plutôt que jamais : un sélecteur ne coûte rien à ajouter, et en avoir déjà un second publié fait toute la différence entre une rotation de clé de cinq minutes et une panne.

Le plancher a bougé en 2024, puis encore en 2025

Pendant vingt ans, la base minimale pour envoyer du courrier a été à peu près « avoir un PTR et ne pas être sur Spamhaus ». Cela a changé en février 2024, quand Google et Yahoo ont publié des exigences pour les expéditeurs quasiment identiques et ont commencé à les faire respecter. Tout expéditeur — vous y compris, avec vos quatre messages par jour — a désormais besoin d'un enregistrement PTR valide à confirmation directe, du TLS sur la connexion, et d'au moins l'un des deux, SPF ou DKIM. Les expéditeurs au-dessus d'environ cinq mille messages par jour vers un même destinataire ont besoin du SPF et du DKIM et d'un enregistrement DMARC, d'un en-tête de désabonnement en un clic fonctionnel selon la RFC 8058, et d'un taux de plaintes pour spam maintenu sous 0.3%.

Microsoft a suivi le 5 mai 2025 avec une règle de même forme pour Outlook.com, Hotmail et Live : les domaines qui envoient plus de cinq mille messages par jour vers ces boîtes grand public doivent avoir SPF, DKIM et DMARC, le courrier non conforme étant d'abord dirigé vers les indésirables puis, ensuite, purement et simplement rejeté. Le support expéditeurs de Microsoft et les bonnes pratiques de Yahoo méritent tous deux dix minutes de lecture avant d'envoyer quoi que ce soit.

La conséquence pratique pour un serveur personnel ou de petite équipe n'est pas que ces seuils vous rattrapent — ils ne le feront pas — mais que l'absence totale d'authentification est désormais réellement anormale. Un mail sans enregistrement DMARC venant d'une adresse sans historique, c'était banal autrefois. En 2026, cela ressemble exactement au profil que les filtres ont été construits pour arrêter. Configurez-vous comme si vous étiez un expéditeur en masse même si vous ne l'êtes pas, car cela coûte une après-midi, et l'alternative est d'être noté par rapport à une population à laquelle vous n'appartenez pas.

Faire chauffer une adresse que personne n'a jamais vue

Une nouvelle adresse ne démarre pas tant neutre qu'inconnue, et l'inconnu est traité avec une suspicion proportionnelle au volume que vous envoyez. La montée en charge qui fonctionne est ennuyeuse : commencez par une correspondance authentique avec des gens qui vont réellement l'ouvrir et y répondre, gardez un volume quotidien à peu près stable et laissez-le croître progressivement plutôt que par paliers, et ne pointez jamais une liste achetée ou exportée de quelque part vers une adresse toute neuve. L'engagement est le signal qui fait passer de l'inconnu au fiable, et il n'existe aucun raccourci pour le produire.

Mesurez avec les outils que vous donnent les destinataires plutôt qu'en regardant votre propre boîte de réception. Le Postmaster Tools de Google affiche la réputation du domaine et de l'IP, les taux de plaintes pour spam et les taux de réussite d'authentification une fois le domaine vérifié — même s'il reste vide tant que vous n'envoyez pas assez pour qu'il ait quelque chose à agréger, ce qui pour un serveur personnel peut vouloir dire jamais, et ce n'est pas grave. Le SNDS de Microsoft fait la même chose pour Outlook.com et se combine avec le Junk Mail Reporting Program, qui vous transmet directement les plaintes. Un service de notation ponctuel est utile pour repérer un enregistrement cassé en dix secondes, et inutile pour tout le reste — il ne vous dit rien sur votre réputation, puisqu'il n'a lui non plus aucun historique avec vous.

Soyez honnête sur le destinataire le plus difficile. Outlook.com est celui où une nouvelle adresse peine le plus longtemps : il est courant qu'un serveur correctement configuré, avec une authentification parfaite, soit classé en indésirables là-bas pendant des semaines, alors que Gmail l'accepte dès le premier message. Le remède, c'est le temps, la régularité et des destinataires qui sortent le message des indésirables — pas un enregistrement DNS de plus. Si la délivrabilité chez Outlook.com dès le premier jour est une exigence métier plutôt qu'une préférence, c'est l'un des signes qu'il vous faut un relais plutôt qu'un expéditeur auto-hébergé, ce qui fait l'objet de la dernière section.

Quoi faire tourner, et de quelle machine on a besoin

Quatre formules couvrent presque tout le monde. Postfix associé à Dovecot pour l'IMAP et à rspamd pour le filtrage, c'est le déploiement de référence : trois démons, une configuration en texte brut, et chaque message d'erreur que vous verrez a déjà sa réponse quelque part. OpenSMTPD fait le même travail avec un fichier de configuration qui se lit d'une traite, ce qui vaut plus que ça n'en a l'air à trois heures du matin. Stalwart est un binaire unique qui parle SMTP, IMAP et JMAP avec le filtrage intégré, et c'est aujourd'hui l'option la plus agréable pour repartir de zéro. Et Mailcow ou Mail-in-a-Box assemblent tout pour vous, webmail compris, au prix d'une pile que vous n'avez pas choisie et qu'on ne démonte pas facilement.

Le dimensionnement dépend moins du nombre de boîtes que de ce qu'on greffe devant. Le SMTP et l'IMAP eux-mêmes ne coûtent presque rien ; quelques dizaines de boîtes mail sont une erreur d'arrondi sur n'importe quelle machine moderne. La mémoire, elle, part dans le filtrage. rspamd est modeste, quelques centaines de mégaoctets une fois ses cartes chargées. ClamAV, lui, ne l'est pas : sa seule base de signatures le pousse bien au-delà du gigaoctet de mémoire résidente, et c'est le composant le plus susceptible de faire swapper une petite instance — ce qui, sur un serveur mail, veut dire que la file d'attente s'engorge et que la livraison ralentit au point que les destinataires commencent à vous différer. Faites-le tourner si vous avez la RAM, passez-le si vous ne l'avez pas, et laissez rspamd porter la charge.

Ramené à des offres réelles : un Starter à $8.50 avec 2 vCPU, 4 GB de RAM et 60 GB de NVMe fait tourner Postfix, Dovecot et rspamd confortablement pour un domaine personnel, à condition de laisser ClamAV de côté. Un Growth à $13.50 avec 4 vCPU, 8 GB et 120 GB est la taille à partir de laquelle on arrête d'y penser — vingt à trente boîtes mail avec filtrage complet, largement de quoi voir venir pour un stockage de mail qui grossit pendant des années. Le stockage est l'axe qui manque réellement en premier, parce que le mail, tout le monde qui en a reçu le garde pour toujours.

Le mettre en place dans le bon ordre

1. Pointer le domaine et déployer l'instance. Décidez du nom d'hôte sous lequel le serveur s'identifiera — mail.example.com est la convention — publiez son enregistrement A, ajoutez un AAAA seulement si vous comptez envoyer en IPv6, et publiez le MX du domaine pointant vers ce nom. Choisissez l'emplacement le plus proche des personnes avec qui vous correspondez ; sur BitVPS, l'instance est en ligne environ soixante secondes après la confirmation du paiement, avec le 25 sortant déjà ouvert.

2. Régler le DNS inverse en conséquence. Réglez le PTR de l'adresse IPv4 — et de l'adresse IPv6, si vous avez publié un AAAA — exactement sur le nom d'hôte de l'étape un. L'aller et le retour doivent concorder dans les deux sens. C'est un seul champ dans le panneau, et c'est la minute la plus rentable de toute la procédure.

3. Ouvrir les bons ports dans les deux sens. Le 25 sortant pour délivrer, le 25 entrant pour recevoir, le 587 et le 465 pour que vos propres utilisateurs soumettent leur courrier, le 993 pour l'IMAP, tout le reste fermé. Un pare-feu qui autorise le 25 sortant mais pas l'entrant ressemble exactement à un problème de DNS pendant la première heure de débogage, et ce n'en est pas un.

4. Installer le MTA et lui donner une vraie identité. Postfix, OpenSMTPD ou Stalwart ; réglez le nom HELO sur le nom d'hôte de l'étape un ; activez le TLS avec un certificat pour ce nom. Let's Encrypt est gratuit et c'est ce que présente la majorité d'Internet. Envoyez-vous un message et lisez les en-têtes avant de continuer — chaque étape suivante suppose que celle-ci a fonctionné.

5. Publier SPF, DKIM et DMARC. Un enregistrement SPF listant l'adresse d'envoi, se terminant par ~all pendant vos tests. Une clé DKIM de 2048-bit avec son sélecteur publié et la signature activée. Un enregistrement DMARC en p=none avec une adresse rua pour que les rapports commencent à arriver. Trois enregistrements DNS, aucun coût, une heure tout au plus.

6. Lire les résultats d'authentification, pas la boîte de réception. Envoyez à Gmail, à Outlook.com et à un destinataire d'entreprise, puis ouvrez l'en-tête Authentication-Results sur chacun. Vous voulez voir spf=pass, dkim=pass, dmarc=pass, et l'alignement fait contre le domaine de l'en-tête visible From:. Atterrir en indésirables avec trois passes, c'est un problème de réputation ; y atterrir avec un échec, c'est un problème de configuration. Ils se corrigent de façons complètement différentes, et les confondre fait perdre des semaines.

7. Resserrer une fois les rapports propres. Après une ou deux semaines de rapports DMARC où aucune source légitime n'échoue, passez à p=quarantine, puis plus tard à p=reject, et changez le SPF de ~all à -all. Resserrer avant d'avoir lu les rapports, c'est ainsi qu'on bloque ses propres factures pendant un mois sans s'en apercevoir.

8. Ajouter les éléments que tout le monde oublie. Publiez MTA-STS et TLS-RPT pour que les autres expéditeurs sachent qu'il faut insister sur le TLS avec vous, ajoutez DANE si votre zone est signée, placez rspamd devant la boîte de réception, sauvegardez le stockage de mail quelque part qui n'est pas cette machine, et chiffrez-le au repos — le guide sur le chiffrement intégral du disque détaille ce que ça protège et ce que ça ne protège pas. Surveillez ensuite la file d'attente sortante : une file qui grossit discrètement est le premier symptôme d'un problème de réputation, et cela apparaît des jours avant que vous ne remarquiez des réponses manquantes.

Quand l'auto-hébergement n'est pas le bon outil

Il existe des cas où faire tourner son propre expéditeur est un mauvais calcul, et être clair là-dessus est plus utile qu'un paragraphe d'encouragement de plus. Le marketing en masse à froid en est l'exemple évident : une adresse toute neuve, sans historique, qui envoie des milliers de messages, c'est exactement la signature que les filtres existent pour attraper, et aucune configuration ne la sauve. Le mail transactionnel où un message perdu coûte de l'argent — réinitialisations de mot de passe, confirmations de commande, codes à deux facteurs — a sa place sur une infrastructure à réputation déjà établie, parce que les deux semaines qu'une nouvelle adresse passe à faire ses preuves sont deux semaines de tickets de support. Et toute équipe sans personne pour surveiller une file d'attente mail un dimanche est une équipe qui découvrira que son courrier sortant est différé depuis vendredi.

Il y a aussi un arbitrage sur l'anonymat que la plupart des articles passent sous silence. Un serveur mail est la chose la moins anonyme que vous puissiez faire tourner. Il publie un domaine, une adresse stable, un enregistrement PTR qui nomme ce domaine, un enregistrement MX qui les relie, et il remet à chaque destinataire un jeu complet d'en-têtes décrivant le trajet. Anonymat et MX public tirent dans des directions opposées, et si la raison de votre présence ici est la confidentialité plutôt que le contrôle, lisez à quel point l'hébergement crypto est réellement traçable avant de vous lancer. L'auto-hébergement retire bel et bien un tiers de votre courrier stocké et de ses métadonnées, ce qui est un gain réel et qui vaut la peine — cela ne rend pas le mail lui-même anonyme, et cela ne peut pas, parce que la moitié de chaque conversation vit dans la boîte de quelqu'un d'autre.

L'arrangement qui fonctionne pour la plupart des gens, c'est un partage. Gardez chez un fournisseur à réputation établie le courrier qui doit absolument arriver, auto-hébergez un second domaine pour la correspondance que vous voulez sortir de l'infrastructure d'un tiers, et laissez chacun porter la charge pour laquelle il est bon. Cela coûte une zone DNS de plus, cela évite que l'un ou l'autre système fasse un travail pour lequel il est mauvais, et c'est ce que fait réellement une grande partie des gens qui font tourner un serveur mail sur BitVPS. Quoi que vous envoyiez, uniquement en opt-in — les listes achetées sont en dehors de notre politique d'utilisation acceptable et c'est le moyen le plus rapide de griller une adresse qui était propre quand nous vous l'avons remise.