DMARC रिपोर्ट में प्रकाशित नीति बनाम मूल्यांकित नीति

एक रिपोर्ट अस्वीकृति की रिपोर्ट किए बिना प्रकाशित अस्वीकृति नीति दिखा सकती है। स्वभाव की व्याख्या करने से पहले रिपोर्टिंग प्रोफ़ाइल पढ़ें: वर्तमान RFC 9990 संदेश भेजने के लिए पास को परिभाषित करता है DMARC एक प्रवर्तन नीति के तहत, जबकि पुरानी रिपोर्टें पासिंग संदेश के लिए किसी का भी उपयोग नहीं कर सकती हैं। नीति संदर्भ, प्रमाणीकरण परिणाम और प्रबंधन निर्णय को विशिष्ट साक्ष्य के रूप में व्याख्या करें। किसी एक क्षेत्र के बजाय उनका संबंध बताता है कि किस चीज़ की जांच की आवश्यकता है।

पहले देखे गए कॉन्फ़िगरेशन को पढ़ें

पॉलिसी_प्रकाशित रिपोर्ट के पॉलिसी डोमेन के लिए रिसीवर द्वारा देखे गए पॉलिसी कॉन्फ़िगरेशन को रिकॉर्ड करता है। यह ऐतिहासिक रिपोर्टिंग साक्ष्य है, कोई ताज़ा DNS लुकअप नहीं। यदि आप आज DNS क्वेरी करते हैं, तो उस परिणाम और टाइमस्टैम्प को अलग रखें। रिपोर्ट किए गए अंतराल के दौरान या उसके बाद नीति बदल गई हो सकती है।

RFC 9990 एक अवधि के दौरान कॉन्फ़िगरेशन बदलने पर एकाधिक रिपोर्ट की अनुमति देता है; अन्यथा एक रिपोर्टर को अंतिम देखे गए कॉन्फ़िगरेशन को नोट करना चाहिए। इसलिए एक नीति स्नैपशॉट हमेशा प्रत्येक संदेश-समय की स्थिति की व्याख्या नहीं कर सकता है। किसी रिपोर्टर पर असंगतता का आरोप लगाने से पहले अंतराल बनाए रखें और इतिहास बदलें।

लेखक डोमेन और संरेखित पथों का मूल्यांकन करें

एक अभिलिखितहेडर_फ्रॉम लेखक डोमेन की आपूर्ति करता है। जब उपडोमेन किसी अन्य डोमेन की नीति पर निर्भर होते हैं तो यह नीति डोमेन से भिन्न हो सकता है। यह मानने के बजाय कि प्रत्येक पंक्ति अलगाव में शीर्ष-स्तरीय पी मान का उपयोग करती है, लागू नीति संबंध निर्धारित करें।

नीति_मूल्यांकन के तहत डीकिम और एसपीएफ़ मान डीएमएआरसी-संबंधित पहचानकर्ता मूल्यांकन का वर्णन करते हैं। वे auth_results के अंतर्गत कच्चे परिणामों से भिन्न हैं। एक गुजरता हुआ संरेखित पथ DMARC संतुष्ट कर सकता है; एक असंबंधित गुजर पहचान नहीं कर सकता. एक संदेश जो DMARC से गुजरता है, वह केवल इसलिए नीति-अस्वीकृति का उम्मीदवार नहीं है क्योंकि डोमेन प्रकाशित करता है p=reject.

ओवरराइड कारणों के साथ स्वभाव पढ़ें

उदाहरणात्मक वर्तमान-प्रोफ़ाइल केस एक: नीति_प्रकाशित p=reject, संरेखित दिखाता है DKIM पास और स्वभाव पास है, जैसा कि RFC 9990 परिशिष्ट ए में वर्णित है और परिशिष्ट बी में दर्शाया गया है। केस दो: दोनों संरेखित पथ विफल हो जाते हैं, लेकिन स्थानीय-नीति कारण के साथ स्वभाव कोई नहीं रहता है। रिपोर्ट एक रिसीवर ओवरराइड का वर्णन करती है, मरम्मत किए गए प्रमाणीकरण परिणाम का नहीं। विफलता और कारण को अलग-अलग रखें।

RFC 9990 एक कारण की आवश्यकता होती है जब संरेखण विफल रहता है और लागू नीति कॉन्फ़िगर की गई नीति से मेल नहीं खाती है। गुम या अप्रत्याशित जानकारी को मनगढ़ंत स्पष्टीकरण के साथ भरने के बजाय जांच के लिए चिह्नित किया जाना चाहिए। एक कारण स्ट्रिंग रिपोर्टर का स्पष्टीकरण है और अभी भी पुष्टि की आवश्यकता हो सकती है।

ये मामले सिंथेटिक हैं. न तो डिस्पोजल नन और न ही पासिंग ऑथेंटिकेशन रिजल्ट इनबॉक्स प्लेसमेंट को साबित करता है। अन्य फ़िल्टरिंग और वितरण निर्णय रिपोर्ट में वर्णित DMARC हैंडलिंग के बाहर मौजूद हो सकते हैं।

वास्तविक बेमेल की विधिपूर्वक जांच करें

