DNS inversé demande un nom associé à une adresse IP. Pour un expéditeur de courrier, l'adresse pertinente est la source publique utilisée sur la connexion SMTP . Un enregistrement PTR à cette adresse constitue une preuve d'infrastructure utile, mais ce n'est pas le cas. SPF autorisation, un Signature DKIM ou la preuve qu'un message est légitime.
Identifiez la véritable adresse et l’autorité
Références : RFC 1035 §3.5, RFC 3596 §2.5.
Commencez par l’adresse IP vue par le système récepteur ou par une observation SMTP externe contrôlée. L'adresse privée d'une application, l'adresse d'un équilibreur de charge et l'adresse de sortie du fournisseur peuvent différer. Répertoriez chaque famille et pool d’adresses sortantes que le service peut utiliser.
Les requêtes inversées IPv4 utilisent des octets inversés sous in-addr.arpa. IPv6 utilise des quartets hexadécimaux inversés sous ip6.arpa. L'autorité pour ces zones inversées suit l'attribution IP et toute délégation. Il s'agit généralement du fournisseur d'hébergement ou du réseau, et non du bureau d'enregistrement ou de l'hôte DNS du domaine visible de l'expéditeur. La publication d'un nom de type PTR dans une zone de transfert sans rapport ne changera pas la véritable réponse inverse.
Coordonner les deux directions
Références : RFC 1912 §2.1, RFC 2181 §10.2.
Demandez à l'opérateur de zone inversée le processus de modification pris en charge et l'adresse IP publique exacte. Choisissez un nom d'hôte d'infrastructure prévu et assurez-vous que ses données d'adresse de transfert incluent cette adresse IP. RFC 1912 recommande de faire correspondre les données inverses et directes ; il s'agit d'un guide opérationnel et non d'un contrat d'acceptation universelle du récepteur.
RFC 2181 précise que DNS ne limite pas une adresse à exactement un PTR . Les noms renvoyés doivent être conservés en preuve plutôt que ignorés en silence. Pour une administration prévisible, un nom d'hôte stable et documenté est souvent plus simple, mais les exigences spécifiques au récepteur nécessitent leur propre documentation à jour. Ne prétendez pas qu’un seul modèle PTR garantit la livraison à chaque fournisseur.
Reproduire une recherche inversée
Appareil IPv4 synthétique : adresse source 192.0.2.25; propriétaire inversé 25.2.0.192.in -addr.arpa.; Objectif PTR smtp.example.com.; avancer A vers cette cible 192.0.2.25. La réponse inverse attendue est le nom d'hôte et la confirmation avant attendue inclut l'adresse IP d'origine.
Dans une zone inversée isolée, interrogez creuser @AUTH -x 192.0.2.25 +norecurse puis interrogez smtp.example.com. A contre l'autorité avancée du laboratoire. Conservez l’autorité utilisée pour chaque direction, car il n’est pas nécessaire qu’il s’agisse de la même organisation. Supprimez le PTR pour un deuxième appareil : la preuve attendue est une absence ou une erreur classée dans la réponse réelle, et non un nom d'hôte nouvellement inventé.
Pour IPv6 , utilisez la conversion adresse-inverse de l'outil de recherche au lieu d'abréger manuellement le nom du quartet. Requête creuser @AUTH -x 2001:db8::25 +norecurse, en remplaçant AUTH par le résolveur de laboratoire configuré. Un contrôle de production doit utiliser une adresse source réelle observée ; ces plages de documentation ne décrivent pas un expéditeur réel.
Distinguer l'infrastructure de l'authentification
Références : RFC 7208 §5.5, RFC 9989 §5.3.5.
Une cible PTR n'a pas besoin d'être le domaine De visible simplement parce que le courrier utilise ce domaine. Un fournisseur peut exploiter une infrastructure d'envoi partagée avec son propre nom d'hôte. Ce qui compte pour une politique de réception particulière doit être vérifié séparément du SPF et DKIM alignement.
N'ajoutez pas le SPF déconseillé ptr mécanisme juste pour rendre DNS inversé pertinent pour SPF . Conservez PTR en tant que problème d'infrastructure et configurez SPF avec l'autorisation d'expéditeur réellement prise en charge. Après les modifications, vérifiez les réponses avant et arrière, l'introduction SMTP et la réponse du récepteur pertinente. Limitez toute conclusion de livraison à l’itinéraire et à l’heure testés.
Gardez la portée des preuves explicite
Une conversion de bibliothèque d'adresses locale confirme que 192.0.2.25 correspond à 25.2.0.192.in -addr.arpa et génère le nom complet du quartet IPv6 . Ce calcul n’interroge ni la zone inversée ni n’établit l’existence d’un PTR . Aucun test de livraison ou de politique de réception n'a été effectué.