DMARC में सीधे reject न चुनें—पहले वैध भेजने वालों की रिपोर्ट पढ़ें

DMARC नीति सुरक्षित ढंग से कड़ी करने के लिए पहले अपने डोमेन से मेल भेजने वाली सभी वैध सेवाएँ दर्ज करें। निगरानी नीति पर उनकी रिपोर्ट लें, SPF या DKIM अनुरूपता की विफलताएँ सुधारें और उसके बाद संगरोध तथा अस्वीकृति नीति अपनाएँ। DMARC.org का परिनियोजन क्रम भी प्रमाणीकरण और रिपोर्ट विश्लेषण को नीति कड़ी करने से पहले रखता है।

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

अपने डोमेन से भेजने वाली हर सेवा दर्ज करें

एक कार्यसूची में कर्मचारियों का मेल, वेबसाइट के फ़ॉर्म, ऑर्डर और भुगतान सूचनाएँ, ग्राहक सहायता, विपणन सेवा तथा स्वचालित संदेश शामिल करें। हर सेवा के सामने उसका जिम्मेदार व्यक्ति, प्राप्तकर्ता को दिखने वाला प्रेषक डोमेन, इस्तेमाल किया गया उपडोमेन और मेल भेजने की व्यवस्था लिखें। इससे रिपोर्ट में दिखने वाले स्रोत को किसी वास्तविक काम से जोड़ने का आधार मिलेगा।

केवल सूचना प्रौद्योगिकी दल की सेवाओं तक सूची सीमित न रखें। बिक्री, लेखा या सहायता दल अपनी अलग मेल सेवा इस्तेमाल कर सकते हैं। प्रत्येक दल से पूछें कि उसके नाम से कौन से नियमित और कभी-कभार भेजे जाने वाले संदेश निकलते हैं। रिपोर्ट में अपरिचित स्रोत दिखे तो पहले इस सूची, सेवा के व्यवस्थापक और भेजने के रिकॉर्ड से उसका मिलान करें; केवल अपरिचित पते के आधार पर उसे जालसाजी न मानें।

SPF और DKIM का पास होना ही पर्याप्त क्यों नहीं

DMARC प्राप्तकर्ता को दिखने वाले प्रेषक पते के डोमेन से प्रमाणित डोमेन का मिलान करता है। SPF में मेल भेजने के लिए अधिकृत डोमेन और DKIM में हस्ताक्षर करने वाला डोमेन देखना होता है। Microsoft की अनुरूपता व्याख्या के अनुसार DMARC सफल होने के लिए इनमें से कम से कम एक जाँच का सफल और अनुरूप होना पर्याप्त है।

बाहरी सेवा अपने डोमेन से मेल भेजने या हस्ताक्षर करने के कारण साधारण SPF अथवा DKIM जाँच में सफल दिख सकती है, जबकि प्राप्तकर्ता को आपके डोमेन का प्रेषक पता दिखे। इस स्थिति में दोनों प्रमाणित डोमेन आपके प्रेषक डोमेन से अलग हों तो DMARC विफल होगा। सेवा में अपने डोमेन से हस्ताक्षर करने या मेल भेजने वाले डोमेन को अनुकूलित करने की सुविधा देखें; बदलाव के बाद वास्तविक परीक्षण संदेश का प्रमाणीकरण परिणाम जाँचें।

अनुरूपता का सामान्य ढीला रूप एक ही संगठन के संबंधित उपडोमेन स्वीकार करता है, जबकि सख्त रूप में डोमेन का ठीक समान होना जरूरी है। इसलिए सख्त रूप चुनने से पहले हर वैध उपडोमेन का प्रभाव समझें। कार्यसूची में किसी सेवा को सुधार दिया है, यह लिखना पर्याप्त नहीं; अगली रिपोर्ट में उस सेवा के संदेशों का अनुरूप परिणाम भी दिखना चाहिए।

निगरानी नीति और रिपोर्ट पाने का पता लगाएँ

अपने डोमेन के _dmarc नाम पर DNS का TXT रिकॉर्ड प्रकाशित करें। उदाहरण के लिए, example.com का नमूना मान “v=DMARC1; p=none; rua=mailto:[email protected]” है; वास्तविक रिकॉर्ड में अपने नियंत्रण वाला चालू पता लगाएँ। यहाँ निगरानी नीति विफल संदेश पर DMARC की ओर से अतिरिक्त कार्रवाई नहीं माँगती और rua प्राप्तकर्ताओं से समेकित रिपोर्ट मँगाता है। रिकॉर्ड प्रकाशित करने के बाद DNS में उसका मान और रिपोर्ट वाले पते पर आने वाला मेल जाँचें।

