Courriel : HELO/EHLO incorrect — corrigez-le avant que les fournisseurs ne vous limitent

décembre 11, 2025 • février 3, 2026 • Lecture : 26 min • Views: 7

Cet article vous a aidé ?

Vos envois sortants « fonctionnent » jusqu’à ce qu’ils ne fonctionnent plus. Puis, un matin, l’équipe commerciale signale que les propositions arrivent avec plusieurs heures de retard,
les réinitialisations de mot de passe arrivent après que l’utilisateur ait cliqué rageusement sur « renvoyer » douze fois, et votre supervision est au vert parce que la file
d’attente se vide techniquement… juste pas à un rythme humain.

Une des causes les plus silencieuses est aussi l’une des plus stupides : votre serveur SMTP se présente avec un nom HELO/EHLO bidon.
Les gros fournisseurs le remarquent. Certains vont vous limiter. D’autres vous refuseront carrément. Et le pire, c’est que vous pouvez fonctionner ainsi
pendant des mois — jusqu’à ce qu’un ajustement de politique, une variation de réputation IP ou un nouveau pool de relais sortants transforme votre « petite mauvaise config »
en incident.

À quoi sert vraiment HELO/EHLO (et pourquoi les fournisseurs s’en soucient)

Le SMTP commence par des présentations. Le client se connecte, le serveur affiche une bannière, puis le client envoie soit :
HELO (à l’ancienne) soit EHLO (ESMTP). Cette unique ligne contient un « nom » que le client
revendique comme identité. Ce n’est pas de l’authentification. Ce n’est pas une preuve cryptographique. C’est une assertion — souvent honnête, parfois négligée,
parfois malveillante.

Les fournisseurs destinataires s’en soucient encore car HELO/EHLO agit comme un signal précoce et peu coûteux. C’est une partie d’une histoire de cohérence plus large :
le reverse DNS de l’IP semble-t-il sensé, s’aligne-t-il avec le nom revendiqué, le nom du certificat TLS correspond-il à l’identité présentée, le domaine d’enveloppe a-t-il SPF,
DKIM est-il valide, DMARC est-il aligné, le comportement correspond-il à l’historique ? HELO/EHLO est un fil dans cette tapisserie. Un fil effiloché ne vous coulera pas toujours.
Trop de fils effilochés, et vous êtes dans la voie lente.

En pratique, les fournisseurs traitent un HELO/EHLO défaillant comme l’un des cas suivants :

Infrastructure mal configurée (pas malveillant, mais peu professionnel)
Hôte compromis (un PC de bureau qui se fait passer pour un serveur de mail)
Expéditeur en masse qui triche (les raccourcis tuent la délivrabilité)

Qu’est-ce qui compte comme « mauvais » ? Les classiques :

HELO/EHLO est localhost, localhost.localdomain ou un nom interne.
HELO/EHLO est un littéral IP ou une IP entre crochets alors que ce n’est pas approprié.
HELO/EHLO est un domaine sans enregistrement A/AAAA.
HELO/EHLO est un domaine qui résout, mais n’aligne pas avec les attentes de reverse DNS.
HELO/EHLO change de façon imprévisible entre les tentatives ou au sein d’un pool de relais.

Si vous exploitez des mails en production, vous voulez que le côté récepteur voie un nom de domaine pleinement qualifié (FQDN), routable et stable que vous contrôlez,
avec DNS direct et inverse correspondants quand c’est possible. Pas parce qu’une norme exige la perfection, mais parce que la délivrabilité est un ensemble d’heuristiques,
et vous n’avez pas voix au chapitre.

Faits intéressants et contexte historique

Six à dix points rapides, parce que l’histoire explique les politiques étranges d’aujourd’hui :

