A और AAAA रिकॉर्ड होस्टनाम को IPv4 और IPv6 पतों पर मैप करते हैं। वे किसी मेल सेवा की निर्भरताएँ हैं, न कि यह घोषणा कि सेवा भेजने के लिए तैयार या अधिकृत है। किसी पते को प्रकाशित करने से वह मार्ग उजागर हो सकता है जिसे ग्राहक वास्तव में आज़माते हैं, इसलिए प्रत्येक विज्ञापित परिवार और समापन बिंदु को सत्यापित करें।
प्रोटोकॉल द्वारा प्रयुक्त नाम का पालन करें
सन्दर्भ: RFC 5321 §5.1, RFC 7208 §5.3, RFC 7208 §5.4.
इनबाउंड SMTP के लिए, MX द्वारा लौटाए गए एक्सचेंज होस्टनाम को हल करें। जब स्पष्ट आदान-प्रदान अनुपयोगी हो तो प्राप्तकर्ता डोमेन का वेबसाइट पता कोई विकल्प नहीं है। यदि कोई MX मौजूद नहीं है, तो SMTP का निहित-एमएक्स नियम प्राप्तकर्ता डोमेन के स्वयं के ए या एएएए रिकॉर्ड को प्रासंगिक बना सकता है।
आउटबाउंड के लिए SPF, वास्तविक नीति और मूल्यांकन की गई पहचान की जांच करें। एक a तंत्र अपने निर्दिष्ट नाम के लिए लौटाए गए पतों को अधिकृत कर सकता है; एक मैदान एक अभिलिखित किसी भी चीज़ को स्वयं अधिकृत नहीं करता. इसी तरह, SPF द्वारा उपयोग किए जाने वाले होस्टनाम को बदलना एमएक्स तंत्र अधिकृत के रूप में मूल्यांकित पतों को बदल सकता है। किसी DNS पते को केवल-वेबसाइट परिवर्तन के रूप में मानने से पहले इन संदर्भों को रिकॉर्ड करें।
दोहरे स्टैक को दो ऑपरेटिंग पथों के रूप में मानें
सन्दर्भ: RFC 1035 §3.4.1, RFC 3596 §2.1, RFC 3596 §2.3.
एक होस्टनाम में कई A रिकॉर्ड और कई AAAA रिकॉर्ड हो सकते हैं। उनकी उपस्थिति पहुंच योग्यता, SMTP सेवा, सही प्रमाणपत्र या समकक्ष नीति की गारंटी नहीं देती है। एक स्वस्थ IPv4 समापन बिंदु यह स्थापित नहीं करता है कि IPv6 काम करता है। इसके विपरीत, एक क्लाइंट पथ पर विफलता यह साबित नहीं करती कि प्रत्येक प्रेषक उस पथ का उपयोग करता है।
वास्तव में प्रयास किए गए गंतव्य पते, पता परिवार, कनेक्शन परिणाम और SMTP प्रतिक्रिया को कैप्चर करें। यदि आउटबाउंड ट्रैफ़िक की जांच कर रहे हैं, तो यह मानने के बजाय कि यह एप्लिकेशन के अंदर उपयोग किए गए पते से मेल खाता है, बाहरी रूप से देखे गए स्रोत पते को कैप्चर करें। NAT और प्रदाता निकास पूल उन मानों को भिन्न बना सकते हैं।
पता-पारिवारिक दोष को पुन: प्रस्तुत करें
सिंथेटिक स्थिरता: example.com. MX 10 mx.example.com.; mx.example.com. A 192.0.2.10; mx.example.com . एएएए 2001:db8::10. लैब में, पोर्ट 25 पर टीसीपी कनेक्शन स्वीकार करने के लिए IPv4 एंडपॉइंट को कॉन्फ़िगर करें और IPv6 एंडपॉइंट को पहुंच से बाहर छोड़ दें। अपेक्षित DNS जाँच दोनों रिकॉर्ड प्रकारों के लिए सफल होती है, जबकि परिवार-विशिष्ट कनेक्शन परीक्षण केवल IPv4 के लिए सफल होता है।
सवाल खोदो @AUTH mx.example.com । ए+नोरेशाप और फिर वही आदेश AAAA. AUTH को पृथक प्राधिकारी से बदलें। दोनों उत्तर रिकार्ड करें. प्रत्येक गंतव्य को स्वतंत्र रूप से पिन करने, कनेक्शन और प्रोटोकॉल परिणामों को रिकॉर्ड करने के लिए अपने अनुमोदित लैब SMTP क्लाइंट का उपयोग करें। फिक्स्चर दर्शाता है कि DNS सफलता सेवा सफलता क्यों नहीं है; यह किसी विशेष प्रेषक के फ़ॉलबैक समय के बारे में कोई दावा नहीं करता है।
दूसरा फिक्स्चर केवल A पते को बदलता है 192.0.2.10 को 192.0.2.20 जबकि SPF नीति है v=spf1 a:mx.example.com -all. अन्यथा सफल लुकअप के साथ IPv4 SPF मूल्यांकन के लिए, पता मिलान के योग्य है a तंत्र परिवर्तन. एक स्पष्ट ip4:192.0.2.10 तंत्र तब तक उस शाब्दिक नेटवर्क से बंधा रहेगा जब तक कि नीति स्वयं नहीं बदल जाती।
पते में परिवर्तन को प्रतिवर्ती बनाएं
सन्दर्भ: RFC 8767 §4.
मेल रूटिंग, SPF संदर्भ, निगरानी और प्रमाणपत्र अपेक्षाओं सहित होस्टनाम के सभी उपभोक्ताओं की सूची। इसका विज्ञापन करने से पहले समापन बिंदु तैयार करें। पुरानी सेवा को बनाए रखें, जबकि उपयुक्त कैश अभी भी सार्वभौमिक प्रतीक्षा अवधि के बजाय वास्तविक माइग्रेशन योजना के आधार पर ट्रैफ़िक को निर्देशित कर सकता है।
परिवर्तन के बाद, आधिकारिक उत्तरों की तुलना पुनरावर्ती टिप्पणियों और संदेश-स्तरीय साक्ष्यों से करें। एक विफल IPv6 समापन बिंदु को एक अनुमोदित परिवर्तन के माध्यम से मरम्मत या हटाया जाना चाहिए, न कि असंबंधित प्रमाणीकरण नीतियों को कमजोर करके छिपाया जाना चाहिए। कार्य तभी बंद करें जब इच्छित पते और संचालन पथ प्रलेखित सेवा डिज़ाइन से मेल खाते हों।
साक्ष्य का दायरा स्पष्ट रखें
दो-परिवार परिदृश्य के लिए, परीक्षण होने तक अपेक्षित IPv4 सफलता और IPv6 विफलता को प्रस्तावित प्रयोगशाला अवलोकन के रूप में रखें। SPF पता-परिवर्तन उदाहरण सफल लुकअप और बताई गई नीति को मानता है; यह किसी भी वास्तविक प्रेषक के लिए वर्तमान प्राधिकरण स्थापित नहीं करता है।