जब वैध मेल DMARC में विफल होता है, तो कारण लगभग हमेशा कुछ अनुमानित बातों में से एक होता है: SPF या DKIM का गायब या गलत अलाइन परिणाम, SPF को तोड़ने वाली फ़ॉरवर्डिंग, या कोई थर्ड-पार्टी प्रेषक जिसे आपके डोमेन के लिए कभी प्रमाणित नहीं किया गया। समाधान शायद ही कभी अपनी पॉलिसी को ढीला करना होता है। समाधान है स्रोत को ढूँढना और उसे ठीक से प्रमाणित करना।
मुझे कैसे पता चले कि क्या विफल हो रहा है?
अपनी रिपोर्ट से शुरू करें, क्योंकि वे ठीक-ठीक बताती हैं कि कौन-सा स्रोत विफल हो रहा है और क्यों। आपकी एग्रीगेट रिपोर्ट मेल को भेजने वाले IP के अनुसार बाँटती हैं और हर IP के लिए SPF और DKIM परिणाम के साथ अलाइनमेंट दिखाती हैं। सबसे आम पैटर्न वह स्रोत है जो मूल जाँच में pass दिखाता है, लेकिन अलाइनमेंट के बाद fail दिखाता है, और यह सीधे समस्या की ओर इशारा करता है। अगर आप अभी इन्हें पढ़ने में सहज नहीं हैं, तो DMARC रिपोर्ट कैसे पढ़ें में सभी फ़ील्ड समझाए गए हैं।
जब आप देख लें कि कौन-सा स्रोत विफल हो रहा है, तो कारण लगभग हमेशा नीचे दिए गए कारणों में से एक होता है।
कारण 1: अलाइनमेंट में अंतर
यह सबसे आम कारण है। SPF या DKIM पास हो जाता है, लेकिन ऐसे डोमेन के लिए जो आपके दिखाई देने वाले From पते से मेल नहीं खाता, इसलिए DMARC इसे विफल मानता है। आमतौर पर इसका मतलब है कि कोई भेजने वाली सेवा आपके डोमेन के बजाय अपने डोमेन से प्रमाणीकरण करती है।
समाधान है सेवा को अलाइनमेंट में लाना। SPF के लिए इसका मतलब है आपके अपने डोमेन पर Return-Path (बाउंस डोमेन) के साथ भेजना। DKIM के लिए इसका मतलब है आपके डोमेन पर प्रकाशित कुंजी से साइन करना, ताकि साइन करने वाला डोमेन आपके From से मेल खाए। ज़्यादातर ईमेल प्लेटफ़ॉर्म ठीक इसी के लिए कस्टम डोमेन का समर्थन करते हैं: आप एक-दो CNAME प्रकाशित करते हैं और अलाइनमेंट अपने आप हो जाता है। यह अवधारणा DMARC कैसे काम करता है में समझाई गई है।
कारण 2: फ़ॉरवर्डिंग
फ़ॉरवर्डिंग चुपचाप SPF को तोड़ देती है। जब कोई संदेश फ़ॉरवर्ड होता है, तो फ़ॉरवर्ड करने वाला सर्वर उसे आगे भेजता है। वह सर्वर आपके SPF रिकॉर्ड में नहीं होता, इसलिए अंतिम गंतव्य पर SPF जाँच विफल हो जाती है। दूसरे लोगों के फ़ॉरवर्डिंग नियमों के बारे में आप ज़्यादा कुछ नहीं कर सकते।
राहत की बात यह है कि DKIM आमतौर पर फ़ॉरवर्डिंग के बाद भी बना रहता है, क्योंकि सिग्नेचर संदेश के साथ ही जाता है। इसी कारण DMARC तब पास होता है जब SPF या DKIM में से कोई एक पास हो: जब तक आपका DKIM सही और संरेखित है, तब तक फ़ॉरवर्ड किया गया मेल SPF विफल होने पर भी DMARC पास करता है। फ़ॉरवर्डिंग से होने वाली विफलताओं का व्यावहारिक समाधान यह है कि आप DKIM को सही ढंग से सेट और संरेखित करें। उसके बाद फ़ॉरवर्ड किए गए मेल के लिए SPF कॉलम पर ध्यान देने की ज़रूरत नहीं रहती।
कारण 3: कोई थर्ड-पार्टी प्रेषक जिसे आप भूल गए
लगभग हर संगठन जितनी सेवाएँ याद रखता है, उससे ज़्यादा सेवाओं के ज़रिए मेल भेजता है: CRM, हेल्प डेस्क, इनवॉइसिंग टूल, मार्केटिंग प्लेटफ़ॉर्म, सर्वे सेवा। इनमें से हर सेवा को आपके डोमेन के लिए प्रमाणित करना ज़रूरी है, वरना उसका मेल DMARC में विफल होता है। आपकी रिपोर्ट में दिखने वाले नए स्रोत आमतौर पर इन्हीं में से कोई होते हैं।
इन्हें एक-एक करके ठीक करें। हर वैध सेवा के लिए उसके निर्देशों के अनुसार अपने डोमेन पर SPF और DKIM सेट करें (इसे अक्सर "authenticate your domain" या "use a custom sending domain" कहा जाता है)। फिर अपनी अगली रिपोर्ट में पुष्टि करें कि वह स्रोत अब पास और संरेखित दिख रहा है। इन सेवाओं की एक सूची बनाए रखें, क्योंकि टीमें नए टूल अपनाती रहती हैं और यही हिस्सा सबसे जल्दी पुराना पड़ता है।
कारण 4: SPF बहुत व्यापक है या लुकअप सीमा से ऊपर है
SPF से जुड़ी दो आम गलतियाँ हैं। अगर आपका SPF रिकॉर्ड 10 DNS लुकअप से ज़्यादा का हो गया है (यह स्पेक में तय सख्त सीमा है), तो वह सीधे विफल हो सकता है और उसके साथ बाकी सही मेल भी विफल हो जाता है। वहीं, बहुत ढीला रिकॉर्ड ऐसे मेल को भी पास कर सकता है जिसे आप अधिकृत नहीं करना चाहते थे। अपने SPF रिकॉर्ड की जाँच करें, सीमा के करीब हों तो include: प्रविष्टियों को मिलाएँ, और जिन सेवाओं का अब उपयोग नहीं करते उन्हें हटा दें।
आपको क्या नहीं करना चाहिए
विफलताओं को ठीक करने के लिए अपनी नीति को वापस p=none पर कमज़ोर करके वहीं न छोड़ें। इससे रिपोर्ट की चेतावनियाँ तो बंद हो जाती हैं, लेकिन सुरक्षा भी बंद हो जाती है, और जिस स्पूफ़िंग को आप रोक रहे थे उसका रास्ता फिर खुल जाता है। किसी विफलता को पीछे हटने का कारण नहीं, बल्कि किसी स्रोत को प्रमाणित करने का संकेत मानें। ढील देने का सही तरीका यह है कि आप p= को एक स्तर पीछे करें और रिपोर्ट पढ़ते रहें। इसका विवरण DMARC नीति क्या है में है।
सब कुछ एक साथ
रिपोर्ट पढ़ें, विफल हो रहा स्रोत खोजें और तय करें कि वह वैध है या नहीं। फिर या तो उसे प्रमाणित करें या पहचानें कि वह स्पूफ़िंग है जिसे आप अब रोक रहे हैं। सूची पर तब तक काम करें जब तक हर असली प्रेषक पास और संरेखित न हो जाए, ताकि आपकी नीति सुरक्षित रूप से reject पर रह सके। अगर आप अभी सेटअप कर रहे हैं, तो DMARC कैसे सेट करें में बुनियादी चरण दिए गए हैं, और Bird की प्रमाणीकरण गाइड में डोमेन-विशिष्ट रिकॉर्ड हैं। ज़्यादातर विफलताएँ गंभीर दिखती हैं, लेकिन सही स्रोत पता चलने पर वे संरेखण का पाँच मिनट का समाधान निकलती हैं।