HELO précède la plupart des mesures anti-spam modernes. Le SMTP ancien supposait des réseaux coopératifs ; « l’identité » servait surtout à la journalisation et à la cohérence du routage.
EHLO est arrivé avec ESMTP pour négocier des fonctionnalités. Ce n’est pas juste un salut ; cela débloque des extensions comme SIZE et STARTTLS selon le serveur.
Le reverse DNS est devenu un pilier anti-abus à l’époque du spam. Les fournisseurs se sont reposés sur le PTR parce que les botnets avaient du mal à le maintenir de façon cohérente.
Certains récepteurs traitent toujours l’absence de PTR comme suspecte. Ce n’est pas toujours une violation de l’IETF, mais c’est fortement corrélé aux sources de courrier indésirable.
Les contrôles HELO existaient dans les configurations MTA bien avant SPF. Beaucoup de jeux de règles Postfix/Sendmail utilisaient des vérifications HELO comme filtrage peu coûteux.
Les systèmes de réputation IP intègrent les anomalies de salutation. Un EHLO de localhost depuis une IP publique ressemble à une machine compromise, parce que c’est souvent le cas.
TLS a rendu l’identité plus compliquée. Vous avez maintenant le nom de bannière, le nom EHLO et le nom de certificat ; les incohérences peuvent déclencher des pénalités de score.
L’essor du cloud a augmenté les risques de désalignement. Les pools autoscalés et les noms d’hôtes éphémères facilitent l’envoi d’un MTA qui « fonctionne » mais qui se présente mal.
La délivrabilité est devenue cruciale pour le produit. Les réinitialisations de mot de passe et les codes MFA ne sont pas des « emails marketing » ; le throttling devient un problème de disponibilité.

Comment un HELO/EHLO erroné échoue en production

1) Throttling doux qui ressemble à une « lenteur aléatoire »

Beaucoup de fournisseurs préfèrent limiter plutôt que rejeter. Ils accepteront un petit flux et différeront le reste avec des échecs temporaires
(réponses 4xx). Votre MTA réessaie. La file augmente. Finalement, les utilisateurs s’énervent.

La preuve évidente n’est pas une panne totale ; c’est une falaise du temps de livraison. Et parce que les réessais peuvent « finir par réussir », l’équipe d’astreinte
s’en tient parfois à l’idée que ce n’est pas une vraie panne. Ce haussement d’épaules est la manière dont vous obtenez une voie lente permanente.

2) Rejets fermes avec des messages d’erreur peu utiles

Certains récepteurs rejettent avec « bad HELO » ou « invalid hostname », ce qui est au moins honnête. D’autres renvoient des échecs de politique vagues.
Si vos logs ne conservent pas le texte de la réponse distante, vous le diagnostiquerez mal comme « fournisseur instable ».

3) Dégradation de réputation : vous ne la voyez pas tant que c’est critique

Un EHLO incorrect peut être toléré quand la réputation IP/domaine est impeccable. Plus tard, un compte compromis envoie un pic de mails spammy,
ou une nouvelle IP sortante chauffe mal, et soudain le scoring du récepteur bascule. Votre mauvaise configuration HELO devient l’excuse commode pour vous pénaliser.

4) Les incohérences TLS et d’identité s’accumulent

Si votre EHLO dit mail.example.com mais que votre certificat TLS est pour smtp-out.example.net, et que votre PTR est
ec2-203-0-113-10.compute-1.amazonaws.com, vous avez construit un petit musée d’incohérences. Aucune divergence unique n’est toujours fatale.
La collection l’est.

Idée paraphrasée de Werner Vogels (CTO d’Amazon) : « Tout échoue tout le temps ; concevez pour détecter et récupérer. » L’identité dans l’email fait partie de la détection — côté récepteur.

Blague n°1 : Votre serveur mail disant « HELO localhost » revient à arriver à une réunion client avec un badge « Bonjour, je suis quelqu’un d’autre. »
Personne n’est arrêté, mais personne ne vous fait confiance non plus.

Playbook de diagnostic rapide

Quand la livraison ralentit ou que les rebonds augmentent, ne commencez pas par faire tourner les clés API ou blâmer DNS « en général ». Faites ceci, dans l’ordre, et vous trouverez généralement
le goulot d’étranglement en moins de 20 minutes.

Première étape : confirmez si le récepteur vous diffère ou vous rejette

Vérifiez les logs sortants pour des différements 4xx et leur texte.
Identifiez les domaines de destinataires les plus différés (Gmail, Microsoft, Yahoo, domaines d’entreprises personnalisés).
Confirmez si les mêmes destinataires réussissent quelques heures plus tard (comportement classique de throttling).

Deuxième étape : capturez la conversation SMTP exacte que votre client présente

La bannière que vous recevez du distant.
Votre chaîne EHLO/HELO.
Si STARTTLS change quelque chose.
Si le distant se plaint explicitement du HELO/EHLO.

Troisième étape : vérifiez l’alignement des identités (EHLO ↔ DNS direct ↔ DNS inverse ↔ TLS)

Le nom EHLO se résout-il (A/AAAA) ?
L’IP de connexion a-t-elle un PTR, et semble-t-il sensé ?
Le PTR résout-il de nouveau vers l’IP de connexion (FCrDNS), quand c’est possible ?
Le nom du certificat TLS est-il cohérent avec l’identité que vous revendiquez ?

