Délivrabilité des emails : pourquoi la configuration HELO/EHLO de votre serveur est cruciale
Un email envoyé n'est pas un email reçu. Cette distinction, souvent négligée dans la gestion quotidienne des communications d'entreprise, est pourtant au cœur de problèmes opérationnels récurrents : devis qui n'arrivent jamais chez le client, factures bloquées dans les filtres spam, confirmations de commande silencieusement rejetées. Le problème est d'autant plus difficile à détecter que l'expéditeur ne reçoit généralement aucun message d'erreur apparent — ou un message sibyllin que peu de responsables savent interpréter.
Dans la plupart des cas observés sur le terrain par les techniciens de l'Agence Easy depuis plus de vingt ans d'exploitation de serveurs de messagerie en environnement professionnel, la cause racine de ces dysfonctionnements n'est ni un contenu filtré pour son texte, ni une pièce jointe suspecte, ni même un problème de liste noire évident. Elle tient à quelque chose de bien plus structurel : une mauvaise configuration du paramètre d'identification du serveur d'envoi, communément appelé HELO ou EHLO dans le protocole SMTP.
Il y a dix ans, un serveur de messagerie mal configuré pouvait encore envoyer des emails sans trop de difficultés. Les filtres anti-spam se concentraient principalement sur le contenu des messages. Aujourd'hui, la situation a radicalement changé. Les grandes infrastructures de messagerie — Gmail, Outlook, Yahoo, OVH, et la quasi-totalité des hébergeurs professionnels — appliquent des politiques d'authentification de plus en plus strictes sur l'identité déclarée des serveurs émetteurs.
Ces exigences renforcées répondent à une réalité simple : le spam et le phishing transitent massivement par des serveurs mal configurés ou dont l'identité est délibérément falsifiée. Les systèmes de filtrage ont donc appris à traiter toute incohérence d'identification comme un signal de risque élevé. Un serveur qui se présente sous un nom ne correspondant pas à son adresse IP réelle est, aux yeux des algorithmes de filtrage, un serveur suspect — indépendamment de la légitimité de son propriétaire.
Pour comprendre pourquoi la configuration HELO/EHLO est si importante, il faut d'abord comprendre comment deux serveurs de messagerie communiquent entre eux. Ce dialogue obéit à un protocole standardisé, le protocole SMTP (Simple Mail Transfer Protocol), qui définit précisément la séquence d'échanges permettant à un serveur émetteur de remettre un message à un serveur destinataire.
Ce dialogue ressemble à une conversation formelle avec des étapes bien définies. Le serveur émetteur établit une connexion TCP sur le port 25 (ou 587 pour les clients), puis les deux serveurs s'échangent des commandes textuelles standardisées. Chaque étape de cet échange conditionne la suite : si l'une d'elles échoue ou génère une réponse négative, l'email est rejeté ou mis en quarantaine, souvent sans que l'expéditeur humain en soit informé de façon explicite.
La toute première commande qu'envoie un serveur émetteur après avoir établi la connexion est HELO (ou son successeur moderne EHLO, qui supporte les extensions SMTP). Cette commande est suivie d'un nom d'hôte : c'est littéralement la façon dont le serveur se présente. Par exemple : EHLO mail.monentreprise.fr.
Ce nom d'hôte déclaré dans le HELO/EHLO est ensuite croisé par le serveur destinataire avec plusieurs éléments vérifiables : l'adresse IP réelle d'où provient la connexion, l'enregistrement DNS de type A associé à ce nom d'hôte, et l'enregistrement PTR (reverse DNS) de l'adresse IP. Si ces trois éléments ne sont pas cohérents entre eux, le serveur destinataire dispose d'une raison solide de considérer l'émetteur comme non fiable. C'est précisément là que réside le problème dans la majorité des configurations par défaut des serveurs mutualisés ou mal paramétrés.
Le HELO/EHLO n'est qu'une première couche d'identification. Il s'inscrit dans un écosystème d'authentification plus large que tout responsable technique ou responsable digital doit maîtriser pour évaluer la solidité de son infrastructure d'envoi. Les trois mécanismes complémentaires sont SPF, DKIM et DMARC.
Le SPF (Sender Policy Framework) est un enregistrement DNS qui liste les adresses IP autorisées à envoyer des emails au nom d'un domaine. Le DKIM (DomainKeys Identified Mail) ajoute une signature cryptographique à chaque email, permettant au destinataire de vérifier que le message n'a pas été altéré en transit. Le DMARC (Domain-based Message Authentication, Reporting and Conformance) définit quoi faire lorsque SPF ou DKIM échoue, et permet au propriétaire du domaine de recevoir des rapports sur les tentatives d'envoi en son nom.
Ces trois mécanismes sont devenus des prérequis de fait pour toute communication email professionnelle. Mais ils ne suffisent pas si le HELO/EHLO est mal configuré : un email peut passer les vérifications SPF et DKIM tout en étant rejeté ou pénalisé à cause d'une incohérence dans l'identification initiale du serveur. Les couches d'authentification fonctionnent en parallèle, pas en substitution.
Le scénario le plus fréquemment rencontré dans les environnements de serveurs mutualisés ou de VPS configurés sans attention particulière est le suivant : le serveur Postfix (ou Exim, ou sendmail) est installé avec un nom d'hôte générique attribué par le fournisseur d'hébergement, souvent de type vpsXXXXX.provider.com ou dedicated-server-XXX.datacenter.net. Ce nom d'hôte est celui que le serveur va utiliser dans sa commande HELO/EHLO, indépendamment du domaine depuis lequel les emails sont envoyés.
Concrètement, cela signifie qu'un email envoyé depuis contact@monentreprise.fr sera présenté par un serveur qui se déclare comme vps12345.hebergeur.com. Le serveur destinataire va alors effectuer une vérification : est-ce que l'IP de vps12345.hebergeur.com correspond bien à l'IP d'où provient la connexion ? Est-ce que le PTR de cette IP pointe bien vers vps12345.hebergeur.com ? Dans le meilleur des cas, ces vérifications passent mais génèrent un score de méfiance. Dans le pire des cas — et c'est fréquent — elles échouent, et l'email est rejeté.
Une configuration HELO incohérente expose également le serveur à une inscription progressive dans les bases de données antispam de référence. Spamhaus, Barracuda, SpamCop, SURBL, et une dizaine d'autres organismes maintiennent des listes d'adresses IP et de domaines dont le comportement d'envoi a été jugé suspect. Ces listes sont consultées en temps réel par les serveurs destinataires lors de chaque tentative de livraison.
Un serveur qui se présente de façon incohérente, qui envoie des volumes inhabituels, ou dont le PTR reverse DNS est absent ou générique, va progressivement accumuler des signaux négatifs auprès de ces organismes. L'inscription sur une blacklist peut intervenir sans aucun comportement malveillant de la part de l'entreprise : il s'agit simplement d'une configuration technique insuffisante qui ressemble, aux yeux des algorithmes, à un comportement de spammeur.
Le problème est que la sortie d'une blacklist — notamment Spamhaus — peut être longue et fastidieuse. Certaines blacklists exigent une procédure de délisting manuelle avec justification technique. D'autres appliquent des délais automatiques. Dans tous les cas, pendant la période d'inscription, une part significative des emails envoyés depuis ce serveur n'atteindra pas sa destination.
Voici un exemple typique de message de rejet que l'on peut observer dans les logs d'un serveur Postfix mal configuré :
550 5.7.1 Service unavailable; Client host [82.XX.XX.XX] blocked using Spamhaus; https://www.spamhaus.org/query/ip/82.XX.XX.XX
Ou encore :
550-5.7.26 This message does not have authentication information or fails to pass authentication checks. To best protect our users from spam, the message has been blocked.
Ces messages, visibles uniquement dans les journaux techniques du serveur émetteur, sont rarement remontés au responsable de l'entreprise. L'email disparaît dans un silence technique. C'est pourquoi la surveillance proactive des logs de messagerie et la mise en place d'alertes sur les erreurs de livraison font partie des bonnes pratiques d'une maintenance d'hébergement sérieuse.
La correction d'un problème de HELO mal configuré repose sur un principe simple : les trois éléments qui permettent d'identifier un serveur d'envoi doivent être cohérents entre eux. Ces trois éléments sont le nom d'hôte déclaré dans la commande HELO/EHLO, l'enregistrement DNS de type A de ce nom d'hôte (qui doit résoudre vers l'IP du serveur), et l'enregistrement PTR (reverse DNS) de cette IP (qui doit pointer vers le même nom d'hôte).
Prenons un exemple concret. Si le serveur d'envoi possède l'adresse IP 82.66.XX.XX et que l'on souhaite qu'il se présente comme mail.monentreprise.fr, la configuration correcte implique : que mail.monentreprise.fr possède un enregistrement A pointant vers 82.66.XX.XX, que l'IP 82.66.XX.XX possède un enregistrement PTR (configuré auprès du fournisseur d'hébergement ou de l'opérateur réseau) pointant vers mail.monentreprise.fr, et que la directive myhostname dans la configuration Postfix soit définie sur mail.monentreprise.fr.
Lorsque ces trois éléments sont correctement alignés, le serveur destinataire peut effectuer une vérification forward-confirmed reverse DNS (FCrDNS), considérée comme l'un des indicateurs les plus fiables de la légitimité d'un serveur d'envoi.
Dans les environnements de serveurs dédiés hébergeant plusieurs domaines — ce qui est le cas typique des serveurs propriétaires de l'Agence Easy gérant plusieurs clients — la question de la configuration HELO se complexifie. Postfix, le serveur de messagerie open source le plus utilisé dans les environnements Linux professionnels, offre plusieurs directives pour gérer cette situation.
La directive smtp_helo_name dans main.cf permet de définir le nom d'hôte utilisé dans la commande EHLO lors des connexions sortantes. Elle prend par défaut la valeur de $myhostname. Dans un contexte multi-domaines, il est recommandé de définir myhostname sur le nom d'hôte principal du serveur (celui pour lequel le PTR est configuré), et de s'assurer que ce nom d'hôte principal est bien celui utilisé pour toutes les connexions sortantes, indépendamment du domaine émetteur.
Une configuration type dans /etc/postfix/main.cf pourrait ressembler à :
myhostname = mail.monserveur.fr
smtp_helo_name = $myhostname
myorigin = /etc/mailname
Il convient également de vérifier les directives mydomain, mynetworks, et inet_interfaces pour s'assurer qu'elles n'entrent pas en conflit avec la configuration du nom d'hôte. Une modification de myhostname nécessite un rechargement de Postfix (postfix reload) pour prendre effet.
Une fois la configuration modifiée, la vérification doit être méthodique. En ligne de commande, on peut tester la résolution DNS directe et inverse avec les commandes dig mail.monserveur.fr A (qui doit retourner l'IP du serveur) et dig -x 82.66.XX.XX (qui doit retourner mail.monserveur.fr). La correspondance entre ces deux résultats confirme l'alignement FCrDNS.
Pour tester manuellement la commande EHLO telle que la voit le serveur destinataire, on peut utiliser telnet ou openssl depuis un serveur externe : openssl s_client -starttls smtp -connect mail.destinataire.fr:25. Cette commande permet d'observer en temps réel le dialogue SMTP et de vérifier que le serveur destinataire accepte bien l'identification EHLO sans retourner d'erreur.
Plusieurs outils en ligne permettent d'effectuer un diagnostic complet de la délivrabilité d'un serveur de messagerie sans nécessiter de compétences techniques avancées. Ces outils sont précieux pour un premier niveau de diagnostic, même s'ils ne remplacent pas une analyse approfondie des logs serveur.
MXToolbox (mxtoolbox.com) est probablement l'outil le plus complet : il permet de vérifier les enregistrements MX, SPF, DKIM, DMARC, le reverse DNS, et de consulter plusieurs dizaines de blacklists simultanément. Mail-tester.com permet d'envoyer un email de test vers une adresse temporaire et d'obtenir un score de délivrabilité avec le détail des problèmes détectés. Google Postmaster Tools est indispensable pour les domaines qui envoient des volumes significatifs vers Gmail : il fournit des métriques sur la réputation du domaine et de l'IP expéditrice.
Ces outils permettent également de vérifier la cohérence HELO/PTR, de détecter une absence d'enregistrement DMARC, ou d'identifier une politique SPF trop permissive. L'utilisation régulière de ces outils — au moins une fois par trimestre dans un contexte d'envoi professionnel actif — permet de détecter les dérives avant qu'elles ne deviennent des incidents.
En dehors d'une analyse technique directe, plusieurs signaux métier doivent alerter un responsable d'entreprise sur un possible problème de délivrabilité. Des clients qui signalent ne jamais recevoir les emails de l'entreprise (confirmations, devis, factures), un taux de réponse aux campagnes d'emailing inhabituellement bas, des demandes de contact restées sans suite alors que l'entreprise a bien envoyé une réponse, ou encore des partenaires qui reçoivent les emails en spam alors que le contenu n'a rien d'inhabituel.
Ces signaux sont souvent attribués à tort à des problèmes de contenu, de timing, ou de comportement des destinataires. Dans une proportion significative des cas diagnostiqués par l'Agence Easy, la cause réelle était une configuration serveur défaillante — HELO incorrect, PTR absent, SPF manquant ou mal rédigé — que l'entreprise ignorait depuis des mois, voire des années.
Si un outil de vérification révèle que l'IP de votre serveur est inscrite sur une ou plusieurs blacklists, la procédure à suivre comporte deux phases distinctes. La première est de corriger la cause racine avant toute tentative de délisting : demander un retrait sans avoir résolu le problème technique sous-jacent est inutile, car l'IP sera réinscrite rapidement. La correction peut impliquer la reconfiguration du HELO, la mise en place du PTR, l'ajout ou la correction des enregistrements SPF/DKIM/DMARC, ou une combinaison de ces actions.
La seconde phase est la procédure de délisting proprement dite. Chaque organisme dispose d'une procédure spécifique : Spamhaus propose un formulaire de demande de retrait en ligne avec vérification automatique, Barracuda également, tandis que d'autres blacklists appliquent des délais automatiques de 24 heures à plusieurs semaines. Il est important de ne pas multiplier les demandes de retrait pour la même IP : cela peut être interprété comme un comportement agressif et retarder le processus.
La gestion de ces incidents fait partie intégrante des services de sécurité et maintenance web proposés par l'Agence Easy, qui intervient régulièrement sur ces sujets dans le cadre de la gestion de ses serveurs propriétaires hébergeant des dizaines de clients en Provence et dans la région PACA.
La délivrabilité des emails est un sujet technique qui a des conséquences très concrètes sur l'activité d'une entreprise. Un serveur bien configuré — avec un HELO/EHLO cohérent, un PTR aligné, des enregistrements SPF, DKIM et DMARC correctement renseignés — est un serveur dont on n'entend jamais parler. Les emails partent, arrivent, et la communication s'effectue sans friction. C'est la normalité attendue, et c'est aussi la marque d'une infrastructure maîtrisée.
À l'inverse, un serveur mal configuré génère des problèmes qui s'accumulent silencieusement : réputation dégradée, inscriptions progressives sur des blacklists, taux de livraison en baisse, et finalement des pertes commerciales réelles — opportunités manquées, relations client détériorées, confiance érodée. Ces conséquences sont d'autant plus difficiles à quantifier qu'elles se manifestent par des absences (emails non reçus) plutôt que par des événements visibles.
L'une des leçons récurrentes de vingt années de gestion d'infrastructures de messagerie professionnelle est que les problèmes de délivrabilité sont rarement pris au sérieux tant qu'ils n'ont pas atteint un niveau de gravité suffisant pour perturber l'activité. La maintenance préventive, la surveillance proactive et la configuration rigoureuse dès le départ sont les seules approches réellement efficaces. Le protocole IMAP/POP3 pour la réception des emails et le protocole SMTP pour leur envoi forment ensemble une chaîne dont chaque maillon doit être correctement paramétré.
L'Agence Easy, agence web et SEO basée à Saint-Rémy-de-Provence depuis 2006, exploite depuis ses débuts une infrastructure de serveurs propriétaires dédiés à l'hébergement de ses clients. Cette indépendance technique — rare dans le paysage des agences web régionales — permet une maîtrise complète de la chaîne d'envoi des emails : configuration Postfix, gestion des PTR, déploiement des politiques SPF/DKIM/DMARC, surveillance des blacklists et intervention rapide en cas d'incident.
Les diagnostics menés sur des infrastructures de messagerie présentant des problèmes de délivrabilité révèlent invariablement les mêmes configurations insuffisantes : HELO générique non aligné avec le PTR, enregistrements DMARC absents, SPF trop permissif avec le mécanisme +all. Ces problèmes sont techniquement simples à corriger une fois identifiés, mais leur identification nécessite une expertise que la plupart des prestataires d'hébergement généralistes ne déploient pas proactivement.
Si votre entreprise dépend de ses emails pour communiquer avec ses clients, prospects ou partenaires — ce qui est le cas de la quasi-totalité des structures professionnelles — la question de la délivrabilité mérite une attention technique sérieuse. Elle mérite en particulier d'être auditée avant qu'un incident ne survienne, plutôt qu'en réaction à des pertes de communication déjà constatées. L'hébergement sécurisé avec maintenance proactive proposé par l'Agence Easy intègre cette dimension comme un composant standard, pas comme une option.
