Guides · E-mail et domaines

Qu'est-ce que le DNS inverse (PTR), et pourquoi la messagerie y tient-elle ?

Écrit par Aldo · threat hunter en blue team
Dernière mise à jour le 9 novembre 2026 · 5 min de lecture

Demandez au DNS dns.google, et vous obtenez 8.8.8.8. Posez la question dans l'autre sens, « comment s'appelle 8.8.8.8 ? », et vous utilisez le DNS inverse. C'est une petite fonction qui décide de beaucoup de choses : si votre serveur de messagerie inspire confiance, et si un robot d'exploration est authentique.

Comment ça marche

Les noms inverses vivent dans une partie spéciale du DNS. L'adresse s'écrit à l'envers sous in-addr.arpa (IPv4) ou ip6.arpa (IPv6), et l'enregistrement qu'on y trouve est un PTR, un pointeur vers un nom :

8.8.8.8.in-addr.arpa.   PTR   dns.google.

Comme la zone inverse suit les blocs d'adresses, elle appartient à celui qui détient le bloc : le registre la délègue au fournisseur, et le fournisseur définit les noms ou laisse ses clients le faire. C'est pourquoi vous ne pouvez pas ajouter d'enregistrement PTR dans le panneau DNS de votre domaine. Il se règle auprès de celui qui vous a donné l'adresse.

Le consulter

dig -x 8.8.8.8 +short
host 8.8.8.8
nslookup 8.8.8.8                 # Windows, macOS, Linux
Resolve-DnsName 8.8.8.8          # Windows PowerShell

Vérifiez ensuite l'autre sens : recherchez le nom obtenu et regardez s'il renvoie la même adresse. Si oui, le nom est confirmé dans le sens direct. Quiconque contrôle un bloc peut faire dire n'importe quoi à son PTR (« mail.votrebanque.fr »), mais seul le vrai propriétaire de ce nom peut le faire pointer en retour. Un nom inverse sans correspondance directe ne prouve rien.

Un exemple concret : six adresses, trois résultats

Nous avons recherché six adresses connues avec la recherche IP d'iplover le 9 novembre 2026. Elle fait les deux requêtes et indique si elles concordent :

Le schéma est classique. Les services qui veulent être reconnus définissent un nom parlant et confirmé dans le sens direct. Les grands réseaux donnent à leurs adresses des noms génériques, contenant souvent l'adresse elle-même, ou pas de nom du tout. Un PTR absent n'a rien de suspect pour un visiteur web. Pour un serveur de messagerie, c'est un problème.

Pourquoi la messagerie y tient

Les serveurs de messagerie destinataires regardent l'adresse qui s'est connectée à eux. Si elle n'a pas de nom PTR, si le nom ne renvoie pas à l'adresse, ou si le nom ressemble à celui d'une connexion domestique (avec des mots comme dynamic, dsl ou pool, ou l'adresse écrite en toutes lettres), beaucoup de serveurs refusent l'e-mail ou le classent comme spam probable. Les consignes de Google pour les expéditeurs, par exemple, demandent que les adresses d'envoi aient un enregistrement PTR dont le nom renvoie à la même adresse.

Donc si vous gérez votre propre serveur de messagerie, ou si un service envoie des e-mails directement depuis votre serveur ou votre VPS :

En IPv6, les mêmes règles s'appliquent, avec des noms plus longs. Si votre serveur envoie en IPv6, il lui faut aussi un PTR pour son adresse IPv6 ; une configuration IPv4 correcte ne le couvre pas.

Ce que le DNS inverse ne peut pas vous dire

Un nom inverse est une étiquette choisie par celui qui contrôle l'adresse, rien de plus. Sans la vérification directe, il peut prétendre n'importe quoi. Même confirmé, il vous dit sur quel réseau se trouve l'adresse, pas qui l'utilise : un nom de cloud signifie un serveur cloud, loué par quelqu'un que vous ne voyez pas. C'est une preuve pour une question (est-ce vraiment le robot de Google, est-ce un vrai serveur de messagerie) et presque inutile pour celle à laquelle on espère souvent qu'il réponde : qui se cache derrière une adresse.