Quatrième étape : vérifiez la configuration MTA et le routage des expéditeurs

Utilisez-vous plusieurs relais ou des IP d’egress NAT ?
Le HELO est-il surchargé par transport, expéditeur ou relayhost ?
Une « optimisation » a-t-elle changé cela récemment (image conteneur, template autoscaling, nouveau relais) ?

Cinquième étape : seulement alors, vérifiez SPF/DKIM/DMARC

Ces mécanismes sont extrêmement importants. Mais lorsque vous dépannez un throttling qui a commencé juste après un changement d’IP sortante ou la reconstruction de nœuds mail,
HELO/EHLO et reverse DNS sont le gain le plus rapide. Corrigez votre introduction avant de négocier la confiance.

Tâches pratiques : commandes, sorties, décisions

Voici des vérifications réelles que vous pouvez exécuter depuis un hôte mail ou une machine de diagnostic proche. Chaque tâche inclut :
une commande, une sortie d’exemple, ce que cela signifie, et la décision à prendre.

Task 1: See what your server sends as EHLO (from logs)

cr0x@server:~$ sudo grep -R "EHLO" /var/log/mail.log | tail -n 5
Jan 03 09:12:41 mx1 postfix/smtp[22104]: <remote>: EHLO localhost
Jan 03 09:13:02 mx1 postfix/smtp[22177]: <remote>: EHLO mx1.internal
Jan 03 09:13:30 mx1 postfix/smtp[22230]: <remote>: EHLO mail.example.com
Jan 03 09:14:05 mx1 postfix/smtp[22301]: <remote>: EHLO localhost.localdomain
Jan 03 09:14:40 mx1 postfix/smtp[22392]: <remote>: EHLO mail.example.com

Ce que cela signifie : Vos clients présentent des valeurs EHLO incohérentes : localhost, des noms internes, et un FQDN correct.

Décision : Arrêtez le hasard. Configurez un nom EHLO unique et stable pour le SMTP sortant et assurez-vous que tous les nœuds l’utilisent.

Task 2: Reproduce the SMTP conversation with OpenSSL (STARTTLS)

cr0x@server:~$ openssl s_client -starttls smtp -crlf -connect gmail-smtp-in.l.google.com:25 -servername gmail-smtp-in.l.google.com < /dev/null
CONNECTED(00000003)
---
220 mx.google.com ESMTP
---
no peer certificate available
---

Ce que cela signifie : Vous pouvez atteindre le port 25 et obtenir une bannière. Cela ne prouve que la connectivité, pas votre EHLO. Vous devez réellement parler SMTP.

Décision : Utilisez une session interactive pour envoyer EHLO et observer les réponses du serveur (tâche suivante).

Task 3: Speak SMTP interactively and see if EHLO triggers policy

cr0x@server:~$ nc -v gmail-smtp-in.l.google.com 25
Connection to gmail-smtp-in.l.google.com 25 port [tcp/smtp] succeeded!
220 mx.google.com ESMTP
EHLO localhost
550-5.7.1 Invalid HELO/EHLO domain. See https://support.google.com/mail/?p=InvalidHelo
550 5.7.1 Bad HELO/EHLO

Ce que cela signifie : Le récepteur rejette explicitement votre valeur EHLO. Ce n’est pas une histoire de réputation fantôme ; c’est une mauvaise configuration concrète.

Décision : Corrigez immédiatement le nom EHLO. En attendant, les réessais ne serviront à rien : vous subissez un blocage de politique.

Task 4: Validate the EHLO name resolves (forward DNS)

cr0x@server:~$ dig +short A mail.example.com
203.0.113.10

Ce que cela signifie : Le nom EHLO a un enregistrement A. C’est le minimum requis.

Décision : Continuez : vérifiez aussi AAAA et si cette IP est réellement votre egress.

Task 5: Check AAAA presence (don’t surprise yourself with IPv6)

cr0x@server:~$ dig +short AAAA mail.example.com

Ce que cela signifie : Aucun enregistrement IPv6. C’est acceptable si vous n’envoyez pas via IPv6. C’est aussi un indice : si vous envoyez via IPv6, vous pourriez utiliser un chemin/nom différent.

Décision : Confirmez quelle famille d’IP votre MTA utilise réellement pour atteindre les grands fournisseurs.

Task 6: Identify the actual outbound IP (don’t guess)

