The SPF ए और एमएक्स तंत्र DNS के माध्यम से खोजे गए पतों को अधिकृत करते हैं। वे मैन्युअल पते के रखरखाव को कम कर सकते हैं, लेकिन वे अन्य नौकरियों के लिए बनाए गए रिकॉर्ड के लिए आउटबाउंड अनुमति भी जोड़ते हैं। इसलिए वेबसाइट माइग्रेशन या इनबाउंड-मेल परिवर्तन बिना किसी संपादन के SPF बदल सकता है SPF रिकॉर्ड स्वयं.
सही सवाल यह नहीं है कि ये तंत्र वैध हैं या नहीं। यह है कि क्या DNS निर्भरता आपकी इच्छित भेजने की नीति को व्यक्त करती है।
वास्तव में क्या मूल्यांकन करता है
ए तंत्र चयनित लक्ष्य नाम को SMTP कनेक्शन परिवार के लिए उपयुक्त पते पर हल करता है। यह IPv4 कनेक्शन के लिए A और मूल IPv6 के लिए AAAA का उपयोग करता है; IPv4-मैप्ड IPv6 को IPv4 के रूप में माना जाता है RFC 7208 §5. अपने नाम के बावजूद, a IPv4 तक सीमित नहीं है। यदि कोई लक्ष्य छोड़ दिया जाता है, तो वर्तमान SPF मूल्यांकन डोमेन का उपयोग किया जाता है।
साथ a:mail.example.com, एक मेल खाता पता डिफ़ॉल्ट + क्वालीफायर के अंतर्गत पारित हो सकता है। नंगे के साथ a example.com पर, example.com के पते प्रासंगिक हो जाते हैं। यदि वह नाम किसी वेबसाइट होस्ट या सीडीएन की ओर इशारा करता है, तो पूछें कि उन पतों को मूल्यांकन की गई पहचान के लिए मेल भेजने के लिए अधिकृत क्यों किया जाना चाहिए। शब्दार्थ प्रकट होते हैं RFC 7208 खंड 5.3.
एमएक्स वास्तव में क्या मूल्यांकन करता है
एमएक्स तंत्र अपने लक्ष्य डोमेन के लिए MX होस्ट और फिर उनके पते पुनर्प्राप्त करता है। यह कनेक्टिंग आईपी की तुलना उन हल किए गए पतों से करता है। MX रिकॉर्ड आमतौर पर इनबाउंड रूटिंग का वर्णन करते हैं, लेकिन जरूरी नहीं कि इनबाउंड सर्वर वही सिस्टम हों जो आउटबाउंड मेल भेजते हैं।
SPF एमएक्स SMTP के अंतर्निहित-एमएक्स फ़ॉलबैक का उपयोग नहीं करता है। यदि लक्ष्य के पास कोई MX रिकॉर्ड नहीं है, तो SPF अपने ए या एएएए रिकॉर्ड को फ़ॉलबैक MX होस्ट के रूप में नहीं मानना चाहिए। वह भेद स्पष्ट है RFC 7208 खंड 5.4.
कार्यान्वित उदाहरण: दो निर्भरताएँ, भिन्न अनुमतियाँ
एक वैध एकल SPF नीति, सफल DNS उत्तर, डिफ़ॉल्ट होस्ट उपसर्ग और कोई पूर्व मूल्यांकन त्रुटि नहीं मानते हुए, यह सिंथेटिक नीति है v=spf1 a:out.example.com mx:example.com -all. मान लें कि out.example.com A 192.0.2.40 का समाधान करता है। example.com का MX inbound.example.com है, जिसका एक अभिलिखित 198.51.100.12 है।
192.0.2.40 से एक कनेक्शन मेल खाता है। 198.51.100.12 से एक कनेक्शन छूट जाता है, फिर एमएक्स से मेल खाता है। 203.0.113.18 से एक कनेक्शन दोनों छूट जाता है और विफल हो जाता है। यदि इनबाउंड MX होस्ट बदलता है, तो SPF के बावजूद दूसरी अनुमति बदल सकती है TXT रिकॉर्ड एक समान रहता है.
IPv6 कनेक्शन के लिए, IPv4 ट्रेस का पुन: उपयोग करने के बजाय प्रासंगिक AAAA उत्तरों का निरीक्षण करें। यदि कोई लक्ष्य अनुपस्थित है या कोई लागू पता नहीं देता है, तो उस नो-मैच स्थिति को DNS त्रुटि से अलग करें; टाइमआउट इस बात का प्रमाण नहीं है कि इच्छित होस्ट अनधिकृत है।
लुकअप कार्य और द्वितीयक सीमाओं की समीक्षा करें
मूल्यांकन किए जाने पर दोनों तंत्र दस डीएनएस-क्वेरी-कारण-अवधि सीमा में योगदान करते हैं। MX विस्तार में अतिरिक्त पता-क्वेरी सीमाएँ भी परिभाषित हैं RFC 7208 §4.6.4. एक नीति उन सीमाओं को विफल कर सकती है, तब भी जब शीर्ष-स्तरीय शर्तों की सतही गिनती स्वीकार्य लगती है।
परीक्षण साक्ष्य में MX उत्तर सेट और उसके बाद के पते लुकअप को कैप्चर करें। दस को इस बात की गारंटी न मानें कि दस दृश्यमान शब्दों वाला प्रत्येक रिकॉर्ड सुरक्षित है। पुनरावर्ती निर्भरताएँ, विस्तार और शून्य लुकअप उनके स्वयं के मूल्यांकन की आवश्यकता है।
तय करें कि निर्भरता बनाए रखनी है या नहीं
जब डोमेन स्वामी जानबूझकर चाहता है कि DNS रिकॉर्ड भेजने की अनुमति को नियंत्रित करे और परिचालन टीमें युग्मन को समझें तो एक या एमएक्स रखें। स्थिर समर्पित निकास के लिए स्पष्ट आईपी4/आईपी6 तंत्र पर विचार करें, या जब प्रदाता आउटबाउंड बुनियादी ढांचे को बनाए रखता है तो प्रदाता-समर्थित शामिल करें।
किसी निर्भरता को हटाने से पहले, पहचानें कि वर्तमान में कौन से वैध पते उससे मेल खाते हैं। एक प्रतीत होता है कि अनावश्यक एमएक्स शायद ही कभी उपयोग किए जाने वाले रिले के लिए एकमात्र प्राधिकरण हो सकता है। प्रतिस्थापन बनाएं, अनुमति सेट की तुलना करें और पुराने शब्द को हटाने से पहले प्रतिनिधि संदेशों को सत्यापित करें।
व्यावहारिक उपाय
एक ए या एमएक्स तंत्र दूसरे DNS परिवर्तन को SPF अनुमति परिवर्तन में बदल देता है। उस रिश्ते को जानबूझकर, संबंधित स्वामियों के लिए दृश्यमान और परीक्षणों द्वारा कवर किया गया बनाएं।
निर्णय और उसकी सीमाएं रिकॉर्ड करें
out.example.com के लिए एक निर्भरता पंक्ति और प्रत्येक MX होस्ट के लिए दूसरी पंक्ति रखें: DNS स्वामी, पता परिवार, अवलोकन किया गया उत्तर और इसका उपयोग करने वाली वैध सेवा। इनबाउंड-प्रदाता माइग्रेशन को MX पंक्ति की समीक्षा को ट्रिगर करना चाहिए, भले ही TXT अपरिवर्तित हो। नमूना परिणाम विश्लेषणात्मक हैं; वास्तविक साक्ष्य में उत्तर टाइमस्टैम्प और टर्मिनल त्रुटियों के साथ-साथ मिलान भी शामिल होना चाहिए।