C'est le seul outil du site qui prend une adresse IP et non un nom de domaine — le PTR appartient à l'adresse. Il le lit, puis il refait le chemin en sens inverse : le nom obtenu répond-il bien, en retour, à cette même adresse ? C'est cette boucle, et non le PTR tout seul, que regardent les serveurs qui reçoivent votre courrier.
Le mécanisme
L'aller-retour
Une requête inverse n'est pas une requête d'un genre spécial : c'est une requête ordinaire, posée sur un nom fabriqué à partir de l'adresse. Déroulez les quatre temps, et changez de cas pour voir la boucle se refermer — ou partir ailleurs.
Le cas
L'adresse de départ
203.0.113.10
Le nom réellement interrogé
10.113.0.203.in-addr.arpa
PTR
Ce que répond le PTR
…
A · AAAA
Ce que répond ce nom, en retour
…
01
On retourne l'adresse
Les quatre octets sont écrits à l'envers et suivis de in-addr.arpa. C'est tout le secret : l'adresse devient un nom de domaine ordinaire. En IPv6, ce sont les 32 chiffres hexadécimaux, un par label, suivis de ip6.arpa.
Adresses d'exemple : plages de documentation des RFC 5737 et 3849. Noms d'exemple : RFC 2606. Le format des noms interrogés vient des RFC 1035 § 3.5 et 3596 § 2.5.
La question qui revient en boucle
Puis-je créer ce PTR chez le registrar de mon domaine ?
Non
C'est la confusion fondatrice de ce sujet, et elle coûte des heures. Un PTR ne vit pas dans la zone de votre domaine : il vit dans in-addr.arpa, une arborescence parallèle qui suit les ADRESSES et non les NOMS, déléguée le long de la chaîne d'attribution. Vous pouvez ajouter dans votre zone autant de lignes intitulées « PTR » que vous voulez : aucun serveur au monde n'ira les lire. La ligne qui compte se remplit chez celui qui vous a attribué l'adresse.
Alors chez qui ?
Un serveur loué
Chez l'hébergeur, dans la fiche de la machine. Le champ s'appelle « reverse DNS », « PTR » ou « rDNS » et se trouve en face de l'adresse. La prise d'effet est généralement immédiate.
Une adresse fournie par un opérateur
Chez l'opérateur, par ticket ou par son espace client. C'est lui qui tient la zone du bloc dont votre adresse fait partie ; personne d'autre ne peut écrire à sa place.
Un bloc qui vous appartient
Chez vous, dans la zone inverse que le registre internet régional vous a déléguée — ou celle que votre opérateur vous délègue par alias, si votre bloc est plus petit qu'un /24.
Lire le résultat
Le PTR seul ne dit presque rien. Ce qui compte tient en une question : le nom qu'il annonce revient-il à l'adresse de départ ?
Boucle fermée
L'adresse annonce un nom, et ce nom résout en retour vers cette même adresse. C'est l'état attendu d'une machine qui envoie du courrier, et c'est ce que vérifient les grands destinataires.
Boucle rompue
Le nom annoncé existe bel et bien, mais il porte une autre adresse. C'est le cas le plus courant après une migration : le serveur a changé d'adresse, le PTR a suivi, le nom est resté sur l'ancienne. Vu du destinataire, l'adresse revendique un nom qui ne la reconnaît pas.
Aucun PTR
L'adresse ne déclare aucun nom. Rien n'est cassé — c'est l'état par défaut. Une adresse ne reçoit pas de PTR toute seule : quelqu'un doit l'écrire, chez le détenteur du bloc. Sur une machine qui n'envoie pas de courrier, c'est sans conséquence.
Boucle invérifiable
Le PTR annonce un nom, mais ce nom ne porte ni A ni AAAA. Il ne résout vers rien du tout : soit il a été supprimé, soit il n'a jamais existé, soit sa zone ne répond pas. Pour un serveur distant, le résultat est le même que la divergence.
Plusieurs noms sur une adresse
C'est permis, et parfois volontaire sur une machine qui héberge plusieurs services. Rien ne garantit pourtant lequel un serveur distant retiendra, ni dans quel ordre ils lui seront servis. Sur une adresse qui envoie du courrier, un seul nom évite la question.
Les quatre raisons pour lesquelles un PTR ne tombe pas juste
Presque jamais une faute de frappe. Presque toujours un enregistrement créé au mauvais endroit, ou la moitié d'un travail fait.
01
Le PTR a été créé dans la zone du domaine, chez le registrar
Ce qui la provoque : Le PTR n'habite pas votre zone. Il habite in-addr.arpa — ou ip6.arpa en IPv6 —, une arborescence déléguée le long de la chaîne d'attribution des adresses. Elle appartient donc à celui qui vous loue l'adresse, pas à celui qui vous a vendu le nom de domaine. Un « enregistrement PTR » ajouté dans la zone du domaine ne sera jamais lu par personne.
Le geste qui corrige : Cherchez « reverse DNS » ou « PTR » dans la console de l'hébergeur du serveur, ou de l'opérateur qui vous fournit l'adresse. Chez la plupart, c'est un champ libre en face de l'adresse ; chez quelques-uns, un ticket.
02
Le serveur a déménagé, le nom est resté derrière
Ce qui la provoque : La nouvelle adresse a bien reçu un PTR vers le nom du serveur, mais l'enregistrement A de ce nom pointe encore vers l'ancienne adresse. Le PTR est juste, la boucle est rompue — et l'outil le voit alors que les contrôles qui se contentent de lire le PTR annoncent « tout va bien ».
Le geste qui corrige : Corrigez le A du nom dans votre zone, pas le PTR. Puis relancez ce contrôle : c'est le retour, et lui seul, qui doit tomber sur l'adresse de départ.
03
Le PTR pointe vers un alias
Ce qui la provoque : Le nom déclaré est un CNAME vers un autre nom. La résolution finit souvent par aboutir, mais pas partout, et la RFC 1912 § 2.1 le déconseille explicitement : un PTR doit désigner un nom qui porte lui-même un A, pas un alias.
Le geste qui corrige : Faites pointer le PTR vers le nom qui porte l'enregistrement A — celui du serveur —, et non vers l'alias commercial qui le maquille.
04
L'IPv4 a son PTR, l'IPv6 n'en a pas
Ce qui la provoque : C'est le défaut le plus discret du lot. Le serveur a été configuré il y a des années sur son adresse IPv4, puis l'hébergeur lui a attribué une adresse IPv6. Quand le destinataire publie un AAAA, la connexion sort en IPv6 — et c'est cette adresse-là, sans PTR, qui est contrôlée à l'arrivée.
Le geste qui corrige : Contrôlez les deux adresses de votre serveur dans cet outil, une par une. Puis créez le PTR manquant, ou coupez la sortie IPv6 du service d'envoi tant qu'il n'existe pas.
Le nom qu'on interroge vraiment
Il n'existe pas de « requête inverse » dans le DNS. Il existe une requête PTR, ordinaire, posée sur un nom fabriqué à partir de l'adresse. Voici comment il se fabrique, et à qui appartient la zone qui le porte.
Ce que vous saisissez
Le nom réellement interrogé
À qui appartient la zone
203.0.113.10 (IPv4)
10.113.0.203.in-addr.arpa
Les quatre octets, à l'envers, suivis de in-addr.arpa — RFC 1035 § 3.5. La zone est déléguée avec le bloc d'adresses, donc à l'opérateur ou à l'hébergeur qui le détient.
2001:db8::1 (IPv6)
1.0.0.…0.8.b.d.0.1.0.0.2.ip6.arpa
Les 32 chiffres hexadécimaux de l'adresse, un par label, à l'envers, suivis de ip6.arpa — RFC 3596 § 2.5. Trente-quatre labels en tout, et c'est pour ça qu'on ne l'écrit jamais à la main.
Un bloc entier en /24
0.113.0.203.in-addr.arpa
La zone déléguée par le registre internet régional à celui qui a reçu le bloc. C'est le premier niveau auquel un client final peut parfois se voir confier ses propres PTR.
Un bloc plus petit qu'un /24
délégué par alias
Un /24 ne se coupe pas en quatre dans in-addr.arpa. La RFC 2317 contourne la limite en plaçant un alias par adresse vers une zone que le client tient lui-même. C'est le montage qu'on rencontre chez les opérateurs qui louent des adresses à l'unité.
Adresses d'exemple : plages de documentation des RFC 5737 (IPv4) et 3849 (IPv6).
Questions fréquentes
Comment crée-t-on un enregistrement PTR ?
Chez celui qui détient l'adresse, jamais chez le registrar du domaine. La zone in-addr.arpa est déléguée le long de la chaîne d'attribution des adresses : de l'IANA au registre internet régional, du registre à l'opérateur, de l'opérateur à l'hébergeur. Concrètement : un champ « reverse DNS » dans la console de votre serveur chez la plupart des hébergeurs, un ticket chez les autres. Si vous louez un serveur, c'est votre hébergeur. Si vous êtes derrière une offre mutualisée, vous n'envoyez pas depuis votre propre adresse et la question ne se pose pas pour vous.
Le PTR est-il vraiment obligatoire pour envoyer du courrier ?
Pour écrire à une boîte Gmail, oui, et c'est écrit noir sur blanc. Les consignes aux expéditeurs de Google demandent depuis le 1ᵉʳ février 2024 que les domaines ou adresses d'envoi aient « des enregistrements DNS directs et inverses valides, aussi appelés enregistrements PTR », et précisent que « l'adresse IP d'envoi doit correspondre à l'adresse IP du nom d'hôte indiqué dans l'enregistrement PTR » — c'est exactement la boucle que contrôle cet outil. Du côté de Microsoft 365, un message dont l'adresse d'envoi n'a pas de PTR valide se voit renvoyer un refus explicite, « 550 5.7.364 … invalid or missing PTR (reverse DNS) record ». Les autres destinataires n'exigent pas tous un PTR, mais beaucoup en tiennent compte dans leur notation.
DNS inverse et SPF, est-ce la même vérification ?
Non, et les deux se complètent. Le SPF part du domaine et énumère les adresses autorisées à envoyer en son nom : c'est le sens direct. Le PTR part de l'adresse et déclare le nom qu'elle porte : c'est le sens inverse. Un serveur peut passer le SPF et échouer sur le PTR, et l'inverse. Aucun des deux ne dispense de l'autre.
Puis-je déclarer plusieurs noms sur une même adresse ?
Rien ne l'interdit, et cet outil vous dira combien il en trouve. Mais l'ordre dans lequel ils vous seront servis n'est pas garanti, et rien ne dit lequel un serveur distant retiendra pour son contrôle. Sur une adresse qui envoie du courrier, un seul nom — celui que le serveur annonce dans son HELO — évite la question.
Mon PTR est correct, pourquoi mes messages partent-ils quand même en indésirable ?
Parce que le PTR n'est qu'un des contrôles. Il dit que la machine est correctement déclarée ; il ne dit rien du contenu du message, de la réputation de l'adresse, ni de l'alignement SPF, DKIM et DMARC du domaine expéditeur. Un PTR juste est une condition d'entrée, pas un laissez-passer.
Cet outil accepte-t-il les adresses IPv6 ?
Oui, dans les deux sens. Une adresse IPv6 est interrogée dans ip6.arpa, et le retour est vérifié sur les enregistrements A comme AAAA. Contrôlez les deux adresses de votre serveur séparément : un serveur dont seule l'IPv4 porte un PTR échoue dès que le destinataire publie un AAAA.
D'où descend l'autorité
La chaîne qui mène à votre PTR
Quatre maillons entre la racine du DNS et la ligne que quelqu'un doit écrire. Savoir lequel vous concerne, c'est savoir à qui écrire — et arrêter de chercher dans la mauvaise console.
01
L'IANA tient la racine des zones inverses
in-addr.arpa pour l'IPv4, ip6.arpa pour l'IPv6. Ce sont des zones du DNS comme les autres, à ceci près qu'elles sont indexées sur les adresses et non sur les noms.
02
Le registre internet régional reçoit les grands blocs
RIPE NCC pour l'Europe, ARIN pour l'Amérique du Nord, et leurs homologues ailleurs. En même temps que le bloc d'adresses, ils reçoivent la zone inverse qui lui correspond.
03
L'opérateur ou l'hébergeur reçoit sa part
Il redécoupe le bloc entre ses clients. C'est presque toujours à ce maillon-là que se remplit le PTR d'un serveur loué : le champ existe dans la console, et il est à vous.
04
Vous, si le bloc vous a été délégué
Un bloc en /24 ou plus grand se délègue directement. Plus petit, il se délègue par alias, selon le montage décrit par la RFC 2317. Dans les deux cas, c'est votre serveur de noms qui répond, et la ligne est à vous.
Délégation des zones inverses : RFC 1035 § 3.5 (in-addr.arpa), RFC 3596 § 2.5 (ip6.arpa), RFC 2317 (délégation d'un bloc plus petit qu'un /24).
Ce que regarde le destinataire
Le nom doit revenir à l'adresse.
Un PTR se lit dans les deux sens. Le serveur qui reçoit votre courrier lit le nom que votre adresse annonce, puis il demande à ce nom quelle adresse il porte. Si les deux ne se rejoignent pas, votre adresse revendique un nom qui ne la reconnaît pas.
PTRl'adresse annonce un nom
A · AAAAle nom annonce une adresse
=les deux doivent coïncider
Mot pour mot
Ce que demandent deux destinataires, tel qu'ils l'ont publié
Pas une estimation, pas un pourcentage : les deux textes ci-dessous sont publics, et ce sont eux que votre serveur doit satisfaire pour entrer.
Google — consignes aux expéditeurs
Applicable à tous les expéditeurs depuis le 1ᵉʳ février 2024.
Ensure that sending domains or IPs have valid forward and reverse DNS records, also referred to as PTR records. […] The sending IP address must match the IP address of the hostname specified in the Pointer (PTR) record.
Assurez-vous que les domaines ou adresses IP d'envoi disposent d'enregistrements DNS directs et inverses valides, aussi appelés enregistrements PTR. […] L'adresse IP d'envoi doit correspondre à l'adresse IP du nom d'hôte indiqué dans l'enregistrement PTR.
Les deux phrases décrivent exactement la boucle que contrôle cet outil : le PTR d'abord, la concordance ensuite.
Microsoft 365 — le refus qu'on reçoit
Code de refus renvoyé au serveur d'envoi, lisible dans les en-têtes du message rejeté.
550 5.7.364 Remote server returned invalid or missing PTR (reverse DNS) record for sending domain
550 5.7.364 Le serveur distant a renvoyé un enregistrement PTR (DNS inverse) absent ou invalide pour le domaine expéditeur.
Un refus définitif, pas un classement en indésirable : le message ne part pas. Le code se lit tel quel dans le rapport de non-remise.
Sources : consignes aux expéditeurs de Google (support.google.com/a/answer/81126) et documentation Microsoft Learn pour le code 550 5.7.364. Citations reproduites dans leur langue d'origine, traduction en dessous.