cr0x@server:~$ curl -s ifconfig.me
203.0.113.10

Ce que cela signifie : L’IP publique d’egress par défaut de cet hôte est 203.0.113.10 (au moins pour HTTP). Le SMTP peut différer s’il y a routage policy ou relais.

Décision : Recoupez avec les logs et les règles NAT/pare-feu ; ne supposez pas que l’IP de curl est l’IP SMTP.

Task 7: Check reverse DNS (PTR) for the outbound IP

cr0x@server:~$ dig +short -x 203.0.113.10
mail.example.com.

Ce que cela signifie : Le PTR pointe vers mail.example.com. C’est la bonne voie : l’IP revendique un nom que vous contrôlez.

Décision : Assurez-vous que votre nom EHLO correspond à ce PTR (ou au moins est dans le même domaine contrôlé avec DNS direct cohérent).

Task 8: Check forward-confirmed reverse DNS (FCrDNS)

cr0x@server:~$ host mail.example.com
mail.example.com has address 203.0.113.10

Ce que cela signifie : PTR → nom, et nom → même IP. Beaucoup de récepteurs apprécient cette symétrie.

Décision : Si cela échoue, corrigez le DNS avant d’ajuster la configuration MTA. Les récepteurs utilisent cela comme indice de confiance.

Task 9: Inspect what Postfix thinks your hostname/HELO is

cr0x@server:~$ sudo postconf -n | egrep '^(myhostname|mydomain|smtp_helo_name|smtp_helo_timeout|smtp_host_lookup|inet_protocols)'
myhostname = mx1.internal
mydomain = internal
inet_protocols = all

Ce que cela signifie : Votre myhostname est un nom uniquement interne, et vous n’avez pas défini smtp_helo_name. Postfix peut utiliser $myhostname comme EHLO. Voilà comment vous en arrivez à dire « hi, I’m mx1.internal » à Gmail.

Décision : Définissez myhostname sur un FQDN public ou définissez smtp_helo_name sur le FQDN public utilisé pour les salutations sortantes (souvent plus sûr quand la nomenclature interne doit rester).

Task 10: Apply a safe Postfix EHLO fix (and verify)

cr0x@server:~$ sudo postconf -e 'smtp_helo_name = mail.example.com'
cr0x@server:~$ sudo systemctl reload postfix
cr0x@server:~$ sudo postconf smtp_helo_name
smtp_helo_name = mail.example.com

Ce que cela signifie : Le SMTP sortant devrait maintenant utiliser mail.example.com pour l’EHLO.

Décision : Retestez immédiatement avec une session SMTP distante (Task 3), et surveillez les changements de réponse de politique.

Task 11: Confirm Exim’s HELO setting (if you run Exim)

cr0x@server:~$ sudo exim -bP helo_data
helo_data =

Ce que cela signifie : Aucune surcharge HELO explicite n’est définie. Exim en déduira souvent le nom d’hôte système dans de nombreuses configurations.

Décision : Si le nom d’hôte système est interne ou instable, définissez un helo_data cohérent sur un FQDN public et assurez-vous que le DNS est aligné.

Task 12: Verify the system hostname isn’t sabotaging you

cr0x@server:~$ hostname -f
mx1.internal

Ce que cela signifie : Votre OS croit que son FQDN est interne. Beaucoup de MTA prennent par défaut ce nom pour les salutations à moins qu’on ne le surcharge.

Décision : Corrigez le FQDN de l’hôte pour un nom public (si approprié) ou configurez explicitement le nom HELO de l’MTA pour le trafic sortant.

Task 13: Check what you present on the receiving side (banner vs EHLO)

cr0x@server:~$ sudo postconf -n | egrep '^(smtpd_banner|myhostname)'
myhostname = mx1.internal
smtpd_banner = $myhostname ESMTP

Ce que cela signifie : Votre bannière entrante annonce mx1.internal. Ce n’est pas la même chose que l’EHLO, mais c’est une autre surface d’identité. Certains récepteurs et analyseurs corrèlent ces signaux lorsque votre serveur agit aussi comme client ailleurs (chaînes de relais, smarthost).

Décision : Si cet hôte est accessible publiquement, corrigez myhostname et la bannière. S’il est uniquement sortant derrière un relais, priorisez l’EHLO sortant mais évitez de divulguer des domaines internes si possible.

Task 14: Confirm you’re not accidentally sending from IPv6 with broken rDNS

cr0x@server:~$ postconf -n | grep inet_protocols
inet_protocols = all

