Reverse DNS (PTR) : à quoi ça sert et comment le configurer

Le reverse DNS (rDNS) est l’opération inverse de la résolution DNS classique : au lieu de traduire un nom de domaine en IP, il traduit une IP en nom de domaine. Configuré via un enregistrement PTR dans la zone in-addr.arpa, il est invisible pour 99 % des internautes — mais crucial pour la délivrabilité email, le whitelisting d’IP, le diagnostic réseau et la confiance accordée à un serveur. Cette page explique son fonctionnement, comment le vérifier, comment le configurer chez un hébergeur, et pourquoi il est indispensable.

DNS direct versus reverse DNS

DNS direct : google.com → 142.250.179.110. Géré via enregistrements A (IPv4) ou AAAA (IPv6) dans la zone du domaine.
Reverse DNS : 142.250.179.110 → par80s07-in-f14.1e100.net. Géré via enregistrements PTR dans une zone spéciale in-addr.arpa (IPv4) ou ip6.arpa (IPv6).

Le rDNS n’est pas le miroir automatique du DNS direct. Vous pouvez avoir exemple.com qui pointe vers 203.0.113.10, mais 203.0.113.10 qui ne pointe vers rien du tout (ou vers un autre nom). C’est l’IP propriétaire (votre hébergeur en général) qui contrôle le rDNS.

Le format technique : in-addr.arpa

Pour interroger le rDNS de 203.0.113.10, on inverse les octets et on ajoute .in-addr.arpa :

10.113.0.203.in-addr.arpa  →  IN PTR  mon-serveur.exemple.com.

En IPv6, le système est similaire mais découpé en quartets hexadécimaux dans la zone ip6.arpa. Heureusement, les outils comme nslookup ou dig gèrent cette inversion automatiquement.

Vérifier le reverse DNS d’une IP

Ligne de commande Linux/macOS : dig -x 203.0.113.10 ou host 203.0.113.10.
Windows : nslookup 203.0.113.10 retourne le nom inversé s’il existe.
Outils en ligne : MXToolbox Reverse Lookup, mxtoolbox.com/ReverseLookup.aspx, ou notre outil whois qui inclut souvent le rDNS.
Script bash rapide pour tester en masse : for ip in 1.1.1.1 8.8.8.8; do echo -n "$ip → "; dig +short -x $ip; done.

À quoi sert le reverse DNS ?

1. Délivrabilité email (le cas le plus critique)

Les serveurs SMTP de Gmail, Outlook, Yahoo et la plupart des autres vérifient :

Le rDNS de l’IP émettrice existe (PTR présent).
Le rDNS pointe vers un nom cohérent avec le domaine du HELO/EHLO et du « From ».
Le DNS direct du nom inversé pointe bien sur la même IP (forward-confirmed reverse DNS, FCrDNS).

Sans rDNS cohérent, le mail est généralement rejeté ou marqué spam. C’est l’une des causes #1 de problème de délivrabilité email.

2. Diagnostic réseau

Quand on analyse un log avec des IP suspectes, le rDNS donne souvent un indice rapide sur l’origine : 172.105.x.x → linode, 34.x.x.x → google cloud, 13.x.x.x → aws. Sans avoir besoin de whois.

3. Logs lisibles

Beaucoup de serveurs (Nginx, Apache, sshd) résolvent les IP en noms via rDNS pour les logs. Plus lisible que des IP brutes. Désactivable pour performance (UseDNS no sur OpenSSH).

4. Authentification et whitelist

Certains services pro autorisent une IP à condition que son rDNS pointe vers un nom prédéfini. Plus solide qu’une simple liste d’IP — il faut contrôler à la fois l’IP et la zone PTR.

Configurer le reverse DNS chez les hébergeurs courants

Pour configurer un rDNS, c’est le propriétaire de la plage IP qui agit, donc votre hébergeur ou FAI. Vous demandez la modification dans son panel :

