DNS inverse et enregistrement PTR pour serveurs mail
Comment un PTR associe une IP à un nom, qui peut le modifier, pourquoi les serveurs mail exigent un DNS inverse confirmé et ce que signifie une incohérence.
Rechercher un enregistrement PTR
De l’adresse au nom
Les enregistrements DNS directs, comme A et AAAA, se trouvent dans la zone d’un domaine : le gestionnaire d’example.com décide que www.example.com pointe vers une adresse. Le DNS inverse a besoin d’une autre arborescence, car les adresses ne sont pas organisées par nom de domaine. Pour IPv4, cette arborescence est in-addr.arpa ; pour IPv6, c’est ip6.arpa.
Pour construire le nom inverse, on écrit l’adresse à l’envers. 8.8.8.8 devient 8.8.8.8.in-addr.arpa, et 203.0.113.10 devient 10.113.0.203.in-addr.arpa : la partie la plus générale de l’adresse arrive ainsi en dernier, comme dans un nom de domaine. Pour IPv6, chaque chiffre hexadécimal de l’adresse complète à 32 chiffres est inversé et séparé par des points, d’où la longueur des noms inverses IPv6.
Qui contrôle un enregistrement PTR ?
La zone inverse d’un bloc d’adresses est déléguée par le registre Internet régional à l’organisation qui détient ce bloc, puis par celle-ci à qui elle le souhaite. Pour une connexion à domicile ou mobile, il s’agit de votre fournisseur d’accès. Pour un serveur cloud, c’est le fournisseur cloud, qui vous permet généralement de définir le nom dans son panneau de contrôle ou sur demande.
C’est pourquoi ajouter un enregistrement PTR chez votre registrar ou votre hébergeur DNS ne sert à rien : ils ne contrôlent pas la zone inverse de l’adresse de votre serveur. Adressez-vous au fournisseur qui vous a attribué l’adresse et indiquez-lui le nom d’hôte exact souhaité.
DNS inverse confirmé par résolution directe (FCrDNS)
Quiconque contrôle une zone inverse peut y publier n’importe quel nom, y compris un nom appartenant au domaine de quelqu’un d’autre. Un nom PTR se vérifie donc dans l’autre sens : recherchez les enregistrements A ou AAAA de ce nom et vérifiez que l’un d’eux correspond à l’adresse d’origine. Lorsque les deux sens concordent, on parle de DNS inverse confirmé par résolution directe, ou FCrDNS (forward-confirmed reverse DNS).
La recherche DNS inverse d’IPNixa effectue ces deux étapes. Elle demande l’enregistrement PTR à Cloudflare et à Google, puis recherche le nom renvoyé et indique l’un des quatre états suivants.
| Résultat | Signification | Étape suivante habituelle |
|---|---|---|
| Résolution directe concordante | Un nom PTR existe et renvoie vers la même adresse | Rien ; c’est ce qu’attendent les serveurs de messagerie |
| Résolution directe différente | Un nom PTR existe, mais ses enregistrements directs ne contiennent pas l’adresse | Demander au fournisseur de modifier le PTR, ou ajouter l’adresse à l’enregistrement A ou AAAA du nom |
| Aucun PTR observé | La zone inverse répond qu’aucun nom n’existe pour cette adresse | Demander au titulaire de l’adresse d’en créer un, si l’adresse envoie des e-mails ou a besoin d’un nom |
| Vérification impossible | Un résolveur a échoué, n’a pas répondu à temps ou a renvoyé une réponse incohérente | Relancer la recherche plus tard avant de modifier quoi que ce soit |
Recherches observées
Nous avons recherché ces adresses publiques le 2 novembre 2026 via les résolveurs DNS over HTTPS de Cloudflare et de Google. Chaque nom renvoyait bien vers l’adresse d’origine.
| Adresse | Nom PTR | La résolution directe inclut l’adresse |
|---|---|---|
| 8.8.8.8 | dns.google | Oui (8.8.8.8 et 8.8.4.4) |
| 1.1.1.1 | one.one.one.one | Oui (1.1.1.1 et 1.0.0.1) |
| 9.9.9.9 | dns9.quad9.net | Oui (9.9.9.9 et 149.112.112.9) |
| 173.194.118.27 | yukulhq-in-f27.1e100.net | Oui |
Ce que montrent les exemples
La quatrième adresse était, à ce moment-là, celle renvoyée pour le serveur de réception de Gmail, gmail-smtp-in.l.google.com. Son nom PTR ne se trouve pas sous gmail.com mais sous 1e100.net, le domaine que Google utilise pour nommer ses serveurs. Un nom PTR n’a pas à correspondre au domaine sous lequel un service est connu ; il doit renvoyer vers l’adresse.
Les deux résolveurs ont renvoyé les mêmes noms avec des durées de cache restantes très différentes. Pour 8.8.8.8, Cloudflare indiquait 84 907 secondes et Google 18 566 secondes, car chacun avait mis l’enregistrement en cache à un moment différent. Après la modification d’un enregistrement PTR par un fournisseur, l’ancien nom peut donc encore apparaître pendant toute la durée du TTL de l’enregistrement.
Une connexion à domicile a généralement un nom générique créé à partir de l’adresse. Une ligne haut débit à Bangkok vérifiée le même jour a renvoyé un nom de la forme ppp-a-b-c-d.revip8.asianet.co.th, où a à d sont les nombres qui composent l’adresse. De tels noms identifient le fournisseur et souvent le type de connexion, pas l’abonné.
Pourquoi les serveurs de messagerie en ont besoin
Les serveurs de messagerie destinataires utilisent le DNS inverse comme première vérification peu coûteuse contre le spam envoyé depuis des ordinateurs personnels compromis. Les consignes de Google pour les expéditeurs exigent que les serveurs d’envoi disposent d’un enregistrement PTR valide qui renvoie vers l’adresse d’envoi, et d’autres grands fournisseurs de messagerie appliquent des contrôles similaires. Les noms génériques, comme celui de la ligne haut débit citée plus haut, sont couramment considérés comme résidentiels et filtrés.
- Choisissez pour le serveur un nom d’hôte sous un domaine que vous contrôlez, par exemple mail.example.com.
- Créez un enregistrement A, et un enregistrement AAAA si le serveur envoie en IPv6, qui fait pointer ce nom d’hôte vers l’adresse du serveur.
- Demandez au fournisseur titulaire de l’adresse de définir l’enregistrement PTR de cette adresse sur le même nom d’hôte. Faites-le pour chaque adresse depuis laquelle le serveur envoie, en IPv4 comme en IPv6.
- Configurez le serveur de messagerie pour qu’il annonce ce même nom d’hôte dans sa salutation SMTP (HELO ou EHLO).
- Vérifiez le résultat avec la recherche DNS inverse d’IPNixa jusqu’à ce que les deux résolveurs indiquent une concordance, en laissant au TTL de l’ancien enregistrement le temps d’expirer.
Ce que le DNS inverse ne peut pas vous dire
Un nom PTR est une étiquette choisie par le titulaire de l’adresse. Il peut être obsolète, générique ou absent, et il n’indique rien sur la personne qui utilise aujourd’hui une adresse dynamique. Servez-vous-en pour identifier le réseau ou le rôle du serveur, pas une personne. Les adresses privées comme 192.168.1.10 n’ont pas d’enregistrements inverses publics : la recherche les ignore donc.
Questions fréquentes
Puis-je définir un enregistrement PTR chez mon registrar ?
Généralement non. L’enregistrement PTR appartient à la zone inverse de l’adresse IP, que contrôle le titulaire du bloc d’adresses. Adressez-vous à votre hébergeur ou à votre fournisseur d’accès ; certains fournisseurs cloud permettent de le définir dans les paramètres du serveur ou de l’adresse.
Une adresse peut-elle avoir plusieurs noms PTR ?
Le DNS le permet, mais de nombreux systèmes n’en utilisent qu’un seul. Pour un serveur de messagerie, publiez exactement un nom PTR par adresse et faites en sorte qu’il renvoie vers cette même adresse.
Ma connexion à domicile a-t-elle besoin d’un DNS inverse ?
Pas pour naviguer, jouer ou regarder du streaming. Il n’a d’importance que si vous exploitez un serveur que d’autres vérifient par son nom, comme un serveur de messagerie, et la plupart des fournisseurs d’accès résidentiels ne permettent pas à leurs clients de le modifier.
Pourquoi la recherche indique-t-elle une incohérence pour un grand site web ?
Les réseaux de diffusion de contenu (CDN) et les répartiteurs de charge attribuent souvent des noms PTR à leur propre infrastructure, et les enregistrements directs de ces noms peuvent changer rapidement. Une incohérence compte pour un serveur de messagerie que vous gérez, beaucoup moins pour un site que vous visitez.