Ce que cela signifie : Postfix peut utiliser IPv6. Si votre réseau a un egress IPv6 mais pas de PTR pour l’adresse v6, vous pouvez être throttlé ou bloqué d’une manière qui paraît « aléatoire », car certaines destinations préfèrent v6.

Décision : Si vous ne pouvez pas maintenir rDNS et réputation IPv6 pour l’instant, envisagez inet_protocols = ipv4 temporairement pendant que vous corrigez le v6 correctement.

Task 15: Observe real-time queue pressure while you fix identity

cr0x@server:~$ mailq | head -n 20
-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
3F2A81C04E*     2199 Fri Jan  3 09:10:12  noreply@example.com
                                         user@gmail.com
                                         (host gmail-smtp-in.l.google.com[142.250.102.26] said: 550 5.7.1 Bad HELO/EHLO (in reply to EHLO command))

Ce que cela signifie : La file enregistre explicitement le rejet distant lié à EHLO. C’est la cause racine en clair.

Décision : Corrigez EHLO puis videz la file sélectivement. Ne purgez pas aveuglément — vos utilisateurs veulent leurs mails.

Task 16: After fixing, force a retry and confirm acceptance

cr0x@server:~$ sudo postqueue -f
cr0x@server:~$ sudo tail -n 20 /var/log/mail.log
Jan 03 09:22:10 mx1 postfix/smtp[24511]: 3F2A81C04E: to=<user@gmail.com>, relay=gmail-smtp-in.l.google.com[142.250.102.26]:25, delay=716, delays=715/0.01/0.2/0.3, dsn=2.0.0, status=sent (250 2.0.0 OK  1704273730 a1-20020a170902d1c100b003d7f9c0d1a9si1234567plb.123 - gsmtp)

Ce que cela signifie : Le message a été accepté (2.0.0). Votre correctif a probablement fonctionné. Le long délai reflète le temps passé à échouer avant la correction.

Décision : Surveillez l’amélioration durable : profondeur de file, taux de différements par domaine, et taux de plaintes. Un envoi réussi n’est pas une tendance.

Erreurs courantes : symptômes → cause → correctif

1) Symptom: Gmail rejects with “Bad HELO/EHLO”

Cause : EHLO est localhost, un domaine interne, ou invalide (pas de point, pas de DNS).

Correctif : Configurez l’HELO/EHLO sortant sur un FQDN public que vous contrôlez (Postfix : smtp_helo_name ; Exim : helo_data), et assurez-vous qu’il se résout.

2) Symptom: Microsoft 365 accepts some mail then defers heavily (4xx)

Cause : Identité incohérente : EHLO qui tourne entre nœuds/IP, ou EHLO non aligné avec PTR/réputation.

Correctif : Standardisez l’EHLO au sein du pool d’expédition et alignez le reverse DNS pour chaque IP. Si vous utilisez plusieurs IP d’egress, chacune doit avoir un PTR sensé dans la même famille de domaine.

3) Symptom: Deliverability fine for weeks, then suddenly slow after a rebuild

Cause : Une nouvelle image/template a rétabli le nom d’hôte sur localhost.localdomain ou modifié le comportement cloud-init. Le MTA salue maintenant incorrectement.

Correctif : Codifiez l’HELO dans la gestion de configuration. Ajoutez un test d’intégration post-déploiement qui initie une session SMTP et vérifie la chaîne EHLO.

4) Symptom: Only some destinations fail, others fine

Cause : Les fournisseurs ont des rigidités HELO différentes ; certains sont tolérants, d’autres non. Ou vous êtes en dual-stack et seul le chemin IPv6 échoue.

Correctif : Vérifiez les logs par domaine et confirmez quelle famille d’IP est utilisée. Si IPv6 est en cause, corrigez le rDNS v6 ou forcez temporairement l’IPv4.

5) Symptom: Receiver says “HELO name does not resolve”

Cause : Votre nom EHLO n’a pas d’enregistrement A/AAAA, ou le DNS en split-horizon ne le rend visible qu’en interne.

Correctif : Publiez un DNS public pour le nom EHLO. N’utilisez pas un nom de zone interne comme identité SMTP publique.

6) Symptom: Receivers complain about “invalid hostname” even with a FQDN

Cause : Vous avez utilisé des underscores, des caractères interdits, ou un nom qui viole les règles de nommage de base.

Correctif : Utilisez un nom d’hôte DNS simple : lettres, chiffres, traits d’union, points. Pas d’underscores. Restez ennuyeux.