OVH : Manager > IP > clic sur l’IP > champ « Reverse ». Modification immédiate. Gratuit.
Hetzner : Robot > IPs > Reverse DNS. Gratuit, immédiat.
AWS EC2 : nécessite Elastic IP + formulaire support pour configurer PTR. Lent (jours).
Scaleway : panel > Instances > onglet Reverse DNS, modification directe.
DigitalOcean, Linode, Vultr : panel droplet > Networking ou similaire.
Google Cloud : pour avoir un rDNS personnalisé, il faut passer par Cloud DNS + déclarations explicites.
FAI résidentiel : 99 % des cas, le rDNS est verrouillé sur le pattern « dynamic.xxx.fai.fr ». Impossible à changer. C’est pour ça qu’on n’envoie pas du mail depuis chez soi.

Cohérence FCrDNS : ce qui vérifie vraiment

FCrDNS = Forward-Confirmed reverse DNS. Test en 2 étapes :

Reverse DNS : 203.0.113.10 → mail.exemple.com (PTR record).
DNS direct : mail.exemple.com → 203.0.113.10 (A record).

Les deux doivent concorder. Si le rDNS pointe vers un nom dont le A record ne renvoie pas l’IP de départ, l’identification échoue. C’est ce que vérifient Gmail et compagnie.

Problèmes courants de rDNS

Aucun PTR configuré : votre hébergeur n’a rien mis. Vérifier dans son panel, sinon contacter le support.
PTR par défaut générique : v123.456.789.10.cloudname.com. Rejet immédiat par les SMTP sérieux.
FCrDNS non aligné : PTR existe mais ne concorde pas avec le DNS direct.
Propagation lente : un changement de rDNS prend 0 à 48 h selon la TTL et l’hébergeur.
IP partagée mutualisé : impossible d’avoir un rDNS dédié sur un hébergement mutualisé. Solution : VPS ou serveur dédié.
Free Mobile / 4G : rDNS sur pattern opérateur. Conséquence : pas de mail SMTP direct depuis l’IP mobile.

Reverse DNS et vie privée

Le rDNS d’une IP résidentielle révèle souvent le FAI et la zone géographique. 203.0.113.10 → adsl-grenoble-pop3.fai.fr en dit long sur l’abonné. Pour la vie privée, c’est un signal additionnel à ne pas négliger. Un VPN change l’IP source visible donc le rDNS associé.

FAQ : reverse DNS

Qui contrôle le rDNS d’une IP ?

Le propriétaire de la plage IP, donc votre hébergeur ou FAI. Vous configurez via leur panel ou ticket support. Sur des plages que vous possédez (entreprise avec sa propre ASN), vous gérez votre zone in-addr.arpa directement.

Combien de temps pour propager un changement ?

Variable : OVH et Hetzner sont quasi instantanés (quelques minutes). AWS et certains gros providers peuvent prendre plusieurs heures. Délai max théorique : 48 h selon la TTL de la zone.

Un site web a-t-il besoin de rDNS ?

Pas indispensable pour un site web pur HTTP. Mais si le même serveur envoie aussi du mail (transactionnel WordPress, notifications), le rDNS devient critique. Bon réflexe de toujours configurer un rDNS cohérent avec le domaine principal du serveur.

Peut-on avoir plusieurs noms PTR pour une IP ?

Techniquement oui, mais c’est déconseillé. La plupart des serveurs SMTP ne prennent en compte qu’un seul PTR. Mettre plusieurs valeurs déclenche des comportements imprévisibles. Pour un usage multi-domaines, configurer un PTR neutre du serveur (mail.exemple.com) et laisser DKIM/SPF gérer les domaines spécifiques.

Le rDNS est-il obligatoire pour envoyer des mails ?

Juridiquement non, techniquement quasi. Sans PTR cohérent, Gmail, Outlook, Yahoo rejettent au mieux 50 %, classent en spam le reste. Combiné avec SPF/DKIM/DMARC, le PTR est le minimum vital pour la délivrabilité.

Pages liées : DNS, SPF DKIM DMARC, IP blacklist email, enregistrements DNS, encyclopédie IP.