रिवर्स DNS आईपी पते से जुड़ा नाम पूछता है। मेल प्रेषक के लिए, प्रासंगिक पता SMTP कनेक्शन पर उपयोग किया जाने वाला सार्वजनिक स्रोत है। उस पते पर एक PTR रिकॉर्ड उपयोगी बुनियादी ढाँचा साक्ष्य है, लेकिन ऐसा नहीं है SPF प्राधिकरण, ए DKIM हस्ताक्षर या इसका प्रमाण कि कोई संदेश वैध है।
वास्तविक पता और प्राधिकारी की पहचान करें
सन्दर्भ: RFC 1035 §3.5, RFC 3596 §2.5.
प्राप्तकर्ता प्रणाली या नियंत्रित बाहरी SMTP अवलोकन द्वारा देखे गए आईपी से प्रारंभ करें। किसी एप्लिकेशन का निजी पता, लोड बैलेंसर पता और प्रदाता का निकास पता भिन्न हो सकता है। प्रत्येक आउटबाउंड पता परिवार और पूल की सूची बनाएं जिसका उपयोग सेवा कर सकती है।
IPv4 रिवर्स क्वेरीज़ in-addr.arpa के अंतर्गत रिवर्स ऑक्टेट का उपयोग करती हैं। IPv6 ip6.arpa के अंतर्गत उल्टे हेक्साडेसिमल निबल्स का उपयोग करता है। उन रिवर्स ज़ोन के लिए प्राधिकरण आईपी आवंटन और किसी भी प्रतिनिधिमंडल का अनुसरण करता है। यह आमतौर पर होस्टिंग या नेटवर्क प्रदाता होता है, न कि प्रेषक के दृश्यमान डोमेन के लिए रजिस्ट्रार या DNS होस्ट। किसी असंबंधित फॉरवर्ड ज़ोन में पीटीआर जैसा नाम प्रकाशित करने से वास्तविक विपरीत उत्तर नहीं बदलेगा।
दोनों दिशाओं का समन्वय करें
सन्दर्भ: RFC 1912 §2.1, RFC 2181 §10.2.
समर्थित परिवर्तन प्रक्रिया और सटीक सार्वजनिक आईपी के लिए रिवर्स-ज़ोन ऑपरेटर से पूछें। एक इच्छित इन्फ्रास्ट्रक्चर होस्टनाम चुनें और सुनिश्चित करें कि इसके आगे के पते के डेटा में वह आईपी शामिल है। RFC 1912 रिवर्स और फॉरवर्ड डेटा के मिलान की सिफारिश करता है; यह परिचालन मार्गदर्शन है, सार्वभौमिक रिसीवर स्वीकृति अनुबंध नहीं।
RFC 2181 स्पष्ट करता है कि DNS किसी पते को बिल्कुल एक PTR तक सीमित नहीं करता है। लौटाए गए एकाधिक नामों को चुपचाप खारिज करने के बजाय साक्ष्य के रूप में बनाए रखा जाना चाहिए। पूर्वानुमेय प्रशासन के लिए, एक स्थिर प्रलेखित होस्टनाम अक्सर सरल होता है, लेकिन रिसीवर-विशिष्ट आवश्यकताओं के लिए अपने स्वयं के वर्तमान दस्तावेज़ की आवश्यकता होती है। यह दावा न करें कि एक PTR पैटर्न प्रत्येक प्रदाता को डिलीवरी की गारंटी देता है।
एक रिवर्स लुकअप पुन: प्रस्तुत करें
सिंथेटिक IPv4 फिक्सचर: स्रोत पता 192.0.2.25; उल्टा मालिक 25.2.0.192.in -addr.arpa.; PTR लक्ष्य smtp.example.com.; उस लक्ष्य पर A को आगे बढ़ाएं 192.0.2.25. अपेक्षित विपरीत उत्तर होस्टनाम है, और अपेक्षित अग्रेषित पुष्टिकरण में मूल आईपी शामिल है।
एक अलग रिवर्स ज़ोन में, क्वेरी करें खोदो @AUTH -x 192.0.2.25 +नोरेकर्स और फिर क्वेरी करें smtp.example.com. A लैब फॉरवर्ड अथॉरिटी के खिलाफ। प्रत्येक दिशा के लिए उपयोग किए गए प्राधिकार को सुरक्षित रखें क्योंकि उन्हें एक ही संगठन होने की आवश्यकता नहीं है। दूसरी स्थिरता के लिए PTR हटाएं: अपेक्षित साक्ष्य अनुपस्थिति या वास्तविक प्रतिक्रिया से वर्गीकृत त्रुटि है, न कि कोई नया आविष्कृत होस्टनाम।
IPv6 के लिए, निबल नाम को मैन्युअल रूप से संक्षिप्त करने के बजाय लुकअप टूल के एड्रेस-टू-रिवर्स रूपांतरण का उपयोग करें। सवाल dig @AUTH -x 2001:db8::25 +norecurse, AUTH के लिए कॉन्फ़िगर किए गए लैब रिज़ॉल्वर को प्रतिस्थापित करना। उत्पादन जांच में वास्तविक देखे गए स्रोत पते का उपयोग होना चाहिए; ये दस्तावेज़ श्रेणियाँ किसी जीवित प्रेषक का वर्णन नहीं करतीं।
बुनियादी ढाँचे को प्रमाणीकरण से अलग करें
सन्दर्भ: RFC 7208 §5.5, RFC 9989 §5.3.5.
एक PTR लक्ष्य को केवल इसलिए डोमेन से दृश्यमान होने की आवश्यकता नहीं है क्योंकि मेल उस डोमेन का उपयोग करता है। एक प्रदाता अपने स्वयं के होस्टनाम के साथ साझा भेजने के बुनियादी ढांचे को संचालित कर सकता है। किसी विशेष प्राप्त पॉलिसी के लिए जो मायने रखता है उसे SPF से अलग से जांचा जाना चाहिए DKIM संरेखण.
हतोत्साहित SPF न जोड़ें पीटीआर रिवर्स DNS SPF के लिए प्रासंगिक बनाने के लिए तंत्र। PTR बुनियादी ढांचे की चिंता के रूप में बनाए रखें और वास्तविक समर्थित प्रेषक प्राधिकरण के साथ SPF को कॉन्फ़िगर करें। परिवर्तनों के बाद, आगे और पीछे के उत्तरों, SMTP परिचय और संबंधित रिसीवर प्रतिक्रिया को सत्यापित करें। किसी भी डिलीवरी निष्कर्ष को परीक्षण किए गए मार्ग और समय तक सीमित रखें।
साक्ष्य का दायरा स्पष्ट रखें
एक स्थानीय पता-लाइब्रेरी रूपांतरण 192.0.2.25 मानचित्रों को 25.2.0.192.in -addr.arpa पर पुष्टि करता है और संपूर्ण IPv6 निबल नाम उत्पन्न करता है। वह गणना न तो रिवर्स ज़ोन की क्वेरी करती है और न ही यह स्थापित करती है कि PTR मौजूद है। कोई डिलीवरी या रिसीवर-पॉलिसी परीक्षण नहीं किया गया था।