7) Symptom: You “fixed” EHLO but throttling persists

Cause : La réputation IP est maintenant entachée, ou votre PTR/TLS/SPF n’est toujours pas aligné. HELO n’était qu’un des multiples pénalités.

Correctif : Vérifiez rDNS et cohérence TLS, puis évaluez l’alignement SPF/DKIM/DMARC et les patterns d’envoi. Attendez-vous à une période de warm-up si vous avez récemment changé des signaux d’identité.

8) Symptom: Everything works from one node, fails from another

Cause : Les nœuds du pool ont des configs divergentes : nom d’hôte, paramètres MTA, egress NAT, ou comportement du résolveur DNS.

Correctif : Traitez la configuration d’identité MTA comme de l’infrastructure immuable. Auditez tous les nœuds, différez les configs, et appliquez via CI/CD.

Trois mini-récits d’entreprise issus du terrain

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

Une entreprise SaaS de taille moyenne a déplacé l’envoi sortant de quelques machines gérées à la main vers un petit pool autoscalé.
L’équipe avait fait les bonnes choses principales : signature DKIM, mises à jour SPF, politique DMARC en mode monitoring, supervision des files.
Ils ont supposé que la salutation était « juste cosmétique ». Ce n’était pas le cas.

Les nouvelles images venaient d’une baseline durcie. Bon point : sysctls CIS, SSH verrouillé, journalisation saine.
Mais la baseline mettait aussi le nom d’hôte système sur l’ID d’instance. Postfix l’a récupéré. Le pool s’est présenté au monde
comme ip-10-2-3-4 et parfois localhost selon le timing du boot et cloud-init.

Pendant une semaine, personne n’a remarqué. La plupart des destinataires d’entreprise étaient permissifs, et le volume n’était pas énorme.
Puis un gros fournisseur a commencé à différer plus agressivement, et le backoff des réessais a fait son travail : la file s’est constituée.
Des tickets de support sont arrivés avec la pire phrase en opérations : « intermittent ».

L’astreinte a essayé les limites de débit, a ajouté des nœuds, et a vu la file s’agrandir — parce que scaler une mauvaise config est la manière de transformer un bug en mode de vie.
Finalement, quelqu’un a extrait une transcription SMTP brute et a vu l’EHLO. La correction a pris cinq minutes. La tournée d’excuses a pris deux jours.

La leçon n’était pas « lisez la RFC ». Elle était plus simple : ne supposez jamais que les surfaces d’identité sont cosmétiques. Dans l’email, les signaux « cosmétiques »
sont souvent les seuls signaux que les récepteurs ont.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux

Une société financière voulait un débit sortant plus rapide pour des relevés et alertes sensibles au temps. Leur équipe mail a ajusté la concurrence et le pipelining,
et ils ont déployé plusieurs IP d’egress pour répartir la charge. Sur le papier : bonne ingénierie.

Puis ils ont « optimisé » le HELO pour qu’il soit unique par nœud, pensant que cela faciliterait le dépannage. Chaque serveur se présentait comme
mx-out-01.example.com, mx-out-02.example.com, etc. Ils ont oublié un détail méchant : le reverse DNS n’avait été mis à jour que pour la moitié des IPs,
et certains noms EHLO n’existaient même pas encore dans le DNS public.

En quelques jours, la délivrabilité est devenue inégale. Certains destinataires recevaient les messages instantanément, d’autres des heures plus tard. Le nouveau comportement a créé
un faux récit : « c’est le filtrage de contenu ». Ils ont donc modifié les templates et les en-têtes et sont descendus dans un mauvais terrier.

La vraie histoire était qu’ils avaient augmenté la variance d’identité tout en augmentant le volume d’envoi. C’est exactement le moment où les fournisseurs serrent la vis.
Plus d’IPs plus plus de noms EHLO ont multiplié les possibilités de désalignement.

La correction finale était peu glamour : réduire l’ensemble d’HELO à un seul nom stable, aligner le PTR pour chaque IP sortante, et déployer les changements avec un nœud canari.
L’« optimisation » faite pour le débogage a rendu le système plus difficile à diagnostiquer car le côté récepteur a commencé à les traiter comme des expéditeurs incohérents.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une organisation de santé gérait son propre relais sortant parce qu’elle avait besoin d’un contrôle strict pour l’audit et le traitement des messages.
Ils étaient conservateurs : un nom principal unique, propriété DNS documentée, gestion de configuration stricte, changements lents et maîtrisés.
Personne n’a été promu pour ça. C’est généralement un bon signe.

