“SPF टूल में पास" और "प्राप्तकर्ता SPF विफलता की रिपोर्ट करता है" आवश्यक रूप से विरोधाभासी नहीं हैं। टूल में मान्य सिंटैक्स हो सकता है, एक अलग आईपी का परीक्षण किया जा सकता है या नए DNS की क्वेरी की जा सकती है। प्राप्तकर्ता ने एक विशेष SMTP कनेक्शन का मूल्यांकन किया। निदान उस कनेक्शन के पुनर्निर्माण से शुरू होता है, न कि यह मानकर कि कोई भी परिणाम गलत होना चाहिए।
पहचानें कि उपकरण वास्तव में क्या पारित हुआ
टूल के इनपुट और सटीक आउटपुट को सहेजें। एक वैध-रिकॉर्ड संकेतक किसी संदेश के लिए आवश्यक रूप से SPF पास नहीं है। यदि इसने मूल्यांकन किया है, तो आईपी पता रिकॉर्ड करें, लिफाफा भेजने वाला, HELO जहां प्रासंगिक और क्वेरी का समय है। अन्य टीमों को घटना की रिपोर्ट करते समय अंतर स्पष्ट रखें।
फिर गंतव्य के विश्वसनीय प्रमाणीकरण परिणाम या SMTP अस्वीकृति साक्ष्य एकत्र करें। किसी प्रेषक-आपूर्ति के साथ व्यवहार न करें Authentication-Results गंतव्य के फैसले के रूप में फ़ील्ड। RFC 8601 बताता है कि परिणामों को विश्वास सीमा की आवश्यकता क्यों है।
पहचान और संपर्क पते की तुलना करें
SPF प्रासंगिक SMTP पहचान के आधार पर कनेक्शन का मूल्यांकन करता है, न कि केवल दृश्यमान पते के आधार पर। RFC 7208 §2.3 और RFC 7208 §2.4 चेक से HELO और मेल का वर्णन करें। रिसीवर द्वारा देखे गए आईपी और मूल्यांकन किए गए डोमेन की तुलना टूल फिक्स्चर से करें।
एक उदाहरणात्मक मामला: एक एप्लिकेशन billing@example.com से प्रदर्शित होता है लेकिन प्रदाता के डोमेन के अंतर्गत एक लिफाफा पहचान का उपयोग करता है। example.com का टूल परीक्षण रिसीवर के वास्तविक SPF निर्णय के लिए अप्रासंगिक हो सकता है। दूसरे मामले में, एप्लिकेशन व्यवस्थापक की अपेक्षा से भिन्न रिले के माध्यम से निकलता है। प्राधिकरण का विस्तार करने से पहले मार्ग की समझ ठीक कर लें।
जैसा कि इसमें वर्णित है RFC 7208 §10.3, यदि कोई फारवर्डर शामिल है, तो अंतिम रिसीवर मूल भेजने वाले आईपी के बजाय फारवर्डर का कनेक्शन देख सकता है। प्रत्येक देखे गए फारवर्डर को मूल डोमेन के SPF में कंबल मरम्मत के रूप में न जोड़ें। इसके बजाय संपूर्ण अप्रत्यक्ष-मेल प्रवाह और अन्य प्रमाणीकरण परिणामों का आकलन करें।
प्रासंगिक समय पर DNS तुलना करें
वर्तमान लागू रिकॉर्ड और निर्भरताएँ पुनर्प्राप्त करें। प्राप्तकर्ता के घटना समय और किसी भी समसामयिक DNS साक्ष्य को सुरक्षित रखें। मरम्मत के बाद किया गया परीक्षण यह साबित नहीं कर सकता कि रिसीवर ने पहले क्या देखा था। इसी प्रकार, एक प्रदाता निर्भरता स्थानीय रिकॉर्ड संपादन के बिना बदल सकती है।
आधिकारिक प्रकाशन, पुनरावर्ती उत्तर और त्रुटि स्थितियों की जाँच करें। पुरानी कैश्ड पॉलिसी को गुम पॉलिसी या अस्थायी DNS त्रुटि से अलग करें। RFC 7208 अनुभाग 2.6 विभिन्न परिणाम श्रेणियों को परिभाषित करता है; पतन मत करो असफल, softfail , temperror और permerror एक निदान में.
वास्तविक पथ पुनः चलाएँ
प्रेक्षित इनपुट के साथ एक मानक-जागरूक मूल्यांकनकर्ता का उपयोग करें। मिलान किए गए तंत्र, क्वालीफायर, पुनरावर्ती निर्भरता और किसी भी सीमा या DNS त्रुटि का निरीक्षण करें। जहां ऐतिहासिक DNS अनुपलब्ध है, वहां रीप्ले को पिछली घटना के पुनर्निर्माण के बजाय वर्तमान स्थिति के परीक्षण के रूप में लेबल करें।
यदि प्रेषक दोनों का उपयोग कर सकता है तो दोनों पते परिवारों का परीक्षण करें। यह देखने के लिए कई प्रभावित और अप्रभावित नमूनों की तुलना करें कि क्या विफलता किसी मार्ग, क्षेत्र, आईपी परिवार या समय अंतराल का अनुसरण करती है। यह एक अनुशंसित निदान पद्धति है, यह दावा नहीं है कि कोई विशिष्ट प्रदाता किसी विशेष तरीके से ट्रैफ़िक वितरित करता है।
सबसे संकीर्ण समर्थित मरम्मत करें
पुष्टि की गई समस्या को ठीक करें: गलत लिफाफा कॉन्फ़िगरेशन, अनुपलब्ध अधिकृत दायरा, विकृत नीति, टूटी हुई निर्भरता या रूटिंग असंगतता। मूल स्थिति को सुरक्षित रखें और सामान्य परिवर्तन अनुमोदन प्राप्त करें। केवल एक अस्पष्ट नमूना पास करने के लिए नीति का विस्तार न करें।
मरम्मत के बाद, उसी एप्लिकेशन रूट के माध्यम से भेजें और एक नए विश्वसनीय रिसीवर परिणाम का निरीक्षण करें। जाँच करना DMARC अलग से, क्योंकि एक कच्चा SPF पास असंरेखित और एक संरेखित हो सकता है DKIM SPF विफल होने पर भी पास DMARC समर्थन कर सकता है। संरेखण निदान मार्गदर्शिका उस भेद को कवर करता है। घटना को पुराने और नए साक्ष्य के बीच अंतर के साथ बंद करें, न कि केवल एक और हरे चेकर स्क्रीनशॉट के साथ।
DNS पृष्ठभूमि: RFC 1035 अनुभाग 3.2.1 संसाधन-रिकॉर्ड टीटीएल को परिभाषित करता है; RFC 2308 §5 नकारात्मक उत्तरों को कैशिंग करना शामिल है। RFC 8767 §4 आधिकारिक रिफ्रेश विफल होने पर पुराने उपयोग की अनुमति देने के लिए टीटीएल शब्दार्थ को अद्यतन करता है। ये DNS व्यवहार का वर्णन करते हैं, परिवर्तन के लिए सार्वभौमिक समापन समय का नहीं।
एक ठोस निर्णय रिकॉर्ड का प्रयोग करें
काल्पनिक तुलना: एक चेकर आज example.com के विरुद्ध आईपी ए का मूल्यांकन करता है; कल के रिसीवर ने bounce.service.example.net .example.net के विरुद्ध आईपी बी का मूल्यांकन किया। वे अलग-अलग इनपुट सेट हैं। आईपी/डोमेन/टाइम ट्रिपल और प्रत्येक के लिए उपलब्ध DNS साक्ष्य दोनों को रिकॉर्ड करें। यदि ऐतिहासिक DNS गायब है, तो बताएं कि मूल परिणाम को पूरी तरह से दोबारा नहीं चलाया जा सकता है। केवल इन टिप्पणियों के आधार पर किसी भी उपकरण को दोषपूर्ण करार न दें। यहां कोई रीप्ले या DNS परीक्षण निष्पादित नहीं किया गया था।