अपनी DMARC नीति को सख्त करने से पहले उन सभी सिस्टम का पता लगाएँ जो आपके डोमेन से वैध मेल भेजते हैं। रिपोर्ट से ऐसा प्रेषक सामने आ सकता है जिसके प्रमाणीकरण में बदलाव ज़रूरी है, इससे पहले कि नीति लागू होने पर उसका मेल ब्लॉक हो जाए।
आपको कौन-सी रिपोर्ट इस्तेमाल करनी चाहिए?
किसी रिपोर्टिंग अवधि में भेजने वाले स्रोतों और प्रमाणीकरण परिणामों की तुलना करने के लिए एग्रीगेट रिपोर्ट इस्तेमाल करें। आपके DMARC रिकॉर्ड का rua पता भाग लेने वाले प्राप्तकर्ता सर्वरों से ये XML सारांश माँगता है।
ruf पता अलग-अलग विफलता रिपोर्ट माँगता है, जिन्हें कभी-कभी फ़ोरेंसिक रिपोर्ट भी कहा जाता है। ये प्रमाणीकरण विफलता रिपोर्टिंग फ़ॉर्मेट का उपयोग करती हैं और इनमें हेडर या संदेश की सामग्री हो सकती है। यह सामग्री व्यक्तिगत जानकारी उजागर कर सकती है, इसलिए प्राप्तकर्ता सर्वर इन्हें संपादित कर सकते हैं या नहीं भेज सकते। RFC 7489 के रिपोर्टिंग नियम दोनों प्रकार की रिपोर्ट का वर्णन करते हैं।
एग्रीगेट रिपोर्ट में केवल वही ट्रैफ़िक होता है जो हर रिपोर्ट करने वाले प्राप्तकर्ता सर्वर ने देखा। किसी रिपोर्ट का न आना इस बात का सबूत नहीं है कि किसी संदेश ने आपके डोमेन का उपयोग नहीं किया। रिपोर्टिंग पते कहाँ सेट करें, यह DMARC रिकॉर्ड की व्याख्या में बताया गया है।
एग्रीगेट रिपोर्ट में क्या होता है?
एग्रीगेट रिपोर्ट रिपोर्ट करने वाले संगठन, रिपोर्टिंग अवधि और प्रकाशित नीति की पहचान करती है। इसके बाद रिकॉर्ड आते हैं, जो समान विशेषताओं वाले संदेशों को समूहित करते हैं। अगर प्रमाणीकरण परिणाम या समूहीकरण के अन्य फ़ील्ड अलग हों, तो एक ही स्रोत IP कई रिकॉर्ड में दिख सकता है।
इस उदाहरण अंश में वे फ़ील्ड रखे गए हैं जो किसी स्रोत की तुलना उसके प्रमाणीकरण परिणामों से करने के लिए ज़रूरी हैं:
<report_metadata>
<org_name>google.com</org_name>
<date_range><begin>1718323200</begin><end>1718409600</end></date_range>
</report_metadata>
<policy_published>
<domain>example.com</domain>
<p>none</p>
</policy_published>
<record>
<row>
<source_ip>203.0.113.10</source_ip>
<count>42</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>pass</spf>
</policy_evaluated>
</row>
<identifiers><header_from>example.com</header_from></identifiers>
<auth_results>
<dkim><domain>example.com</domain><result>pass</result></dkim>
<spf><domain>example.com</domain><result>pass</result></spf>
</auth_results>
</record>यह रिकॉर्ड 203.0.113.10 से आए 42 संदेशों को दर्शाता है, जिनके दिखाई देने वाले From पते में example.com है। दोनों प्रमाणीकरण तरीके पास हुए और संरेखित रहे। प्राप्तकर्ता सर्वर ने इन संदेशों पर कोई DMARC कार्रवाई लागू नहीं की; इससे यह तय नहीं होता कि वे इनबॉक्स में पहुँचे।
कौन-से फ़ील्ड ऑथेंटिकेशन की समस्या पहचानते हैं?
ऑथेंटिकेशन विफलता और डोमेन-अलाइनमेंट विफलता में अंतर करने के लिए policy_evaluated की तुलना auth_results से करें।
| फ़ील्ड | क्या जाँचें |
|---|---|
source_ip | भेजने वाले सर्वर और उसके लिए ज़िम्मेदार सेवा की पहचान करें। |
count | इस रिकॉर्ड में दर्शाए गए संदेश गिनें, पूरी रिपोर्ट के नहीं। |
header_from | प्राप्तकर्ता को दिखाए गए डोमेन की पुष्टि करें। |
disposition | जाँचें कि रिसीवर ने none, quarantine या reject में से क्या लागू किया। |
policy_evaluated में dkim और spf | जाँचें कि क्या हर तरीका DMARC के लिए पास और अलाइन हुआ। |
auth_results | कच्चे ऑथेंटिकेशन परिणामों और उनके द्वारा ऑथेंटिकेट किए गए डोमेन की तुलना करें। |
उदाहरण के लिए, जब SPF का ऑथेंटिकेट किया गया डोमेन From डोमेन से अलाइन नहीं होता, तो वह auth_results के तहत पास हो सकता है लेकिन policy_evaluated के तहत फ़ेल हो सकता है। अलाइन किया गया DKIM पास फिर भी उस संदेश को DMARC में पास करा सकता है। DMARC कैसे काम करता है इस संबंध को समझाता है।
हर भेजने वाले स्रोत के साथ आपको क्या करना चाहिए?
पॉलिसी बदलने से पहले हर स्रोत को किसी ऐसी सेवा से मिलाएँ जिसे आप अधिकृत करते हैं। केवल ऑथेंटिकेशन परिणामों से यह पता नहीं चलता कि आपके संगठन ने उस सेवा से भेजने का इरादा किया था या नहीं।
- जो ज्ञात प्रेषक पास और अलाइन होता है, उसके लिए पुष्टि करें कि उसकी रिपोर्ट की गई मात्रा आपके अपेक्षित ट्रैफ़िक से मेल खाती है।
- जो ज्ञात प्रेषक फ़ेल होता है, उसका ऑथेंटिकेशन या अलाइनमेंट ठीक करें और बाद की रिपोर्टों में परिणाम जाँचें।
- जो अज्ञात प्रेषक पास होता है, उसके लिए पता करें कि उसे किसने कॉन्फ़िगर किया और क्या उसका अधिकार बना रहना चाहिए।
- जो अज्ञात प्रेषक फ़ेल होता है, उसकी जाँच करें कि वह गलत कॉन्फ़िगर की गई वैध सेवा है या आपके डोमेन का अनधिकृत उपयोग।
मॉनिटरिंग से क्वारंटीन या अस्वीकृति पर जाने से पहले वैध विफलताओं को ठीक करें, क्योंकि अन्यथा वे संदेश प्रवर्तन के दायरे में आ सकते हैं। DMARC विफलताओं को ठीक करना आम कारणों को बताता है।
Bird भेजने वाले डोमेन की रिपोर्ट आप कैसे जाँचें?
आप अपने DMARC रिकॉर्ड में दिए गए rua पते के ज़रिए एग्रीगेट रिपोर्ट अपने मेलबॉक्स में मँगा सकते हैं। XML जाँचने के लिए DMARC रिपोर्ट एनालाइज़र का उपयोग करें, या रिपोर्ट को किसी टेक्स्ट एडिटर में खोलें।
Bird का DNS सत्यापन आपकी प्रकाशित नीति की जाँच करता है, जबकि रिसीवर की रिपोर्ट संदेशों के ऑथेंटिकेशन परिणाम बताती हैं। ये दोनों अलग-अलग जाँचें हैं। कौन-सी नीति और DNS रिकॉर्ड प्रकाशित करने हैं, यह ऑथेंटिकेशन गाइड में बताया गया है।