Un trimestre, ils ont dû faire pivoter des IPs sortantes suite à un changement de fournisseur réseau. C’est le moment où les organisations paniquent :
les modifications de PTR prennent du temps, la réputation des anciennes IPs s’évapore, et tous les fournisseurs vous disent « mettez à jour le DNS » sans le reste du contexte.

Ils avaient une checklist qui incluait l’alignement HELO comme point prioritaire : les nouvelles IPs recevaient des PTR pointant vers mail.example.org,
le DNS direct mappait déjà ce nom vers l’IP correcte, et Postfix avait smtp_helo_name verrouillé.
Ils avaient aussi un canari : un relais à faible volume a pris la nouvelle route en premier.

Quand un fournisseur a commencé à différer le trafic du canari, ils l’ont détecté tôt, limité la zone d’impact, et ont ajusté en réduisant temporairement la concurrence
pour cette destination pendant que la réputation chauffait. La piscine principale n’a jamais connu de crise de file.

Leur pratique « ennuyeuse » consistait simplement à traiter l’identité SMTP comme un contrat d’interface, pas une suggestion. Cela n’a pas empêché toute douleur, mais a rendu la douleur contenable.

Blague n°2 : La délivrabilité des emails, c’est comme la plomberie — personne ne veut payer pour ça, et tout le monde le remarque la minute où ça sent mauvais.

Checklists / plan pas à pas (déploiement sécurisé)

Plan pas à pas : corriger HELO/EHLO sans créer un second incident

Choisissez un nom d’identité sortante unique.
- Utilisez un FQDN stable que vous contrôlez, comme mail.example.com ou smtp.example.com.
- Évitez les noms par nœud sauf si vous avez de bonnes raisons et une hygiène DNS irréprochable.
Assurez-vous que le nom se résout publiquement.
- Publiez les enregistrements A (et AAAA si vous envoyez via IPv6) pour le nom choisi.
- Ne comptez pas sur un DNS en split-horizon pour une identité exposée à Internet.
Alignez le reverse DNS pour chaque IP sortante.
- Définissez le PTR sur un nom d’hôte dans la famille de domaines que vous contrôlez.
- Privilégiez un PTR identique à votre EHLO, ou au moins dans le même namespace de domaine.
Définissez explicitement le HELO sortant dans l’MTA.
- Postfix : définissez smtp_helo_name.
- Exim : définissez helo_data (et vérifiez par transport si nécessaire).
Vérifiez la cohérence du pool.
- Diff postconf -n entre les nœuds.
- Confirmez qu’aucun nœud n’utilise un résolveur ou un domaine de recherche qui altère la résolution du nom d’hôte.
Canarisez le changement.
- Dirigez un petit pourcentage du trafic sortant via un nœud ou une IP d’egress avec EHLO corrigé.
- Surveillez les différements et rebonds par domaine de destination.
Déployez progressivement, puis videz les files avec prudence.
- Après la correction, vous pouvez utiliser postqueue -f, mais attention aux limites de débit : vous pourriez surcharger les fournisseurs et déclencher de nouvelles limitations.
- Envisagez un vidage échelonné par destination si les volumes sont importants.
Ajoutez un test de régression.
- En CI ou post-déploiement, exécutez une conversation SMTP contre un récepteur de test qui affirme la chaîne EHLO.
- Faites échouer le build si EHLO contient localhost ou un suffixe interne.

Checklist opérationnelle : à quoi ressemble le « bon »

Le nom EHLO est un FQDN valide, stable entre réessais et nœuds.
Le nom EHLO a des enregistrements A/AAAA publics.
L’IP sortante a un PTR sensé et de préférence aligné avec l’EHLO.
Le PTR résout de nouveau vers l’IP sortante (FCrDNS).
Le nom du certificat TLS est cohérent avec l’identité mail (surtout si vous terminez TLS vous-même).
Les logs conservent les chaînes de réponse distantes pour les rejets/différements (pour voir « Bad HELO » plutôt que « delivery failed »).
La surveillance de file inclut les taux de différement par destination (car « taille de file » seule ment).

FAQ

1) HELO/EHLO est‑il la même chose que le domaine dans l’en‑tête « From : » ?

Non. HELO/EHLO est le salut du client SMTP. « From : » est un en‑tête de message vu par les utilisateurs.
Les récepteurs corrèlent plusieurs identités, mais ce sont des couches différentes et elles peuvent légitimement différer (relays, envois tiers, etc.).