रिपोर्ट पाने का पता सुरक्षित किए जा रहे डोमेन से अलग डोमेन पर हो तो बाहरी पते को रिपोर्ट स्वीकार करने की DNS अनुमति चाहिए हो सकती है। रिपोर्ट न मिले तो पहले प्रकाशित पता, उसका मेलबॉक्स और यह अनुमति जाँचें। निगरानी इतनी लंबी रखें कि कभी-कभार चलने वाले वैध मेल प्रवाह भी दिखाई दें; केवल शुरुआती दिनों में दिखे स्रोतों को पूरी सूची न मानें।

समेकित रिपोर्ट से वैध और अज्ञात स्रोत अलग करें

समेकित रिपोर्ट का RFC 9990 मानक स्रोत का पता, संदेशों की गिनती, लागू निर्णय और प्रमाणीकरण से जुड़े डोमेन तथा परिणाम दर्ज करता है। पहले रिपोर्ट की अवधि और सुरक्षित किए गए डोमेन की पहचान करें, फिर हर स्रोत को अपनी कार्यसूची से मिलाएँ। स्रोत का पता या अधिक संदेशों की गिनती अपने आप यह सिद्ध नहीं करती कि सेवा वैध है।

एक कामचलाऊ कार्यपत्रक में प्रत्येक स्रोत के लिए ये विवरण रखें:

• रिपोर्ट की अवधि, स्रोत का पता और संदेशों की गिनती;
• प्राप्तकर्ता को दिखने वाला प्रेषक डोमेन तथा SPF और DKIM से प्रमाणित डोमेन;
• प्रमाणीकरण और अनुरूपता के परिणाम, साथ में प्राप्तकर्ता का लागू निर्णय;
• मिलती हुई सेवा, उसका जिम्मेदार व्यक्ति और पहचान की पुष्टि या लंबित जाँच।

पहचानी गई वैध सेवा का मेल विफल हो तो उसके मेल भेजने वाले डोमेन या हस्ताक्षर की व्यवस्था सुधारें। फिर नया परीक्षण संदेश भेजकर उसके प्रमाणीकरण परिणाम को अगली रिपोर्ट से मिलाएँ। जिस स्रोत का स्वामी या भेजने का रिकॉर्ड नहीं मिलता, उसे अज्ञात रखें; उसे वैध सेवाओं की विफलताओं के साथ जोड़ देने से सुधार का काम अस्पष्ट हो जाएगा।

संगरोध के बाद अस्वीकृति नीति कब लागू करें

जब हर आवश्यक मेल सेवा पहचानी जा चुकी हो और उसके संदेश DMARC में सफल हों, निगरानी से संगरोध नीति पर जाएँ और रिपोर्ट मिलती रहने दें। Google की चरणबद्ध सलाह निगरानी के दौरान रिपोर्ट रोज देखने तथा समस्याएँ दूर होने पर नीति कड़ी करने को कहती है। संगरोध के बाद वैध स्रोतों की नई विफलताओं और संदेश न मिलने की शिकायतों की जाँच करें।

अस्वीकृति नीति से पहले आगे भेजे जाने वाले मेल और मेलिंग सूचियों में कर्मचारियों की भागीदारी भी देखें। RFC 9989 का वर्तमान DMARC मानक बताता है कि ऐसे अप्रत्यक्ष रास्तों पर वैध मेल प्रभावित हो सकता है और पुराने pct टैग को हटा दिया गया है। इसलिए प्रतिशत वाला टैग सुरक्षित परीक्षण की गारंटी मानने के बजाय इन मेल प्रवाहों के परिणाम जाँचें।

अस्वीकृति नीति तब लागू करें जब संगरोध के दौरान आवश्यक संदेशों की विफलताएँ सुलझ चुकी हों और अप्रत्यक्ष मेल का असर समझ लिया गया हो। बाद में कोई नई सेवा या उपडोमेन जुड़ने पर उसे भी कार्यसूची और समेकित रिपोर्ट से मिलाएँ।

यह भी पढ़ें:

• फ्रीलांस आय AIS में गलत दिखे—रिटर्न से पहले ऑनलाइन जवाब सुरक्षित करें
• भारत में घर से काम कानूनी अधिकार नहीं—आपसी सहमति की शर्त पहले पढ़ें
• विदेशी ग्राहक को बिल भेजने से पहले LUT भरें—IGST रोकने का सही क्रम