Deliverability

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

DMARC alignment के लिए visible From डोमेन से मेल खाने वाले डोमेन की एक सफल SPF या DKIM जाँच ज़रूरी होती है, इसलिए असंबंधित डोमेन फ़ेल हो जाते हैं।

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

SPF और DKIM पास क्यों हो सकते हैं जबकि DMARC फ़ेल होता है?

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

SPF जाँचता है कि कनेक्ट करने वाला सर्वर उस envelope sender डोमेन के लिए अधिकृत है या नहीं, जो डिलीवरी-फ़ेलियर नोटिस के लिए उपयोग होता है। DKIM एक signing डोमेन से जुड़े क्रिप्टोग्राफ़िक signature को मान्य करता है, जिसे signature के d tag से पहचाना जाता है।

Envelope sender SMTP संवाद के दौरान दिया जाता है। यह प्राप्तकर्ता के मेल क्लाइंट में दिखने वाले From हेडर से अलग होता है।

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

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

Aligned कब माना जाता है?

Relaxed alignment के लिए साझा organizational डोमेन ज़रूरी है। Strict alignment के लिए डोमेन समान होने चाहिए।

RFC 9989 यह परिभाषित करता है कि रिसीवर उस सीमा को कैसे खोजते हैं।

प्रमाणित डोमेनFrom डोमेनAlignment
foo.example.comnews.example.comRelaxed, क्योंकि दोनों example.com साझा करते हैं
news.example.comnews.example.comStrict, क्योंकि डोमेन समान हैं
foo.example.netnews.example.comकोई नहीं, क्योंकि organizational डोमेन भिन्न हैं

adkim tag DKIM alignment को नियंत्रित करता है। aspf tag SPF alignment को नियंत्रित करता है। प्रत्येक relaxed के लिए r या strict के लिए s स्वीकार करता है, और relaxed डिफ़ॉल्ट है।

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

विनिर्देश बताता है कि लगभग सभी डोमेन मालिक relaxed alignment को पर्याप्त मानते हैं। आपकी डोमेन-मिलान आवश्यकताएँ तय करती हैं कि relaxed alignment उपयुक्त है या नहीं।

क्या DMARC को दोनों तरीकों का aligned होना ज़रूरी है?

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

रिसीवर दोनों तरीकों का स्वतंत्र रूप से मूल्यांकन करता है। पास लेकिन unaligned परिणाम DMARC pass प्रदान नहीं कर सकता।

फ़ॉरवर्डिंग कनेक्ट करने वाले सर्वर को बदलकर SPF तोड़ सकती है। DKIM बचा रह सकता है यदि फ़ॉरवर्डर signed कंटेंट को संरक्षित रखे। तब aligned डोमेन का एक intact signature SPF फ़ेलियर के बावजूद संदेश को DMARC पास करा देता है।

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

कोई भेजने वाली सेवा SPF alignment क्यों तोड़ सकती है?

SPF alignment तब फ़ेल होता है जब सेवा ऐसे envelope sender डोमेन का उपयोग करती है जो आपके visible From डोमेन से align नहीं होता।

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

अपने डोमेन के अंतर्गत एक कस्टम return path कॉन्फ़िगर करें, जो डिलीवरी-फ़ेलियर नोटिस के लिए उपयोग होने वाला डोमेन है। Relaxed alignment में bounce.example.com From example.com पर मेल खा सकता है।

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

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

आप अपने sending डोमेन के अंतर्गत Bird का return-path alias प्रकाशित करते हैं।

उस alias को CNAME रिकॉर्ड के रूप में प्रकाशित करें। Return-path alias Bird का SPF सेटअप प्रदान करता है, इसलिए Bird sends के लिए डोमेन रूट पर अलग SPF रिकॉर्ड की ज़रूरत नहीं है।

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

Bird आपके sending डोमेन को जोड़ देता है। उदाहरण के लिए, mail.example.com पर send बनकर send.mail.example.com हो जाता है। वह return path relaxed मोड में From mail.example.com पर align हो सकता है।

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

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

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

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

यह अंतर relaxed alignment को प्रभावित करता है क्योंकि खोजा गया organizational डोमेन यह तय करता है कि संबंधित नाम मेल खाते हैं या नहीं। यह इसे भी प्रभावित करता है कि किसी सबडोमेन पर कौन-सी parent policy लागू होती है। एक प्रकाशित विनिर्देश यह स्थापित नहीं करता कि कोई विशेष रिसीवर कौन-सी खोज विधि लागू करता है।

क्या percentage tag enforcement को नियंत्रित कर सकता है?

pct percentage tag विश्वसनीय आंशिक enforcement प्रदान नहीं करता। RFC 9989 इसे बाहर रखता है।

Appendix A.6 मध्यवर्ती प्रतिशतों की असंगत हैंडलिंग का वर्णन करता है। इसलिए pct=50 की सेटिंग आपको यह आश्वासन नहीं दे सकती कि सख़्त हैंडलिंग ठीक आधे फ़ेल होने वाले संदेशों को प्रभावित करती है।

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

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

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

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

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

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

संक्षेप में

  1. प्रमाणीकरण visible डोमेन से मेल खाना चाहिए।

    SPF और DKIM असंबंधित डोमेन के लिए पास हो सकते हैं, इसलिए DMARC को From में मौजूद डोमेन के लिए aligned pass चाहिए।

  2. कोई भी एक aligned तरीका pass दे सकता है।

    एक intact aligned DKIM signature फ़ॉरवर्डिंग से SPF टूटने पर भी DMARC pass बनाए रख सकता है।

  3. Relaxed और strict अलग-अलग मिलान नियम इस्तेमाल करते हैं।

    Relaxed alignment साझा organizational डोमेन स्वीकार करता है। Strict alignment के लिए डोमेन समान होने चाहिए।

  4. डोमेन खोज और enforcement अलग-अलग तंत्र हैं।

    RFC 9989 डोमेन सीमाएँ खोजने के लिए DNS tree walk का उपयोग करता है। यह अपने policy प्रारूप से अविश्वसनीय percentage tag को बाहर रखता है।

व्यवहार में लाएँ।

इस विषय के लिए डॉक्यूमेंटेशन, गाइड और उदाहरणों के साथ आगे बढ़ें। संसाधन अंग्रेज़ी में हैं।

इम्प्लीमेंटेशन ब्रीफ़ पाएँ

उसी नेटवर्क पर बनाएँ।

एक टेस्ट API key आपको तुरंत मिल जाती है। भुगतान विधि जोड़ने और सेंडर सत्यापित करने पर प्रोडक्शन अनलॉक होता है।

आपका अगला आइडिया।
जुड़ने के लिए तैयार।