2) Si j’ai SPF/DKIM/DMARC, puis‑je ignorer HELO/EHLO ?

Non. L’authentification aide, mais les fournisseurs notent la cohérence. Un EHLO cassé reste un signe d’infrastructure négligée ou de compromission.
Vous essayez d’avoir l’apparence d’un vrai système de mail, pas de gagner un débat sur une RFC.

3) Que devrais‑je mettre comme nom EHLO dans Postfix ?

Généralement un FQDN stable unique comme mail.example.com. Dans Postfix, définissez smtp_helo_name sur cette valeur.
Assurez‑vous qu’il se résout publiquement et qu’il est aligné avec le PTR de votre IP sortante.

4) EHLO doit‑il correspondre exactement au reverse DNS ?

Le « doit » dépend de votre environnement, mais la correspondance exacte est le choix le moins controversé.
Si vous ne pouvez pas la rendre exacte (plusieurs IPs, contraintes fournisseur), gardez‑la dans la même famille de domaine et maintenez la cohérence DNS.

5) Puis‑je utiliser une adresse IP dans HELO/EHLO ?

Évitez‑le. Certains systèmes acceptent des littéraux d’adresse entre crochets, mais beaucoup de récepteurs le considèrent comme suspect.
Utilisez un FQDN valide avec un DNS approprié à la place.

6) Mes noms d’hôte sont internes par politique. Puis‑je les garder internes ?

Vous pouvez garder le nom d’hôte OS interne et présenter un EHLO public pour le SMTP sortant en le configurant explicitement dans l’MTA.
C’est souvent le compromis le plus propre entre la politique de nommage interne et la réalité de la délivrabilité externe.

7) Pourquoi cela a‑t‑il cassé « soudainement » alors que c’était faux depuis des mois ?

Parce que les récepteurs changent leur scoring, vos patterns de trafic évoluent, et la réputation IP change. Une pénalité mineure devient décisive quand d’autres signaux se détériorent.
Aussi : des changements d’infrastructure (nouvelles images, nouveau NAT, activation d’IPv6) peuvent modifier silencieusement le nom de salutation.

8) Qu’en est‑il du SMTP entrant — mon `smtpd_banner` compte‑t‑il ?

Oui, surtout si votre serveur est exposé à Internet. Une bannière annonçant localhost ou des noms internes paraît amateur et peut influer sur la manière dont d’autres MTA vous traitent.
Ce n’est pas la même chose que l’EHLO sortant, mais c’est une partie de l’identité publique de votre serveur mail.

9) HELO/EHLO affecte‑t‑il TLS ?

Indirectement. Certains récepteurs corrèlent le nom EHLO avec les noms de certificat TLS et le comportement SNI.
Les incohérences s’additionnent. Vous voulez une histoire cohérente : nom, DNS, IP et certificat ne doivent pas se contredire.

10) Si j’utilise un relais tiers (smarthost), dois‑je m’en préoccuper ?

Oui, mais différemment. Si vous confiez le mail à un relais, c’est leur EHLO et leur réputation IP qui contrôlent la livraison finale.
Votre risque se déplace vers la session SMTP entre vous et le relais : assurez‑vous de présenter une identité saine et de ne pas déclencher leurs limites de politique.

Conclusion : prochaines étapes à livrer cette semaine

HELO/EHLO n’est pas glamour. C’est une seule ligne de texte. Et elle peut absolument ruiner votre semaine.
Les fournisseurs la lisent comme un signal de compétence. Quand vous envoyez « EHLO localhost », vous leur dites que votre infrastructure est mal gérée ou compromise.
Ils répondent en conséquence : limitation, différement, rejet.

Prochaines étapes pratiques :

Choisissez un FQDN sortant stable pour l’EHLO et assurez‑vous qu’il se résout publiquement.
Alignez le PTR pour chaque IP sortante et confirmez le reverse DNS direct confirmé quand c’est possible.
Définissez explicitement l’EHLO dans votre MTA (ne comptez pas sur les valeurs par défaut du système d’exploitation).
Canarisez et observez les différements/rebonds par destination avant le déploiement complet.
Ajoutez un test de régression pour éviter que la prochaine reconstruction ne réintroduise « localhost » dans l’email de production.

Faites le travail d’identité ennuyeux maintenant. Votre canal d’incidents futur sera plus calme, et vos utilisateurs arrêteront de considérer l’email comme une roulette.