Spamhaus n’a publié aucune date d’application précise pour son contrôle DNS : la page Sender Guidelines annonce un déploiement progressif à partir de novembre 2026 (page consultée le 27 octobre 2026). Chaque IP émettrice doit présenter un HELO valide et un couple PTR/A qui concorde, faute de quoi elle s’expose à une inscription dans les zones CSS ou XBL.
Le symptôme est connu des équipes CRM : « mon outil d’emailing dit que tout est OK » et pourtant les campagnes finissent en spam. Un défaut DNS sur l’IP d’envoi suffit à déclencher une inscription en liste ; l’interface de l’outil ne vous en parle pas forcément.
Ce que Spamhaus annonce et ce qu’il laisse dans l’ombre
D’après les lignes directrices expéditeur de Spamhaus, Spamhaus déploie progressivement l’exigence d’un HELO valide et d’un PTR accompagné de son enregistrement A pour chaque IP d’envoi.
Les pages consultées ne donnent ni calendrier par phase ni détail de la sanction. La seule conséquence nommée est une inscription sur la CSS (Combined Spam Sources) ou sur la XBL, la liste des IP compromises. Aucun nouveau standard n’apparaît dans ces pages. Pour situer l’organisme et ses zones, voir notre présentation de Spamhaus.
Une limite à garder en tête : les pages de l’outil de contrôle précisent que les résultats ne sont pas disponibles pour toutes les IP et peuvent ne pas refléter des changements récents. Un test au vert se refait donc après chaque modification DNS.
Google et Yahoo imposent depuis février 2024 des règles d’authentification aux expéditeurs de plus de 5 000 messages par jour ; Microsoft a annoncé le 2 avril 2025 une logique comparable pour Outlook.com, appliquée depuis le 5 mai 2025. Spamhaus ajoute un contrôle côté liste d’IP.
HELO : le nom que votre serveur donne en se présentant
Un serveur d’envoi fraîchement loué se présente avec le nom de machine fourni par l’hébergeur, quelque chose comme vps-4821.hosting.example (jamais le nom du domaine de l’expéditeur), tant que personne ne touche à la commande EHLO. Sous Postfix 3.x, le paramètre smtp_helo_name du fichier main.cf fixe ce nom et reprend par défaut la valeur de myhostname. C’est ce que Spamhaus écarte.
La section 4.1.1.1 de la RFC 5321 (2008) demande que l’argument de EHLO soit le nom de domaine complet du client SMTP quand il existe. Spamhaus durcit la lecture : ce nom doit se résoudre vers l’IP qui se connecte. Il proscrit localhost et les noms génériques de l’hébergeur ou du fournisseur d’accès. Un nom qui pointe vers une infrastructure sans rôle dans l’envoi est refusé ; l’imitation du HELO d’un fournisseur de boîtes comme Gmail ou Hotmail l’est aussi.
La constance compte autant que le nom. Plusieurs valeurs de HELO se résolvant vers des IP différentes renvoient, selon les lignes directrices, à l’activité d’un proxy résidentiel ou d’un malware. Un parc de relais configurés à la main, chacun avec son propre nom, peut se ranger dans cette catégorie sans que personne l’ait voulu.
Spamhaus recommande aussi d’aligner le HELO sur le nom du reverse DNS et de publier sur ce domaine une page web qui explique l’usage du serveur.
PTR et enregistrement A : fermer la boucle
Le contrôle suit un aller-retour. L’IP d’envoi possède un PTR qui pointe vers un nom complet ; ce nom possède un enregistrement A (AAAA en IPv6) qui renvoie vers la même IP ; le HELO annoncé reprend ce nom. On parle de forward-confirmed reverse DNS (FCrDNS).
L’outil check.spamhaus.org (module IP & Domain Reputation Checker) rend trois verdicts, « HELO Resolution », « PTR Record » et « PTR Resolution ». Une croix rouge signifie, d’après la page de dépannage, qu’une demande de retrait a peu de chances d’aboutir. Le rejet Gmail 550 5.7.25 lié au PTR est traité dans notre article sur l’erreur SMTP 550 5.7.25.
Tester la boucle avant novembre
Deux requêtes dig (paquet bind9-dnsutils sous Debian 12) reproduisent le contrôle. Pour une IP d’envoi 203.0.113.25 (adresse de documentation), la commande dig -x 203.0.113.25 +short retourne le PTR, par exemple mail.exemple.fr. La commande dig +short A mail.exemple.fr doit alors retourner 203.0.113.25 ; la session SMTP doit annoncer mail.exemple.fr dans le EHLO.
Pour contrôler le HELO réellement utilisé en production, Spamhaus mentionne l’adresse helocheck@abuseat.org, héritée de la CBL (Composite Blocking List) dont les données alimentent la XBL.
À qui appartiennent ces enregistrements chez vous ?
Tout dépend du montage d’envoi. Sur un IP pool mutualisé chez un prestataire (Twilio SendGrid, Mailjet ou Brevo par exemple), HELO, PTR et A relèvent du prestataire. Vous ne pouvez rien y modifier ; votre levier se limite à demander la conformité par écrit et à surveiller la sender reputation et le complaint rate de vos envois.
Sur une IP dédiée ou un serveur à vous, tout vous revient. Le PTR se règle chez le détenteur du bloc d’adresses, en général l’hébergeur (OVHcloud, Hetzner ou Scaleway par exemple), via son espace client ou un ticket. L’enregistrement A et le HELO se règlent chez vous : zone DNS d’un côté, configuration du serveur SMTP de l’autre.
Spamhaus déconseille de laisser sur une IP dédiée le reverse DNS généré automatiquement au nom de l’hébergeur. Il recommande un nom sur le domaine de l’expéditeur. En IPv6, la page exige aussi une allocation d’au moins un /64 avec reverse DNS valide, comme le résume la section des exigences minimales. Le choix entre IP dédiée et mutualisée est détaillé dans l’article IP dédiée ou partagée. Le mécanisme du PTR a sa page : le reverse DNS lookup.
Un DNS conforme protège-t-il d’une inscription en liste ?
Non. Les exigences minimales de Spamhaus forment une liste de cinq points qui s’ouvre sur l’opt-in confirmé et cite les listes achetées ou louées comme source fréquente de spam traps. Le reverse DNS arrive en deuxième position, le HELO en troisième, l’IPv6 en quatrième et SPF, DKIM et DMARC en cinquième.
Un DNS propre ne vous protège pas d’une base périmée : quand le hard bounce remonte, il est déjà compté contre l’IP d’envoi. Une IP au DNS irréprochable qui écrit à des adresses mortes accumule ces rebonds comme n’importe quelle autre. Côté Gmail, la page d’aide de Google demande de rester sous 0,10 % de plaintes dans Postmaster Tools et d’éviter d’atteindre 0,30 %. Les autres listes à surveiller en dehors de Spamhaus sont passées en revue dans blocklists email : lesquelles surveiller vraiment en 2026.
Avant la prochaine campagne, passez un échantillon de la liste dans un vérificateur d’adresses pour relever son taux de hard bounce, puis ouvrez check.spamhaus.org avec l’IP d’envoi.
