DMARC अलाइनमेंट क्या है, और SPF और DKIM पास होने पर भी DMARC क्यों फ़ेल होता है?

कोई प्रेषक अपने डोमेन पर नियंत्रण साबित कर सकता है, फिर भी From पते में आपका डोमेन दिखा सकता है। केवल सफल ऑथेंटिकेशन से यह साबित नहीं होता कि उसे उस दिखाई देने वाली पहचान का इस्तेमाल करने की अनुमति है।

SPF और DKIM पास होने पर भी DMARC क्यों फ़ेल हो सकता है?

दोनों जाँचें ऐसे डोमेन को प्रमाणित कर सकती हैं जो दिखने वाले From डोमेन से मेल नहीं खाते।

SPF यह जाँचता है कि कनेक्ट करने वाला सर्वर उस एनवेलप सेंडर डोमेन के लिए अधिकृत है या नहीं, जिसका उपयोग डिलीवरी विफलता की सूचनाओं के लिए होता है। DKIM एक साइनिंग डोमेन से जुड़े क्रिप्टोग्राफ़िक सिग्नेचर को सत्यापित करता है, और यह डोमेन सिग्नेचर के d टैग से पहचाना जाता है।

एनवेलप सेंडर SMTP बातचीत के दौरान दिया जाता है। यह उस From हेडर से अलग है जिसे प्राप्तकर्ता का मेल क्लाइंट दिखाता है।

उदाहरण के लिए, attacker.example को नियंत्रित करने वाला सेंडर उस डोमेन के लिए SPF और DKIM पास कर सकता है। वही सेंडर From में billing@example.com डाल सकता है। कोई भी परिणाम example.com को सत्यापित नहीं करता, इसलिए DMARC फ़ेल हो जाता है।

संगठनात्मक डोमेन वह प्रशासनिक सीमा है जिसमें एक डोमेन और उसके सबडोमेन आते हैं, जैसे news.example.com के लिए example.com।

किसे अलाइन माना जाता है?

रिलैक्स्ड अलाइनमेंट के लिए दोनों डोमेन का संगठनात्मक डोमेन एक होना चाहिए। स्ट्रिक्ट अलाइनमेंट के लिए दोनों डोमेन बिल्कुल एक जैसे होने चाहिए।

RFC 9989 बताता है कि प्राप्तकर्ता उस सीमा का पता कैसे लगाते हैं।

adkim टैग DKIM अलाइनमेंट को नियंत्रित करता है। aspf टैग SPF अलाइनमेंट को नियंत्रित करता है। दोनों टैग रिलैक्स्ड के लिए r या स्ट्रिक्ट के लिए s स्वीकार करते हैं, और डिफ़ॉल्ट रिलैक्स्ड है।

स्ट्रिक्ट अलाइनमेंट का उपयोग तभी करें जब आपको बिल्कुल एक जैसे डोमेन चाहिए, क्योंकि यह सहोदर सबडोमेन के बीच के अन्यथा मान्य मिलानों को बाहर कर देता है। foo.example.com के रूप में साइन करने वाली सेवा news.example.com वाले From के लिए स्ट्रिक्ट अलाइनमेंट पूरा नहीं कर सकती।

स्पेसिफ़िकेशन के अनुसार लगभग सभी डोमेन मालिकों के लिए रिलैक्स्ड अलाइनमेंट पर्याप्त होता है। रिलैक्स्ड अलाइनमेंट आपके लिए उपयुक्त है या नहीं, यह आपकी डोमेन-मिलान आवश्यकताओं पर निर्भर करता है।

क्या DMARC के लिए दोनों तरीकों का अलाइन होना ज़रूरी है?

नहीं: SPF या DKIM में से किसी एक का अलाइन पास पर्याप्त है।

प्राप्तकर्ता सर्वर दोनों तरीकों का मूल्यांकन अलग-अलग करता है। जो परिणाम पास तो है पर अलाइन नहीं है, उससे DMARC पास नहीं मिल सकता।

फ़ॉरवर्डिंग से कनेक्ट करने वाला सर्वर बदल जाता है, जिससे SPF विफल हो सकता है। अगर फ़ॉरवर्ड करने वाला साइन की गई सामग्री को जस का तस रखता है, तो DKIM बचा रह सकता है। तब अलाइन डोमेन का अक्षुण्ण सिग्नेचर SPF विफल होने के बावजूद संदेश को DMARC पास करा देता है।

अगर फ़ॉरवर्डिंग साइन की गई सामग्री बदल देती है, तो DKIM भी विफल हो सकता है। DMARC विफलताओं को कैसे ठीक करें में इसका निदान बताया गया है।

कोई सेंडिंग सेवा SPF अलाइनमेंट क्यों तोड़ सकती है?

जब सेवा ऐसा एनवेलप सेंडर डोमेन इस्तेमाल करती है जो आपके दिखने वाले From डोमेन से अलाइन नहीं होता, तब SPF अलाइनमेंट विफल होता है।

अगर सेवा अपना असंबंधित बाउंस डोमेन इस्तेमाल करती है, तो उस डोमेन के लिए SPF पास हो सकता है। DMARC उस परिणाम को अलाइन न होने के कारण अस्वीकार करता है। अपने डोमेन के SPF रिकॉर्ड में सेवा को जोड़ने से वह डोमेन नहीं बदलता जिसकी जाँच प्राप्तकर्ता सर्वर करता है।