अपने दिनांकित DNS परिवर्तनों और नियंत्रित संदेश साक्ष्य के साथ रिपोर्ट की अवधि, देखी गई नीति, लेखक डोमेन, संरेखण मोड और कच्चे पहचानकर्ताओं की तुलना करें। पुष्टि करें कि प्रेषक एक अधिकृत व्यावसायिक मार्ग है। यदि रिपोर्ट आंतरिक रूप से असंगत रहती है, तो XML को सुरक्षित रखें और अनिश्चितता को रिकॉर्ड करें।

केवल डैशबोर्ड के लेबल को सहमत बनाने के लिए डोमेन नीति को कमजोर न करें। सत्यापित प्रेषण दोष मौजूद होने पर उसे ठीक करें; अलग-अलग दस्तावेज़ रिसीवर ओवरराइड और रिपोर्टिंग सीमाएं। परिणाम एक ऐसी कथा होनी चाहिए जिसे कोई अन्य व्यवस्थापक उसी फ़ील्ड से पुन: प्रस्तुत कर सके।

दो स्पष्ट फ़ील्ड फिक्स्चर की तुलना करें

दोनों आंशिक सिंथेटिक मानचित्र वर्तमान RFC 9990 रिपोर्टिंग प्रोफ़ाइल और नीति डोमेन और हेडर_फ्रॉम brand.example , p=reject, शिथिल संरेखण और युग अंतराल 1704067200–1704153600 (1 जनवरी 2024 00:00 से 2 जनवरी 2024 00:00 यूटीसी) का उपयोग करते हैं। पहले में, count=25, कच्चा SPF vendor.example के लिए पास और brand.example /चयनकर्ता बिलिंग1 के लिए DKIM पास। गणना किए गए संरेखित परिणाम SPF विफल और DKIM पास हैं; DMARC पास हो गया। आपूर्ति किया गया स्वभाव वर्तमान RFC 9990 रिपोर्टिंग प्रोफ़ाइल के अंतर्गत पारित है।

दूसरे में, count=4 और दोनों कच्चे तंत्र vendor.example के लिए पास होते हैं DKIM चयनकर्ता v1. कोई भी पहचान संरेखित नहीं होती है, इसलिए परिकलित DMARC परिणाम विफल हो जाता है। प्रदत्त स्वभाव अभी भी कोई नहीं है, कारण प्रकार local_policy और स्पष्ट रूप से सिंथेटिक टिप्पणी "विश्वसनीय-फॉरवर्डर हैंडलिंग अपवाद" के साथ। वह कारण विफल संरेखण को बदले बिना काल्पनिक संचालन की व्याख्या करता है।

फ़ील्ड तुलनाएँ दोनों प्रमाणीकरण परिणामों की व्याख्या करती हैं; दूसरा उदाहरण स्पष्ट रूप से एक कारण प्रदान करता है। ये आंशिक फ़ील्ड मानचित्र पूर्ण XML या लाइव अवलोकन नहीं हैं। प्राप्तकर्ता का प्रबंधन निर्णय एक इनपुट है, न कि केवल प्रमाणीकरण से अनुमानित परिणाम।

अगली कार्रवाई चुनें

• संरेखित पास प्लस वर्तमान-प्रोफ़ाइल स्वभाव पास (या लीगेसी-प्रोफ़ाइल कोई नहीं): उस पासिंग संदेश के लिए कोई DMARC अस्वीकृति का अनुरोध नहीं किया गया है; यदि आवश्यक हो तो डिलीवरी की अलग से जाँच करें।
• दोनों संरेखित पथ विफल हो जाते हैं और कोई भी स्थिति नहीं होती है: ओवरराइड कारण का निरीक्षण करें और प्रमाणीकरण को पासिंग के रूप में पुनः लेबल करने के बजाय प्रेषक की पुष्टि करें।
• रिपोर्ट और वर्तमान DNS असहमत हैं: दिनांकित नीति-परिवर्तन इतिहास के साथ रिपोर्ट अंतराल की तुलना करें।
• आवश्यक कारण गुम है: रिपोर्ट को सुरक्षित रखें और एक अस्पष्ट बेमेल को चिह्नित करें। स्थानीय-नीति अपवाद का आविष्कार न करें।

वर्तमान और विरासती स्वभावों में अंतर करें

RFC 9990 परिशिष्ट ए डिस्पोजल पास को एक प्रवर्तन नीति के साथ DMARC पारित करने के लिए कोई कार्रवाई नहीं के रूप में परिभाषित करता है। कोई कार्रवाई नहीं होने के कारण यह किसी को बरकरार नहीं रखता है। पुराने RFC 7489 -प्रारूप रिपोर्ट में पासिंग डिस्पोजल की कमी होती है और पासिंग मैसेज के लिए कोई भी रिपोर्ट नहीं की जा सकती है। नेमस्पेस, रिपोर्टिंग प्रोफ़ाइल और संरेखित परिणामों को एक साथ जांचें: कोई भी सार्वभौमिक रूप से अमान्य नहीं है, लेकिन इसे वर्तमान-प्रोफ़ाइल पास उदाहरण के लिए चुपचाप खड़ा नहीं होना चाहिए। कोई भी मान इनबॉक्स प्लेसमेंट को साबित नहीं करता है।