Microsoft परिणाम के रूप में समग्र प्रमाणीकरण पढ़ें
माइक्रोसॉफ्ट का कंपाउथ फ़ील्ड दूसरी वर्तनी नहीं है DMARC. यह प्रमाणीकरण और अन्य संदेश संकेतों का उपयोग करके एक समग्र मूल्यांकन है, और इसकी व्याख्या माइक्रोसॉफ्ट के दस्तावेजी प्रसंस्करण से संबंधित है। इसलिए एक संदेश में हेडर के स्वाभाविक रूप से विरोधाभासी होने के बिना अलग-अलग दिखने वाले DMARC और समग्र परिणाम हो सकते हैं। परिणाम क्या स्थापित करता है, यह तय करने से पहले प्रत्येक क्षेत्र, उसके पहचान संदर्भ और संबंधित कारण कोड को पढ़ना सही कार्य है।
यह आलेख 8 नवंबर 2026 को बनाए गए Microsoft प्राथमिक दस्तावेज़ का उपयोग करता है। एंटी-स्पैम हेडर पृष्ठ 27 जुलाई 2026 अद्यतन की पहचान करता है। कोई मूल संदेश या किरायेदार ट्रेस प्रदान नहीं किया गया था, और नीचे दिया गया उदाहरण संशोधित हेडर के बजाय स्पष्ट रूप से काल्पनिक है। परिचालन निष्कर्ष जारी करने से पहले कैटलॉग को एक वास्तविक मूल-संदेश उदाहरण की आवश्यकता होती है।
पहचान को दृश्यमान रखें
Microsoft हेडर.from को दृश्यमान डोमेन से, smtp.mailfrom को लिफाफे के रूप में परिभाषित करता है मेल प्रेषक डोमेन, और हेडर.d के रूप में DKIM उपस्थित होने पर डोमेन पर हस्ताक्षर करना। ये फ़ील्ड अलग-अलग हो सकते हैं. परिणाम पढ़ते समय अपने रिश्ते को सुरक्षित रखें: a SPF एक डोमेन के लिए पास स्वचालित रूप से स्थापित नहीं होता है संरेखण दृश्यमान प्रेषक के साथ, और एक DKIM पास उसके द्वारा वर्णित हस्ताक्षर और डोमेन से संबद्ध होना चाहिए। माइक्रोसॉफ्ट प्रमाणीकरण हेडर फ़ील्ड
DMARC का प्रोटोकॉल निर्णय इसके नियमों के तहत दृश्यमान डोमेन के साथ संरेखण से संबंधित है। Microsoft समग्र प्रमाणीकरण SPF , DKIM , DMARC और अन्य जानकारी को संयोजित करते समय उस डोमेन को आधार के रूप में उपयोग करता है। अनुपालन विवरण या DNS समस्या निवारण निष्कर्ष में अलग DMARC परिणाम को कॉम्पॉथ से न बदलें। वे संबंधित लेकिन गैर-समान प्रश्नों का उत्तर देते हैं। RFC 9989 माइक्रोसॉफ्ट मिश्रित फ़ील्ड
परिणाम और कारण की एक साथ व्याख्या करें
Microsoft दस्तावेज़ कंपाउथ मान पास, फेल, सॉफ्टपास और कोई नहीं, तीन अंकों के कारण के साथ। पूरी जोड़ी रखो. कारण कोड एक SMTP उत्तर कोड नहीं है, भले ही उसके अंक किसी अन्य डायग्नोस्टिक से मिलते जुलते हों। सामान्य SMTP तालिका का उपयोग करके reason=130 डिकोड न करें या एक संदेश के मूल्य से किरायेदार-व्यापी स्थिति का अनुमान न लगाएं। देखे गए संदर्भ के लिए वर्तमान Microsoft तालिका का उपयोग करें। माइक्रोसॉफ्ट समग्र प्रमाणीकरण
हेडर संदर्भ कारण 000 को DMARC विफलता और संगरोध या अस्वीकार नीति के साथ स्पष्ट प्रमाणीकरण विफलता के रूप में वर्णित करता है, जबकि 001 दस्तावेज में कमजोर या अनुपस्थित-नीति परिस्थितियों में अंतर्निहित प्रमाणीकरण विफलता की चिंता करता है। यह 109 को ऐसे मामले के रूप में वर्णित करता है जहां नहीं DMARC रिकॉर्ड मौजूद है लेकिन संदेश अन्यथा पारित हो जाएगा। ये स्कोप्ड वेंडर परिभाषाएँ हैं, हेडर बनाने के निर्देश या सबूत नहीं कि ऐसा संदेश यहाँ देखा गया था। माइक्रोसॉफ्ट कारण कोड
किसी प्रकाशित पॉलिसी पर दावा किए बिना bestguesspass को समझें
माइक्रोसॉफ्ट के dmarc=bestguesspass लेबल का अर्थ है कि कोई DMARC नहीं TXT रिकॉर्ड मौजूद है लेकिन यदि डोमेन में कोई होगा तो संदेश पास हो जाएगा। इसे प्रमाण के रूप में रिपोर्ट नहीं किया जाना चाहिए कि डोमेन ने एक वैध DMARC नीति प्रकाशित की है या वास्तविक मानक DMARC मूल्यांकन पास हो गया है। विक्रेता लेबल को शब्दशः सुरक्षित रखें और उसका सीमित अर्थ समझाएँ। Microsoft DMARC फ़ील्ड मान
ऐसे परिणाम की समीक्षा करने वाले प्रेषक को अभी भी वास्तविक सार्वजनिक नीति और इच्छित प्रमाणीकरण कॉन्फ़िगरेशन को सत्यापित करना चाहिए। यह न मानें कि समग्र सफलता स्पष्ट डोमेन नीति की आवश्यकता को हटा देती है या गारंटी देती है कि अन्य प्राप्तकर्ता भी समान मूल्यांकन करेंगे। एक रिसीवर-विशिष्ट अनुमान या अनुमान डोमेन के प्रकाशित नियंत्रणों के लिए पोर्टेबल प्रतिस्थापन नहीं है।
ARC और अंतर्निहित संकेत अंतर्निहित तथ्यों को दोबारा नहीं लिखते हैं
Microsoft दस्तावेज़ कारण 130 को विश्वसनीय मानते हैं ARC सीलर का परिणाम DMARC विफलता को ओवरराइड करता है। यह अग्रेषित या मध्यस्थ पथ में एक समग्र परिणाम की व्याख्या कर सकता है, लेकिन इसका मतलब यह नहीं है कि अंतर्निहित DMARC विफलता को साक्ष्य रिकॉर्ड से मिटा दिया जाना चाहिए। मूल परिणाम, ARC संदर्भ, कारण और अंतिम प्रबंधन को अलग रखें। यह दावा न करें कि कोई भी मनमाना ARC हेडर पर्याप्त है; प्रलेखित मामला एक विश्वसनीय मुहर लगाने वाले से संबंधित है। माइक्रोसॉफ्ट कारण 130
इसी तरह, माइक्रोसॉफ्ट अन्य अंतर्निहित संकेतों का वर्णन करता है और नोट करता है कि समग्र विफलता के परिणामस्वरूप सीधे अवरोधन नहीं होता है। समग्र मूल्यांकन उस विफलता के बावजूद एक संदेश की अनुमति दे सकता है, जबकि अन्य सुरक्षा प्रौद्योगिकियां प्रमाणित मेल में जोखिम की पहचान कर सकती हैं। नतीजतन, compauth=pass इनबॉक्स प्लेसमेंट या सामग्री सुरक्षा की गारंटी नहीं है, और compauth=fail अपने आप में अस्वीकृति का प्रमाण नहीं है। माइक्रोसॉफ्ट हैंडलिंग स्पष्टीकरण
हेडर ट्रस्ट सीमा स्थापित करें
संबंधित रिसीवर से एक अधिकृत मूल संदेश प्राप्त करें और पहचानें कि किस विश्वसनीय सिस्टम ने परिणाम तैयार किए हैं। RFC 8601 इसका कारण बताता है Authentication-Results दावों के लिए एक विश्वास सीमा की आवश्यकता होती है। एक संदेश पथ के साथ एकाधिक शीर्षलेख दिखाई दे सकते हैं, और एक अविश्वसनीय प्रेषक वह पाठ सम्मिलित कर सकता है जो आधिकारिक दिखता है। उत्पत्ति का पता लगाए बिना वांछित निष्कर्ष से सबसे अच्छी तरह मेल खाने वाली किसी भी घटना का चयन न करें। RFC 8601
आंतरिक सत्यापन के लिए एक अछूता मूल और एक अलग संशोधित व्याख्यात्मक प्रति रखें। पते या हस्ताक्षरित सामग्री बदलने से स्वतंत्र क्रिप्टोग्राफ़िक पुनर्वैधीकरण को रोका जा सकता है, इसलिए कॉपी को तदनुसार लेबल करें। एक एनोटेशन चर्चा के लिए पहचान संबंधों को संरक्षित कर सकता है, लेकिन यह एक नया सत्यापन योग्य मूल संदेश नहीं है। यदि प्राप्तकर्ता को मजबूत साक्ष्य की आवश्यकता है, तो चुपचाप प्रकटीकरण का विस्तार करने के बजाय अनुमोदित सुरक्षित हस्तांतरण प्रक्रिया का उपयोग करें।
मूल समग्र-परिणाम वर्कशीट
निम्नलिखित प्रस्तावित वर्कशीट फ़ील्ड व्याख्या को प्रतिलिपि प्रस्तुत करने योग्य बनाती है। इसमें कोई वास्तविक संदेश नहीं है और इसे पूर्ण प्रमाणीकरण विश्लेषण नहीं माना जाना चाहिए।
- साक्ष्य उत्पत्ति: प्राप्त-संदेश संदर्भ, रिसीवर, टाइमस्टैम्प और विश्वसनीय सत्यापनकर्ता।
- दृश्यमान पहचान: हेडर.फ्रॉम और व्यवसाय प्रेषक से इसका संबंध।
- SPF : सटीक परिणाम, smtp.mailfrom और प्रेक्षित स्रोत संदर्भ।
- DKIM : प्रत्येक प्रासंगिक हस्ताक्षर और संबंधित हेडर के लिए परिणाम।डी।
- DMARC : सटीक विक्रेता फ़ील्ड मान और अलग से सत्यापित नीति संदर्भ।
- समग्र: कम्पाउथ मान, तीन अंकों का कारण और उद्धृत माइक्रोसॉफ्ट परिभाषा।
- मध्यस्थता: अग्रेषण, विश्वसनीय ARC या वास्तव में उपलब्ध अन्य मार्ग साक्ष्य।
- परिणाम: अवलोकन किया गया संचालन, असमर्थित निष्कर्ष और अगले साक्ष्य की आवश्यकता।
सिंथेटिक ऑल-पास रिकॉर्ड बनाने के लिए विभिन्न संदेशों के परिणामों को संयोजित न करें। एक सफल प्रत्यक्ष-डिलीवरी नमूना और एक अग्रेषित विफलता नमूना एक मार्ग अंतर प्रकट कर सकता है, लेकिन प्रत्येक को अपनी पहचान और टाइमस्टैम्प की आवश्यकता होती है। जब कोई फ़ील्ड या मूल संदेश अनुपलब्ध हो तो अज्ञात को सुरक्षित रखें।
काल्पनिक उदाहरण: अनुमानित सफलता को गलती से नीति परिनियोजन समझ लिया जाता है
काल्पनिक सीब्राइट डेस्क एक काल्पनिक रिपोर्ट देखता है जिसमें dmarc=bestguesspass और compauth=pass reason=109. प्रस्तावित समीक्षा बताती है कि प्रलेखित अर्थ प्रकाशित DMARC रिकॉर्ड स्थापित नहीं करता है। मेल स्वामी अभी भी वास्तविक नीति का निरीक्षण करेगा और केवल समग्र परिणाम से डोमेन को पूर्ण चिह्नित करने के बजाय इच्छित तैनाती की पुष्टि करेगा।
इस कार्य में कोई सीब्राइट डेस्क हेडर, DNS उत्तर या टैनेंट परिणाम मौजूद नहीं है। मानों का उपयोग केवल Microsoft की दस्तावेज़ीकृत व्याख्या को दर्शाने के लिए किया जाता है, मनगढ़ंत सत्यापन साक्ष्य के रूप में नहीं। वास्तविक विश्लेषण के लिए मूल संदेश और विश्वसनीय स्रोत संदर्भ की आवश्यकता होती है।
कैटलॉग को वर्तमान Microsoft फ़ील्ड परिभाषाओं और एक संशोधित मूल-संदेश उदाहरण की आवश्यकता है। परिभाषाएँ स्रोत-आधारित हैं, लेकिन मूल-संदेश साक्ष्य अनुपस्थित है। मूल साक्ष्य, मानव एसएमई, स्रोत प्रयोज्यता, उत्पादन मार्ग, दृश्य पहुंच और मालिक की रिहाई खुली रहती है। यह मसौदा एक व्याख्या मार्गदर्शिका है, सत्यापित किरायेदार मूल्यांकन नहीं।