अपने ही डोमेन के अंतर्गत एक कस्टम रिटर्न पाथ कॉन्फ़िगर करें, यानी वह डोमेन जिस पर डिलीवरी विफलता की सूचनाएँ जाती हैं। रिलैक्स्ड अलाइनमेंट में bounce.example.com का मिलान example.com वाले From से हो सकता है।

DKIM एक अलग रास्ता देता है: सेवा को किसी अलाइन डोमेन से साइन करने के लिए कॉन्फ़िगर करें। दोनों परिणामों की पुष्टि आप एग्रीगेट रिपोर्ट में कर सकते हैं, जिनमें प्राप्तकर्ता सर्वर की जाँचों का सारांश होता है।

Bird के साथ रिटर्न पाथ कैसे कॉन्फ़िगर करें?

आप Bird का रिटर्न-पाथ उपनाम अपने सेंडिंग डोमेन के अंतर्गत प्रकाशित करते हैं।

उस उपनाम को CNAME रिकॉर्ड के रूप में प्रकाशित करें। रिटर्न-पाथ उपनाम Bird का SPF सेटअप प्रदान करता है, इसलिए Bird से भेजे जाने वाले संदेशों के लिए आपको डोमेन रूट पर अलग SPF रिकॉर्ड की आवश्यकता नहीं होती।

API का return_path.name फ़ील्ड 1 से 63 अक्षर, अंक या हाइफ़न स्वीकार करता है, और दोनों सिरों पर अक्षर या अंक होना चाहिए। इससे लंबा लेबल या हाइफ़न से शुरू होने वाला लेबल अमान्य है।

Bird आपका भेजने वाला डोमेन जोड़ता है। उदाहरण के लिए, mail.example.com पर send, send.mail.example.com बन जाता है। वह रिटर्न पाथ relaxed मोड में mail.example.com वाले From के साथ संरेखित हो सकता है।

बाउंस-डोमेन गाइड में इस रिकॉर्ड की जानकारी है। आप DKIM रिकॉर्ड भी प्रकाशित करते हैं। Bird भेजने वाले डोमेन या उसके संगठनात्मक डोमेन, किसी पर भी मान्य DMARC नीति स्वीकार करता है। p=none जैसी निगरानी नीति पर्याप्त है, जो विफलताओं के लिए कोई प्रबंधन प्राथमिकता व्यक्त नहीं करती।

विनिर्देश संगठनात्मक डोमेन कैसे खोजता है?

RFC 9989 डोमेन पदानुक्रम में ऐसे रिकॉर्ड खोजता है जो लागू नीति और डोमेन की सीमा तय करते हैं। इस खोज को DNS tree walk कहा जाता है।

यह विनिर्देश RFC 7489 में वर्णित Public Suffix List वाले तरीके की जगह लेता है। वह सूची com और co.uk जैसे साझा पंजीकरण प्रत्ययों की पहचान करती है।

यह अंतर relaxed संरेखण को प्रभावित करता है, क्योंकि खोजा गया संगठनात्मक डोमेन तय करता है कि संबंधित नाम मेल खाते हैं या नहीं। यह इस बात को भी प्रभावित करता है कि किसी सबडोमेन पर कौन-सी पैरेंट नीति लागू होती है। प्रकाशित विनिर्देश से यह तय नहीं होता कि कोई विशेष प्राप्तकर्ता कौन-सा खोज तरीका लागू करता है।

क्या प्रतिशत टैग प्रवर्तन को नियंत्रित कर सकता है?

pct प्रतिशत टैग भरोसेमंद आंशिक प्रवर्तन नहीं देता। RFC 9989 इसे शामिल नहीं करता।

परिशिष्ट A.6 बताता है कि बीच के प्रतिशत मानों को असंगत तरीके से संभाला जाता था। इसलिए pct=50 सेटिंग से आप यह सुनिश्चित नहीं कर सकते कि सख्त प्रबंधन विफल होने वाले संदेशों में से ठीक आधे पर लागू होगा।

केवल शून्य और सौ के मान अपवाद थे, जिनका अर्थ क्रमशः प्रतिशत-आधारित प्रवर्तन न होना और पूर्ण प्रवर्तन था। कुछ मध्यस्थ pct=0 को आगे होने वाली विफलताओं से बचने के लिए दिखाई देने वाले From पते को बदलने का संकेत भी मानते थे।

none, quarantine और reject के ज़रिए नीति बदलने से पहले रिपोर्ट की मदद से वैध विफलताओं को ठीक करें। मान none विफलताओं के लिए कोई प्रबंधन प्राथमिकता नहीं बताता। मान quarantine विफलताओं को संदिग्ध के रूप में चिह्नित करता है। मान reject डोमेन के अनधिकृत उपयोग को दर्शाता है। नीति गाइड में चरणबद्ध रोलआउट समझाया गया है।

क्या संरेखित पास यह साबित करता है कि संदेश सुरक्षित है?

संरेखित पास From डोमेन के अधिकृत उपयोग को साबित करता है, लेकिन यह तय नहीं करता कि संदेश वांछित या सुरक्षित है।

प्राप्तकर्ता अपने फ़िल्टरिंग नियमों के आधार पर पास हुए संदेश को अस्वीकार या क्वारंटाइन कर सकता है। जब अन्य साक्ष्य डिलीवरी का समर्थन करें, तो वह विफल संदेश को स्वीकार भी कर सकता है।

डोमेन प्राधिकरण और प्रेषक प्रतिष्ठा, यानी प्रेषक के ट्रैफ़िक का प्राप्तकर्ता द्वारा किया गया आकलन, अलग-अलग सवालों के जवाब देते हैं। डिलीवरी की जाँच करते समय दोनों देखें।