Un reverse DNS lookup prend une adresse IP et renvoie le nom d’hôte qui y est enregistré. La résolution directe transforme unspam.email en adresse IP ; le reverse DNS fait l’inverse, à partir d’un enregistrement PTR publié par le propriétaire du bloc d’adresses IP.
C’est pour l’e-mail que cela compte le plus. Les serveurs de réception regardent si votre adresse IP d’envoi possède un enregistrement reverse DNS avant de décider quoi faire de votre message, et son absence est lue comme un signal fort d’expéditeur mal configuré ou jetable. Sur les adresses IP d’envoi que nous testons, 99 % disposent d’un reverse DNS valide, et le 1 % qui en est dépourvu saute immédiatement aux yeux.
Ce guide explique ce qu’est le reverse DNS, comment lancer une résolution en ligne de commande ou depuis un navigateur, et comment créer l’enregistrement PTR lui-même.
Qu’est-ce que le reverse DNS ?
Le reverse DNS est la résolution qui détermine le nom d’hôte associé à une adresse IP donnée. La résolution directe fait l’inverse : elle récupère une adresse IP à partir d’un nom d’hôte.
Le DNS lui-même, c’est le Domain Name System, l’annuaire téléphonique d’internet, et il fonctionne dans les deux sens parce que les humains comme les machines doivent le lire. Les résolutions directes sont celles que vous utilisez tous les jours sans y prêter attention. Les résolutions inverses sont celles dont les serveurs de messagerie se servent pour décider s’ils vous font confiance.
Toutes les adresses IP n’ont pas d’entrée inverse, car le DNS fonctionne très bien sans. Pendant des années, le reverse DNS est donc resté une recommandation plutôt qu’une obligation. Pour l’e-mail, ce n’est plus vrai : depuis novembre 2026, Spamhaus déploie progressivement l’exigence que chaque adresse IP d’envoi dispose d’un nom HELO valide, d’un enregistrement PTR et d’un enregistrement A correspondant.
Appuyez sur lecture pour charger cette vidéo depuis YouTube (Google). Consultez notre politique de cookies.
Comment fonctionne le reverse DNS ?
Un résolveur inverse l’adresse IP, y accole le suffixe de la zone inverse et demande au DNS l’enregistrement PTR situé à ce nom. Les étapes sont les suivantes :
- Le résolveur écrit l’adresse IPv4 à l’envers et y accole
.in-addr.arpa:203.0.113.25devient ainsi25.113.0.203.in-addr.arpa. Une adresse IPv6 est écrite en entier, inversée chiffre hexadécimal par chiffre hexadécimal et reçoit.ip6.arpaà la place. - Il demande au DNS l’enregistrement PTR situé à ce nom. La réponse vient des serveurs de noms de celui qui contrôle la zone inverse, c’est-à-dire en général le propriétaire du bloc d’adresses IP, et non le propriétaire du domaine.
- Si un enregistrement PTR existe, sa valeur est le nom d’hôte. S’il n’existe pas, la réponse est vide et l’adresse n’a pas de nom inverse.
Une résolution qui ne renvoie rien n’est pas une erreur. Elle signifie qu’aucun enregistrement PTR n’est publié pour cette adresse, ce qui est courant sur les accès internet grand public et sur les hébergements mutualisés, et c’est exactement l’état que les serveurs de réception jugent suspect.
Voyons quelques bonnes raisons pour lesquelles le reverse DNS compte.
Le principe de base du reverse DNS lookup
Pourquoi le reverse DNS compte pour les e-mails que vous envoyez
Le reverse DNS est l’un des signaux de confiance les moins coûteux qu’un expéditeur puisse publier, et l’un des rares à être contrôlé avant même que votre contenu soit examiné. Trois choses en dépendent.
L’acceptation de vos e-mails
Comme SPF, DKIM et DMARC, le reverse DNS sert à séparer les expéditeurs légitimes des infrastructures jetables. Les serveurs de messagerie interrogent l’adresse IP d’envoi, et beaucoup rejettent ou pénalisent lourdement une connexion quand aucun enregistrement PTR ne revient, en partant du principe qu’un expéditeur sérieux contrôle son propre bloc d’adresses IP, ce qui n’est en général pas le cas d’un spammeur. Les serveurs de réception les plus stricts exigent en plus un reverse DNS confirmé dans les deux sens, le forward-confirmed reverse DNS, où le nom d’hôte de l’enregistrement PTR résout vers la même adresse IP.
Le reverse DNS n’est toutefois qu’un signal parmi d’autres : la situation de l’adresse IP sur les blacklists pèse tout autant, et sur les adresses IP d’envoi que nous testons, 6 % apparaissent sur une blacklist d’adresses IP. Pour voir exactement depuis quelle adresse IP un message est parti et comment le serveur destinataire l’a jugé, passez un message suspect dans notre Email Header Analyzer.
Le filtrage antispam et le traçage des abus
Le reverse DNS est au cœur de plusieurs techniques antispam éprouvées de longue date. Un serveur de réception qui résout une adresse IP entrante en mail.yourcompany.com la traite très différemment d’une adresse qui ne résout vers rien, ou vers un nom d’hôte générique de fournisseur d’accès du type host-92-14-233-8.dynamic.example.net. C’est la même résolution qui permet aux services abuse et aux équipes de sécurité d’identifier l’opérateur derrière une adresse IP qui envoie des e-mails malveillants, sonde un pare-feu ou tente de s’introduire dans un système.
Des journaux lisibles et un diagnostic plus rapide
Les journaux serveur, les traceroutes et les outils de supervision résolvent les adresses IP en noms d’hôte pour qu’un humain puisse les lire. Sans reverse DNS, votre trafic apparaît dans les journaux de tout le monde sous la forme d’une simple suite de chiffres, ce qui ralentit vos propres diagnostics et vous fait passer pour un anonyme aux yeux de quiconque enquête sur un incident.
Ce que le reverse DNS ne fait pas. Il ne vous dit pas qui a visité votre site web, quelles pages ont été lues, combien de temps les visiteurs sont restés ni quel appareil ils utilisaient. Ces informations viennent de l’analyse d’audience, et l’attribution au niveau de l’entreprise que certains éditeurs vendent par-dessus provient de bases de données commerciales reliant les adresses IP aux organisations, pas d’un enregistrement PTR. Une résolution inverse renvoie un nom d’hôte, et rien d’autre.
Le reverse DNS est facultatif pour le protocole et obligatoire en pratique
Le reverse DNS n’est pas nécessaire au fonctionnement du DNS, et c’est précisément pour cette raison que tant d’expéditeurs s’en passent, alors que s’en passer coûte cher. L’IETF attend de chaque adresse qu’elle soit résolvable, mais un enregistrement PTR manquant ne casse rien techniquement : rien ne vous force la main tant que vos e-mails ne commencent pas à être rejetés.
En réalité, les serveurs de réception et les fournisseurs de messagerie contrôlent la configuration du reverse DNS au moment de décider quoi faire des e-mails venant de votre serveur. Ils vérifient si l’adresse IP du serveur d’envoi possède un enregistrement reverse DNS. La plupart des serveurs considèrent l’absence d’enregistrement comme une fraude et rejettent sans discussion les e-mails de cette source. C’est désormais une norme établie : sur les adresses IP d’envoi que nous testons, 99 % disposent d’un reverse DNS valide, et le 1 % qui en est dépourvu saute immédiatement aux yeux des serveurs destinataires.
Si vous menez des campagnes emailing et sollicitez sans cesse vos abonnés par ce canal, l’absence de reverse DNS devient un vrai point de blocage : vos e-mails seront rejetés sans raison valable. Il est donc fortement recommandé de configurer le reverse DNS de votre domaine pour garantir une bonne délivrabilité.
Avec un reverse DNS en place, vous contribuez enfin à la communauté et vous vous attaquez à des problèmes de sécurité courants. Cette configuration de base aide d’autres acteurs à repérer des menaces potentielles et à combattre la cybercriminalité plus efficacement, ce qui crée un écosystème sûr et transparent pour vous et vos clients.
Spamhaus exige le FCrDNS et un HELO cohérent à partir de novembre 2026
Spamhaus publie désormais des Sender Guidelines qui font passer le reverse DNS du statut d’usage à celui d’exigence explicite. La page indique qu’à partir de novembre 2026, Spamhaus déploie progressivement l’exigence que chaque adresse IP d’envoi dispose d’un HELO valide, d’un enregistrement reverse DNS (PTR) et d’un enregistrement A correspondant. Ces contrôles figurent parmi les exigences minimales que tout expéditeur doit respecter « pour éviter d’être listé ».
Ce que les exigences minimales demandent à chaque adresse IP d’envoi, au 7 novembre 2026 :
| Exigence | Ce que demande Spamhaus |
|---|---|
| Enregistrement PTR | Une entrée reverse DNS pour chaque adresse IP d’envoi, qui pointe vers un nom de domaine complet (FQDN) |
| Confirmation directe | Ce nom d’hôte résout vers la même adresse IP : c’est le forward-confirmed reverse DNS (FCrDNS) |
| Nom HELO/EHLO | Un nom d’hôte qui résout vers l’adresse IP d’envoi et reste le même d’une connexion à l’autre |
| Pas de noms de remplissage | Les noms de remplissage comme localhost, les noms par défaut de l’hébergeur et les noms qui changent d’une connexion à l’autre sont lus comme des signes de mauvaise configuration ou de compromission |
| IPv6 | Envoyer depuis une allocation de /64 ou plus, avec un reverse DNS valide |
Spamhaus recommande aussi un reverse DNS à l’image de votre propre domaine plutôt qu’un nom générique d’hébergeur, et ses recommandations pour les ESP et les gros expéditeurs résument la règle en une ligne : le HELO, le PTR et l’enregistrement A doivent tous utiliser le même nom d’hôte.
La page nomme aussi la conséquence. Un nom HELO de remplissage, par défaut ou changeant peut entraîner un listage, et ne pas respecter ces bases d’infrastructure peut faire inscrire une adresse IP dans les zones CSS ou XBL de Spamhaus. Notre guide pour sortir de Spamhaus explique ce que chacune de ces listes implique pour le retrait, et notre analyse des Sender Guidelines de Spamhaus couvre le reste de la page, du taux de rebond à l’authentification.
En pratique, un seul nom d’hôte remplit les trois rôles. Si votre serveur envoie depuis 187.133.11.219 sous le nom mail.example.com, le PTR de 187.133.11.219 renvoie mail.example.com, l’enregistrement A de mail.example.com renvoie 187.133.11.219, et le serveur salue chaque destinataire avec EHLO mail.example.com. Les étapes de configuration ci-dessous produisent exactement cet état.
Comment faire un reverse DNS lookup ?
Il existe deux façons de lancer un reverse DNS lookup : une seule commande sur votre propre machine, ou un outil en ligne si vous préférez ne pas toucher à un terminal.
La première passe par la ligne de commande. La plupart des systèmes d’exploitation (Linux, macOS et bien sûr Windows) savent interroger le Domain Name System pour obtenir un nom d’hôte à partir d’une adresse IP : votre ordinateur de bureau ou portable peut donc vous aider directement.
Les utilisateurs de Windows peuvent par exemple recourir aux commandes « ping » ou « nslookup ». La requête ressemble à ceci :
ping -a w.x.y.z
ou
nslookup 7.7.7.7
Si un enregistrement PTR est publié, ces commandes renvoient son nom d’hôte.
Sous macOS et Linux, vous pouvez utiliser la commande « dig » suivie de l’option « -x » et de l’adresse IP, comme ceci
dig -x 7.7.7.7
Si la ligne de commande vous effraie, une résolution depuis un navigateur donne exactement la même réponse.
Trois outils qui font un reverse DNS lookup dans le navigateur
Unspam, MxToolBox et WhatIsMyIP résolvent tous les trois une adresse IP en nom d’hôte sans terminal, et tous les trois sont gratuits pour ce contrôle.
- IP Blacklist Checker d’Unspam. Saisissez une adresse IP d’envoi : au-dessus des résultats des blacklists, il affiche le nom d’hôte du PTR et indique si ce nom résout vers la même adresse, ce qui vous montre la confirmation directe et pas seulement un nom. Complétez-le par un MX Lookup pour voir quels serveurs reçoivent les e-mails de votre domaine, qui ne sont souvent pas ceux qui les envoient.
- MxToolBox. MxToolBox est un autre service de diagnostic multitâche. La plupart de ses outils sont payants, mais le reverse DNS lookup est gratuit. Saisissez simplement l’adresse IP au format IPv4 ou IPv6 et profitez du résultat.
- WhatIsMyIP. Effectue la résolution directe et la résolution inverse depuis le même champ. Saisissez l’adresse IP et il renvoie le nom d’hôte du PTR.
Comment configurer le reverse DNS en sept étapes
Configurer le reverse DNS revient à faire publier un enregistrement PTR pour votre adresse IP d’envoi, à donner au nom d’hôte qu’il désigne un enregistrement A qui pointe vers la même adresse IP, et à utiliser ce nom d’hôte comme nom HELO. Sur la plupart des serveurs cloud et des offres VPS, le prestataire publie le PTR pour vous, depuis son panneau de configuration ou via un ticket au support : les étapes 2 à 4 ne s’appliquent donc que si l’on vous délègue un bloc d’adresses à gérer vous-même. Tout cela suppose une adresse IP dédiée : sur un hébergement mutualisé, l’enregistrement PTR appartient à votre prestataire et vous ne pouvez pas le modifier.
Étape 1 : rassembler les informations nécessaires
La première chose à faire pour configurer le reverse DNS est de déterminer qui est votre hébergeur et si vous avez accès au DNS.
Dans la majorité des cas, votre hébergeur ou votre fournisseur d’accès possède votre bloc d’adresses IP. Si ce n’est pas le cas, vous pouvez identifier le propriétaire avec des services tiers gratuits comme IP WHOIS Lookup.
Étape 2 : définir le nom de la zone reverse DNS
Une fois le propriétaire du bloc d’adresses IP identifié, contactez-le et demandez une zone pour l’adresse IP de votre serveur de messagerie.
Vous remarquerez que cette zone se termine par « in-addr.arpa » et contient un bloc d’adresses IP dont les octets sont inversés. C’est la syntaxe officielle à utiliser pour créer votre propre zone reverse DNS.
Le format est simple : il commence par une adresse IP aux octets inversés et se termine par « .in-addr.arpa ».
Suivez cette procédure simple en 5 étapes pour définir le nom de votre zone reverse DNS :
- Prenez la première adresse de votre bloc, et non l’adresse de votre serveur de messagerie.
- S’il s’agit d’un bloc /24 complet, omettez le dernier octet. S’il s’agit d’un bloc sans classe, gardez les quatre octets et mettez le masque de côté.
- Inversez l’ordre des octets restants.
- Ajoutez « in-addr.arpa » à la fin.
- S’il s’agit d’un bloc sans classe, rajoutez le masque au premier label. La RFC 2317 l’écrit avec une barre oblique et propose le tiret comme caractère plus sûr : utilisez la forme que demande le propriétaire de votre bloc.
Prenons un exemple pour bien comprendre la procédure.
Votre serveur de messagerie est par exemple 187.133.11.219 et se trouve dans le bloc 187.133.11.192/27, soit les 32 adresses de .192 à .223. C’est un bloc sans classe : partez donc de sa première adresse et mettez le masque de côté, à savoir « /27 ».
Vous obtenez donc 187.133.11.192
Inversez ensuite l’ordre des octets : 192.11.133.187
Ajoutez alors « .in-addr.arpa » : 192.11.133.187.in-addr.arpa
Réinsérez enfin le masque avec le tiret : 192-27.11.133.187.in-addr.arpa
L’enregistrement PTR de votre serveur se trouve alors à 219.192-27.11.133.187.in-addr.arpa, et le propriétaire du bloc fait pointer le nom standard 219.11.133.187.in-addr.arpa vers lui avec un enregistrement CNAME, selon le schéma que décrit la RFC 2317.
Étape 3 : demander la délégation du reverse DNS
Demandez à votre fournisseur d’accès de déléguer le reverse DNS à votre fournisseur DNS. Pour cela, vous devez lui communiquer les serveurs de noms de votre domaine.
Vous pouvez trouver le serveur de noms de votre domaine grâce à un outil gratuit, le Dig Web Interface Tool.
Si l’hébergeur ou le fournisseur d’accès ne peut pas déléguer le reverse DNS, il fera probablement tout lui-même. Vous pouvez alors laisser la configuration à l’équipe support et sauter les étapes suivantes.
Étape 4 : créer la zone reverse DNS
Connectez-vous chez votre hébergeur et trouvez le menu DNS dans le panneau de configuration.
Cliquez dessus et choisissez « Gérer le DNS ». Le libellé peut varier légèrement.
Cliquez sur « Ajouter des domaines ».
Saisissez le nom de la zone reverse DNS que nous avons défini à l’étape 2.
Étape 5 : créer l’enregistrement PTR
Une fois la zone créée, créez-y un enregistrement PTR pour chaque adresse IP d’envoi. Ouvrez l’onglet correspondant. Selon votre prestataire, il peut s’appeler « PTR record » ou quelque chose d’approchant.
Saisissez le dernier octet de l’adresse IP dans le champ « name », par exemple 219 pour 187.133.11.219.
Saisissez comme valeur un nom d’hôte complet, comme mail.example.com : ni le domaine seul, ni le nom générique de votre prestataire. Choisissez un nom d’hôte dans un domaine que vous contrôlez, car l’étape suivante a besoin d’un enregistrement A pour lui.
Étape 6 : faire pointer le nom d’hôte vers l’adresse IP et l’utiliser comme HELO
Un enregistrement PTR ne fait que la moitié du contrôle. Dans la zone DNS habituelle de votre domaine, publiez un enregistrement A (et un enregistrement AAAA pour un expéditeur IPv6) afin que mail.example.com résolve vers la même adresse IP d’envoi. C’est ce qui rend votre reverse DNS forward-confirmed. Réglez ensuite le nom d’hôte HELO ou EHLO de votre serveur de messagerie sur exactement ce nom. Si vous envoyez depuis plusieurs adresses IP, donnez à chacune son propre nom d’hôte, et ne laissez jamais le nom changer d’une connexion à l’autre.
Étape 7 : vérifiez l’enregistrement au lieu d’attendre
La propagation est régie par le TTL de la zone : un nouvel enregistrement PTR est donc généralement visible en quelques minutes à quelques heures, et non au bout des deux jours qu’annonçaient les vieux conseils. Laissez passer jusqu’à 24 h avant de conclure à un problème, et relancez la résolution pour confirmer au lieu d’attendre à l’aveugle.
Vérifiez les deux sens, pas seulement le PTR :
dig -x 187.133.11.219 +short
dig A mail.example.com +short
La première commande doit renvoyer mail.example.com. et la seconde 187.133.11.219. Envoyez-vous ensuite un message de test et lisez l’en-tête Received ajouté par votre boîte de réception : le nom qui suit immédiatement from est le HELO annoncé par votre serveur, et ce doit être le même nom d’hôte.
Enregistrement DNS pour Unspam.email
Un seul nom d’hôte à trois endroits, et le travail est fait
Le reverse DNS coûte un enregistrement PTR, un enregistrement A et une ligne de configuration du serveur de messagerie, et il vous vaut le bénéfice du doute auprès de tous les serveurs de réception, et c’est pourquoi 99 % des adresses IP d’envoi que nous testons en disposent déjà.
Identifiez le propriétaire de votre bloc d’adresses IP, demandez-lui de déléguer la zone inverse, publiez un enregistrement PTR qui pointe vers un nom d’hôte que vous contrôlez, donnez à ce nom d’hôte un enregistrement A qui résout vers la même adresse IP, et faites-en le nom que votre serveur utilise dans le HELO. C’est exactement l’état que vérifie le déploiement de Spamhaus de novembre 2026. Lancez ensuite un test de spam gratuit pour voir comment le côté réception lit désormais vos e-mails, et regardez les en-têtes d’un vrai message pour confirmer que le PTR est bien renvoyé.
