एक SPF आपके ग्राहक द्वारा देखे गए पते को प्रमाणित करने के लिए कुछ भी न करते हुए पास पूरी तरह से सही हो सकता है। भेजने वाला सर्वर किसी विक्रेता के लिफाफा डोमेन के लिए अधिकृत हो सकता है जबकि दृश्यमान सर्वर आपके व्यावसायिक डोमेन का उपयोग करता है। DMARC पूछता है कि क्या पासिंग प्रमाणीकरण पहचान उस लेखक डोमेन के साथ संरेखित है।
यह एक पहचान समस्या है, जरूरी नहीं कि यह गुम-आईपी समस्या हो। SPF अनुमतियाँ बढ़ाने से पहले वास्तविक प्राप्त संदेश में डोमेन से प्रारंभ करें।
तीन अलग-अलग अवलोकनों की तुलना करें
दृश्यमान फ्रॉम डोमेन, मूल्यांकन किए गए डोमेन SPF और प्रत्येक पासिंग में डोमेन को रिकॉर्ड करें DKIM हस्ताक्षर'एसडी = फ़ील्ड. प्रत्येक तंत्र के लिए रिसीवर के परिणाम को अलग से रिकॉर्ड करें। अनुमान मत लगाओ संरेखण हरे SPF से या DKIM बैज जो उस डोमेन को छुपाता है जिसका उसने मूल्यांकन किया था।
RFC 9989 अनुभाग 4.4.2 SPF संरेखण को परिभाषित करता है। सख्त संरेखण के लिए SPF और लेखक डोमेन का बिल्कुल मेल खाना आवश्यक है RFC 9989 §3.2.10.2. रिलैक्स्ड अलाइनमेंट संगठनात्मक-डोमेन खोज का उपयोग करता है RFC 9989 §4.10.2. यह किसी विक्रेता के स्वामित्व वाले किसी भी डोमेन की अनुमति नहीं देता जिसके साथ आपका अनुबंध है।
कार्यान्वित उदाहरण: बिना किसी संरेखण के एक सही पास
निम्नलिखित एक सिंथेटिक डायग्नोस्टिक फिक्स्चर है जो लागू DMARC नीति को मानता है। एक संदेश प्रेषक: accounts@example.com प्रदर्शित होता है। इसका मेल प्रेषक delivery@vendor.example.net है। कनेक्टिंग आईपी 192.0.2.17 है। विक्रेता लिफाफा नीति है v=spf1 ip4:192.0.2.17 -all, इसलिए SPF पास हो जाता है।
मान लें कि संगठनात्मक डोमेन example.com और example.net हैं। वे भिन्न हैं, इसलिए SPF पथ आराम या सख्त मोड में संरेखित नहीं होता है। यदि DKIM भी केवल d=vendor.example.net, तो कोई भी पासिंग पहचान संरेखित नहीं होती है। इसलिए DMARC पास गुजरने वाले संरेखित पथ का अभाव है RFC 9989 §5.3.5. उस आईपी को example.com में जोड़ रहा हूँ SPF रिकॉर्ड इस तथ्य को नहीं बदलता कि इस लेनदेन में vendor.example.net उपयोग किया गया था।
अब return@bounce.example.com के समर्थित कस्टम लिफाफे पर विचार करें। यदि SPF bounce.example.com के लिए पास हो जाता है और यह तथा example.com दोनों समान रूप से खोजे जाते हैं संगठनात्मक डोमेन, आराम से SPF संरेखण पारित हो सकता है। सख्त संरेखण अभी भी नहीं है क्योंकि नाम अलग-अलग हैं। वैकल्पिक रूप से, d=example.com के साथ एक पासिंग DKIM हस्ताक्षर एक संरेखित DKIM पथ प्रदान कर सकता है।
एक समर्थित सुधार चुनें
सेवा दस्तावेज़ या व्यवस्थापक से पूछें कि क्या यह डोमेन से कस्टम मेल, संरेखित DKIM , या दोनों का समर्थन करता है। सेवा से सटीक उत्पन्न DNS मान प्राप्त करें। एक सामान्य SPF शामिल एक कस्टम लिफाफे को स्वयं कॉन्फ़िगर नहीं करता है, और प्रदाता के रिटर्न पते को मैन्युअल रूप से तैयार करने से बाउंस हैंडलिंग बाधित हो सकती है।
वह सुधार चुनें जो वर्कफ़्लो और आपकी नीति के अनुकूल हो। एक संरेखित DKIM परिनियोजन अक्सर अग्रेषण के माध्यम से उपयोगी लचीलापन प्रदान करता है, हालांकि कवर की गई सामग्री में परिवर्तन के तहत हस्ताक्षर टूट सकते हैं RFC 6376 §3.7. यदि आप कस्टम MAIL FROM का उपयोग करते हैं, तो प्रदाता द्वारा सेटअप पूर्ण होने की रिपोर्ट के बाद वास्तविक लिफाफे का परीक्षण करें। उपयोग में आने वाले उत्पाद और खाते के लिए उत्पाद की उपलब्धता और कॉन्फ़िगरेशन चरणों को सत्यापित किया जाना चाहिए।
किसी चेतावनी को उसके द्वारा बनाई गई सीमा को समझे बिना हटाने के लिए संरेखण में ढील न दें। इसके विपरीत, यदि वैध उपडोमेन प्रेषकों को जानबूझकर आराम से संरेखण के लिए डिज़ाइन किया गया था, तो सुरक्षा के बैज के रूप में सख्त संरेखण का चयन न करें। दस्तावेज़ करें कि चुना गया पहचान संबंध स्वीकार्य क्यों है।
केवल DNS ही नहीं, पथ का पुनः परीक्षण करें
एक मेलबॉक्स पर एक प्रतिनिधि संदेश भेजें जहां आप विश्वसनीय रिसीवर परिणामों का निरीक्षण कर सकते हैं। अधिसूचना प्रकार का परीक्षण करें जो विफल रहा, क्योंकि प्रदाता के विपणन और लेनदेन संबंधी उत्पाद अलग-अलग पहचान का उपयोग कर सकते हैं। नया लिफ़ाफ़ा, SPF परिणाम, DKIM हस्ताक्षरित डोमेन और DMARC परिणाम कैप्चर करें।
यदि प्रत्यक्ष मेल काम करता है लेकिन अग्रेषित मेल नहीं करता है, तो उस मार्ग की अलग से जांच करें। DNS सुधार को केवल इसलिए असफल न कहें क्योंकि एक असंबंधित सामग्री फ़िल्टर अभी भी संदेश को स्पैम में रखता है। प्रमाणीकरण परिणाम और मेलबॉक्स प्लेसमेंट अलग-अलग परिणाम हैं।
व्यावहारिक उपाय
एक उपयोगी निदान पासिंग डोमेन को नाम देता है और दिखाता है कि यह संरेखित क्यों होता है या नहीं होता है। समर्थित भेजने वाली पहचान को सुधारें, फिर वास्तविक संदेश सत्यापित करें। गलत डोमेन पर व्यापक SPF अनुमतियाँ संरेखण अंतर को बंद नहीं कर सकती हैं।
निर्णय को प्रतिलिपि प्रस्तुत करने योग्य रखें
प्रत्येक गुजरने वाली पहचान और उसके संरेखण मोड में एक पंक्ति का उपयोग करें। From= example.com के लिए केवल vendor.example.net पास होने के साथ, एक परिणाम को दूसरे डोमेन में जोड़ने के बजाय दोनों कच्चे पासों को असंरेखित के रूप में चिह्नित करें। यदि d=example.com भी सत्यापित करता है, तो उस अलग संरेखित DKIM पथ को रिकॉर्ड करें। कस्टम मेल FROM व्यवहार का स्वतंत्र रूप से परीक्षण करें, भले ही समग्र DMARC पहले ही पास हो चुका हो।