Le DNS direct — nom vers IP — c’est la partie à laquelle la plupart des opérateurs pensent. Le DNS inverse — IP vers nom — c’est la partie qui décide silencieusement si un serveur de courriel tout neuf entre dans la boîte de réception ou reste en quarantaine une semaine. Gmail, Outlook et la plupart des plateformes de courriel entrant sérieuses rejettent les sessions SMTP venant d’IP dont le DNS inverse ne se confirme pas vers l’avant. Le Reverse DNS Lookup de PortJar est le test qui vous dit, en un écran, si vous avez bien configuré ça.
Ce que l’outil fait
Vous lui donnez une adresse IPv4 ou IPv6. Il interroge l’enregistrement PTR sous in-addr.arpa (ou ip6.arpa), lit le nom d’hôte retourné, puis résout ce nom d’hôte vers l’avant vers un enregistrement A ou AAAA. Si les réponses directe et inverse correspondent, la correspondance est confirmée vers l’avant. Si le PTR pointe vers un nom qui ne résout pas, ou qui résout vers une IP différente, l’outil le signale.
Cette dernière étape — forward-confirm — c’est ce qui sépare un test inverse utile d’une demi-réponse. Un registraire ou un panneau de contrôle d’hébergement peut vous montrer le PTR qu’il a posé, mais seul le système DNS public peut vous dire si votre zone directe est d’accord. Le destinataire de courriel fait exactement ce test depuis l’internet ouvert.
Comment l’utiliser
Ouvrez portjar.com/tools/reverse-dns et collez l’IP. Fonctionne en IPv4 et IPv6 — les deux comptent pour le courriel, parce que si vous annoncez un AAAA sur le nom d’hôte du courriel et que le PTR v6 est faux, Gmail vous fera échouer en v6 même quand le v4 est propre.
Pour une nouvelle IP que vous venez de monter pour du courriel sortant, lancez ce test dès que votre fournisseur dit que le PTR est posé. C’est plus rapide que de scruter les journaux de rejet chez le destinataire, et ça confirme ce que le destinataire verra vraiment.
Quand vous y recourriez
- Mise en service d’un nouveau relais de courriel sortant sur une IP fraîchement allouée — confirmer que le PTR est posé et se confirme vers l’avant avant d’y diriger du vrai trafic. Le guide de dépannage « courriel allant dans le pourriel » de PortJar en fait l’un des premiers tests.
- Un client se plaint que le courriel vers Gmail ou Outlook s’est mis à rebondir avec
does not meet IPv6 sending guidelinesoumessages from your IP have been blocked. Le DNS inverse est généralement la première chose à vérifier. - Après une migration de serveur où l’IP a changé, confirmer que le PTR a été mis à jour sur la nouvelle IP et que l’ancien PTR a été nettoyé.
- Lors d’une revue de journaux, quand une IP inconnue apparaît dans les journaux d’accès — une recherche inverse vous dit si l’hôte est vraiment ce qu’il prétend être (forward-confirm) ou si c’est une affirmation usurpée.
- Après que les MX Diagnostics de PortJar ont signalé un problème de PTR sur l’un des hôtes MX résolus, et vous voulez confirmer que la faille est dans le DNS inverse plutôt que dans le direct.
Quoi faire de la sortie
Un résultat confirmé vers l’avant avec un nom d’hôte sensé (quelque chose comme mail.example.com pour une IP qui appartient à votre serveur de courriel), c’est la seule réponse que vous voulez voir. Tout le reste demande de l’attention.
Un PTR pointant vers le nom générique du fournisseur d’hébergement — static.123.45.67.89.providerdomain.com — est techniquement confirmé vers l’avant si la zone du fournisseur est bien faite, mais aucun destinataire de courriel entrant ne fera autant confiance à du courriel venant de provider-generic.example.net qu’à du courriel venant de mail.votredomaine.com. Demandez au fournisseur de poser un PTR personnalisé correspondant au nom d’hôte annoncé en HELO/EHLO.
Un PTR qui retourne un nom qui ne résout pas du tout vers l’avant veut dire que la zone directe n’a pas l’enregistrement. Le correctif est dans la zone directe, pas dans le PTR. Ajoutez l’enregistrement A (et AAAA le cas échéant) pour qu’il corresponde.
Un PTR qui résout vers l’avant vers une IP différente de celle interrogée, c’est la mauvaise configuration classique après un remaniement d’IP. Corrigez le côté périmé — généralement la zone directe — et revérifiez.
Aucun PTR posé, c’est la forme la plus courante pour les IP qui n’ont jamais envoyé de courriel. Le fournisseur d’hébergement pose le PTR sur la plupart des plateformes, donc ça vit dans leur panneau de contrôle ou dans un billet de soutien, pas dans votre console DNS.
Stack Harbor vérifie le DNS inverse confirmé vers l’avant dans le cadre de la prise en charge des serveurs de courriel sous gestion de déploiement.