Le DNS inversé (reverse DNS, ou rDNS) répond à une question différente de celle du DNS classique : au lieu de « vers quelle IP pointe ce nom d'hôte ? », il répond à « vers quel nom d'hôte pointe cette IP ? » Le mécanisme sous-jacent est l'enregistrement PTR (pointer), et les serveurs mail le vérifient comme un contrôle de base pour s'assurer que la machine qui envoie le message est bien celle qu'elle prétend être. S'il est mal configuré, vos e-mails sortants ont beaucoup plus de chances de finir dans les spams, même si vos enregistrements SPF, DKIM et DMARC sont parfaits.
Qu'est-ce que le DNS inversé ?
Une résolution DNS classique (directe) prend un nom d'hôte comme mail.example.com et renvoie un enregistrement A ou AAAA contenant une adresse IP. Le DNS inversé fait l'inverse : à partir d'une adresse IP, il renvoie un nom d'hôte via un enregistrement PTR. Cette correspondance a été définie dans la spécification DNS d'origine (RFC 1035) et se trouve dans des zones inverses spéciales plutôt que dans le fichier de zone habituel de votre domaine.
Vous pouvez vérifier les enregistrements de n'importe quelle IP ou nom d'hôte avec un outil de recherche DNS ; pour les recherches inversées en particulier, la plupart des outils permettent d'interroger directement le type d'enregistrement PTR sur l'IP.
Comment fonctionnent les zones in-addr.arpa et ip6.arpa
Le DNS inversé ne se trouve pas sous votre domaine. Il se trouve sous deux zones spéciales, fondées sur les adresses IP, que la racine du DNS délègue en suivant la hiérarchie de numérotation :
- IPv4 utilise
in-addr.arpa. Les quatre octets de l'adresse sont inversés puis ajoutés devant ce suffixe. Ainsi,192.0.2.1devient1.2.0.192.in-addr.arpa. - IPv6 utilise
ip6.arpa(défini dans la RFC 3596). Chaque quartet hexadécimal de l'adresse de 128 bits est inversé et séparé par des points, ce qui donne un nom beaucoup plus long de 32 labels.
Comme in-addr.arpa est structuré par octet, les zones inverses sont habituellement déléguées aux frontières /8, /16 ou /24. Si votre FAI vous attribue un bloc plus petit, par exemple un /27, la délégation in-addr.arpa classique ne s'applique pas proprement. La RFC 2317 (« classless in-addr.arpa delegation ») résout ce problème avec une solution de contournement basée sur des CNAME, afin que les blocs inférieurs à un /24 puissent tout de même bénéficier d'une délégation PTR correcte.
Pourquoi les serveurs mail ont besoin d'un enregistrement PTR
La plupart des serveurs mail destinataires vérifient l'enregistrement PTR de l'IP qui se connecte dans le cadre du filtrage antispam. Deux contrôles sont courants :
- Existence du PTR : l'IP d'envoi possède-t-elle un enregistrement PTR ? De nombreux filtres antispam considèrent l'absence de PTR comme un signal d'alerte, car les serveurs mail légitimes en ont presque toujours un.
- DNS inversé confirmé par résolution directe (FCrDNS) : le serveur destinataire prend le nom d'hôte du PTR et effectue une résolution directe sur celui-ci. Si cet enregistrement A/AAAA renvoie bien la même IP, l'identité est confirmée dans les deux sens. Une incohérence, ou un PTR qui ne résout vers rien, ressemble à de l'usurpation.
Un PTR générique attribué par le FAI (du type 123-45-67-89.dynamic-ip.example.net) au lieu d'un véritable nom d'hôte de serveur mail est aussi un signal courant qui nuit à la réputation de l'expéditeur, même s'il résout techniquement. Si vous enquêtez sur un problème de délivrabilité, c'est l'un des premiers points à vérifier, au même titre que SPF, DKIM et DMARC : consultez pourquoi vos e-mails arrivent dans les spams pour une vue d'ensemble, et utilisez l'outil de recherche MX pour confirmer en même temps que votre routage mail est correct.
TipLa bonne pratique consiste à avoir exactement un enregistrement PTR par IP, et il doit correspondre au nom d'hôte que votre serveur mail présente dans son message d'accueil SMTP HELO/EHLO. Des enregistrements PTR multiples ou incohérents font échouer le contrôle FCrDNS, même lorsque l'e-mail est parfaitement légitime.
Comment configurer un enregistrement PTR
La personne qui contrôle votre enregistrement PTR dépend du propriétaire de l'adresse IP :
| Situation | Qui configure le PTR |
|---|---|
| VM cloud (AWS, GCP, Azure) | Le fournisseur, via une demande au support ou un paramètre de DNS inversé en libre-service lié à votre compte |
| VPS/serveur dédié | Le panneau de contrôle de l'hébergeur, ou votre interlocuteur commercial |
| Auto-hébergement avec votre propre bloc d'IP | Vous, une fois que votre FAI ou votre RIR a délégué la zone inverse à vos serveurs de noms |
| IP partagée/dynamique d'un FAI | Généralement impossible : vous ne contrôlez pas l'adresse |
Les fournisseurs cloud et VPS attribuent presque toujours un PTR par défaut pointant vers un nom d'hôte générique à leur marque, sauf si vous en configurez un personnalisé. Pour un serveur mail, ce PTR doit pointer vers le nom d'hôte réel sous lequel le serveur s'identifie, par exemple :
; Reverse zone: 2.0.192.in-addr.arpa
1.2.0.192.in-addr.arpa. IN PTR mail.example.com.
Et la résolution directe doit correspondre, afin que le FCrDNS soit confirmé dans les deux sens :
; Forward zone: example.com
mail.example.com. IN A 192.0.2.1
Chez un fournisseur cloud, vous faites généralement cette demande via sa console ou un ticket au support plutôt qu'en modifiant directement un fichier de zone, puisque vous n'êtes pas propriétaire de la zone in-addr.arpa ; le résultat final reste néanmoins la même paire PTR/A.
WarningConfigurer uniquement le PTR sans enregistrement A direct correspondant (ou l'inverse) fera échouer les contrôles FCrDNS. Vérifiez toujours les deux sens après chaque modification, et attendez-vous à un certain délai avant que le changement soit visible partout : consultez la propagation DNS expliquée si une recherche affiche encore l'ancienne valeur.
Le DNS inversé au-delà de l'e-mail
La délivrabilité des e-mails est la raison la plus fréquente pour laquelle on s'intéresse aux enregistrements PTR, mais le DNS inversé intervient aussi dans :
- Le diagnostic : traceroute et les journaux serveur résolvent les IP en noms d'hôte pour plus de lisibilité.
- Le contrôle d'accès : certains systèmes anciens et certaines politiques réseau effectuent des contrôles d'autorisation ou de refus basés sur le rDNS, bien que ce soit beaucoup moins courant que le filtrage des e-mails.
- L'hygiène réseau en général : un PTR correctement configuré fait partie des petits contrôles à inclure, aux côtés de SPF, DKIM, DMARC et CAA, lors de l'audit de la configuration DNS d'un domaine ; consultez 20 contrôles de sécurité DNS que tout domaine devrait réussir pour la liste complète.
La gestion des enregistrements PTR découle généralement de la gestion de serveurs et de messagerie répartis chez plusieurs fournisseurs, et c'est là que les choses se compliquent : un hébergeur gère le DNS inversé via un ticket au support, un autre via une option dans un panneau de contrôle, et il est facile de perdre de vue quelles IP disposent réellement d'un PTR correspondant. La gestion DNS d'InfraNest rend les enregistrements, les délégations et les particularités de chaque fournisseur visibles depuis un seul tableau de bord, pour qu'un PTR manquant ou incohérent ne passe pas inaperçu jusqu'à ce que la délivrabilité chute.
Vérifiez l'enregistrement PTR actuel de n'importe quelle IP avec l'outil de recherche DNS gratuit avant d'aller plus loin dans votre diagnostic.
Questions fréquentes
#Que se passe-t-il si mon serveur n'a pas d'enregistrement PTR ?
De nombreux serveurs mail destinataires considèrent l'absence d'enregistrement PTR comme un signal de spam et peuvent rejeter ou mettre en quarantaine les e-mails provenant de cette IP, même si SPF et DKIM sont validés. En dehors de l'e-mail, un PTR manquant signifie surtout que les journaux et les outils de diagnostic affichent une IP brute au lieu d'un nom d'hôte.
#Une adresse IP peut-elle avoir plusieurs enregistrements PTR ?
Techniquement oui, le DNS autorise plusieurs enregistrements PTR pour une même IP, mais la bonne pratique et la plupart des filtres de messagerie attendent exactement un nom d'hôte canonique par IP. Des enregistrements PTR multiples ou incohérents font couramment échouer les contrôles de DNS inversé confirmé par résolution directe (FCrDNS).
#Ai-je besoin du DNS inversé pour un site web qui n'envoie pas d'e-mails ?
Non : le DNS inversé compte surtout pour les serveurs mail sortants et pour le diagnostic réseau. Un serveur uniquement web qui n'envoie pas d'e-mails n'a guère besoin d'un enregistrement PTR personnalisé, au-delà de celui attribué par défaut par votre hébergeur.
#Pourquoi ne puis-je pas configurer d'enregistrement PTR sur ma connexion Internet domestique ?
La délégation du DNS inversé suit la propriété des adresses IP, et les FAI grand public restent propriétaires des blocs d'adresses attribués à leurs clients au lieu de leur déléguer les zones inverses. C'est l'une des raisons pour lesquelles les serveurs mail fonctionnant sur des IP domestiques dynamiques sont presque toujours signalés comme à haut risque par les filtres antispam.
Essayez avec un outil gratuit
Cet article vous a-t-il été utile ?
