DMARC रिपोर्ट कैसे पढ़ें: एक व्यावहारिक गाइड

डीएमएआरसी रिकॉर्ड प्रकाशित होने के 24-72 घंटों के भीतर, पहली समग्र रिपोर्ट आ जाती है, और यह तुरंत उन सभी वैध और अनधिकृत सर्वरों का खुलासा करती है जिन्होंने उस अवधि के दौरान आपके डोमेन के रूप में ईमेल भेजे थे। इसमें पेंच यह है, जैसा कि दस्तावेजित है डीएमएआरसी.ओआरजीप्रोटोकॉल विनिर्देश के अनुसार, ये रिपोर्टें मशीन-स्वरूपित XML फाइलें हैं जो स्वचालित पार्सर के लिए डिज़ाइन की गई हैं, न कि मानव पाठकों के लिए।

DMARC रिपोर्ट को पढ़ना जानने से वह कच्चा डेटा उपयोगी जानकारी में परिवर्तित हो जाता है। यह दृश्यता वास्तव में मूल्यवान है, लेकिन केवल XML को डिकोड करके कार्रवाई योग्य रूप में बदलने के बाद ही। ईमेल स्पैम के आँकड़े यह बताएं कि यह दृश्यता क्यों महत्वपूर्ण है: स्पूफिंग और प्रतिरूपण आम हैं, इसलिए आपको यह पहचानने के लिए DMARC रिपोर्ट की आवश्यकता है कि कौन से स्रोत आपके डोमेन के रूप में ईमेल भेज रहे हैं।

DMARC रिपोर्ट कैसे पढ़ें

पहली बार पढ़ने में 15-30 मिनट लगते हैं। एक बार पैटर्न समझ में आ जाने पर, उसी प्रेषक से आने वाले डेटा को पढ़ने में 2-3 मिनट लगते हैं। नीचे दिए गए चरण शुरू से अंत तक एक संपूर्ण DMARC एग्रीगेट रिपोर्ट तैयार करने की प्रक्रिया को दर्शाते हैं।

यहां एक अनाम XML स्निपेट दिया गया है जो नीचे दिए गए समीक्षा चरणों में उपयोग की जाने वाली रिपोर्ट संरचना को दर्शाता है:

<?xml version="1.0" encoding="UTF-8" ?>
<feedback>
  <report_metadata>
    <org_name>google.com</org_name>
    <email>[email protected]</email>
    <report_id>10296513920663916120</report_id>
    <date_range>
      <begin>1716768000</begin>
      <end>1716854400</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>yourdomain.com</domain>
    <adkim>r</adkim>
    <aspf>r</aspf>
    <p>none</p>
    <pct>100</pct>
  </policy_published>
  <record>
    <row>
      <source_ip>209.85.220.41</source_ip>
      <count>847</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
    <auth_results>
      <dkim>
        <domain>yourdomain.com</domain>
        <result>pass</result>
      </dkim>
      <spf>
        <domain>yourdomain.com</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
  <record>
    <row>
      <source_ip>198.51.100.23</source_ip>
      <count>312</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>fail</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <auth_results>
      <dkim>
        <domain>unknownsender.net</domain>
        <result>fail</result>
      </dkim>
      <spf>
        <domain>unknownsender.net</domain>
        <result>fail</result>
      </spf>
    </auth_results>
  </record>
</feedback>

चरण 1: रिपोर्ट प्राप्त करने के लिए एक इनबॉक्स या सेवा स्थापित करें

पुष्टि करें कि एक समर्पित इनबॉक्स आपके DMARC रिकॉर्ड के rua= टैग में निर्दिष्ट पते पर रिपोर्ट एकत्र कर रहा है (उदाहरण के लिए, [ईमेल संरक्षित]मेलबॉक्स प्रदाता प्रतिदिन समग्र रिपोर्ट भेजते हैं, इसलिए कम ट्रैफ़िक वाले डोमेन में भी प्रति माह दर्जनों XML फ़ाइलें जमा हो जाती हैं; इस प्रकार, एक सामान्य साझा इनबॉक्स जल्दी ही अनियंत्रित हो जाता है।

कभी-कभार समीक्षा की आवश्यकता वाले छोटे डोमेन के लिए, एक समर्पित मेलबॉक्स ठीक रहता है। प्रति सप्ताह कुछ रिपोर्टों से अधिक के लिए, या कई डोमेन का प्रबंधन करने वाले संगठनों के लिए, स्वचालित पार्सिंग के लिए rua= टैग को DMARC विश्लेषक के इनपुट पते पर इंगित करें।

चरण 2: XML फ़ाइल खोलें और उसे डीकंप्रेस करें

रिपोर्ट ईमेल से संलग्न फ़ाइल डाउनलोड करें। अधिकांश रिपोर्ट .xml.gz या .zip आर्काइव फ़ाइलों के रूप में आती हैं जिन्हें पहले डीकंप्रेस करना आवश्यक होता है (macOS और Linux पर, डबल-क्लिक करें या gunzip का उपयोग करें; Windows पर, राइट-क्लिक करें और एक्सट्रैक्ट करें)।

परिणामी .xml फ़ाइल को VS Code, Sublime Text या Notepad++ जैसे किसी भी टेक्स्ट एडिटर में खोलें। आप इसे ब्राउज़र में भी खोल सकते हैं, जिससे XML को समझना अक्सर आसान हो जाता है क्योंकि इसके खंड एक लंबे टेक्स्ट ब्लॉक के बजाय कोलैप्सेबल नोड्स के रूप में दिखाई देते हैं।

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

चरण 3: रिपोर्टिंग संगठन और नीति की पहचान करें

पता लगाएँ फ़ाइल के शीर्ष पर स्थित ब्लॉक में रिपोर्टिंग संगठन (Google, Microsoft, Yahoo, Mail.ru, या अन्य) और रिपोर्ट विंडो के प्रारंभ और समाप्ति के लिए Unix टाइमस्टैम्प दर्शाए गए हैं। इन टाइमस्टैम्प को पठनीय तिथियों में परिवर्तित करने से यह पुष्टि हो जाती है कि रिपोर्ट किस 24-घंटे की अवधि को कवर करती है।

पता लगाएँ इसके तुरंत बाद ब्लॉक करें। यह रिपोर्ट विंडो के दौरान सक्रिय DMARC नीति (p=none, p=quarantine, या p=reject) और SPF (aspf) और DKIM (adkim) दोनों के लिए संरेखण मोड दिखाता है। r का अर्थ है शिथिल संरेखण; s का अर्थ है सख्त संरेखण।

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

चरण 4: रिकॉर्ड अनुभाग में प्रत्येक प्रेषण स्रोत की समीक्षा करें

नीचे स्क्रॉल करें ब्लॉक। प्रत्येक रिकॉर्ड एक प्रेषक आईपी और उसके परिणामों को दर्शाता है, जिन्हें संदेशों की संख्या के आधार पर समूहीकृत किया गया है। ऊपर दिए गए उदाहरण में, 209.85.220.41 ने 847 संदेश भेजे और DMARC पास किया; 198.51.100.23 ने 312 संदेश भेजे और SPF और DKIM दोनों में विफल रहा।

प्रत्येक रिकॉर्ड के लिए, कैप्चर करें और आईपी ​​आईडी यह पहचान करती है कि किस सर्वर ने आपके डोमेन के रूप में संदेश भेजने का दावा किया, जबकि संख्या यह दर्शाती है कि रिपोर्ट विंडो के दौरान उस सर्वर से कितने संदेश आए।

प्रत्येक अपरिचित स्रोत आईपी पर रिवर्स डीएनएस लुकअप चलाएँ। वैध प्रेषक पहचानने योग्य होस्टनामों में परिवर्तित हो जाते हैं (जीमेल के लिए mail-sor-f41.google.com, सेंडग्रिड के लिए sendgrid.net और AWS SES के लिए amazonses.com)। अपरिचित आईपी को वैध मानने से पहले उनकी जांच करना आवश्यक है।

चरण 5: प्रत्येक प्रेषक के लिए SPF और DKIM संरेखण की जाँच करें

प्रत्येक रिकॉर्ड के अंदर, निम्नलिखित को खोजें: इस ब्लॉक में उस स्रोत आईपी के लिए एसपीएफ परिणाम और डीकेआईएम परिणाम, साथ ही प्रत्येक प्रमाणीकरण विधि द्वारा मूल्यांकित डोमेन शामिल हैं।

DMARC के लिए यह आवश्यक है कि SPF या DKIM में से कोई एक ही संरेखित मोड में पास हो ताकि पूरा संदेश DMARC पास कर सके। यह फ़ील्ड रिपोर्ट विंडो के दौरान सक्रिय नीति के आधार पर अंतिम निर्णय (कोई नहीं, क्वारंटाइन या अस्वीकार) दिखाता है।

ऐसे किसी भी रिकॉर्ड को चिह्नित करें जहां SPF और DKIM दोनों विफल दिख रहे हों, और स्रोत एक वैध प्रेषक होना चाहिए। यह एक गलत तरीके से कॉन्फ़िगर किया गया प्रेषक है जिसे नीति को सुरक्षित रूप से सख्त करने से पहले ठीक करने की आवश्यकता है। एक रिकॉर्ड जिसमें spf=fail लेकिन dkim=pass दिख रहा हो, आमतौर पर ठीक है, क्योंकि संदेश अभी भी DMARC से पास हो जाता है।

DMARC रिपोर्ट में प्रत्येक XML फ़ील्ड आपको क्या बताता है

DMARC एग्रीगेट रिपोर्ट RFC 7489 का पालन करती हैं। सभी अनुपालन करने वाली रिपोर्टें एक ही संरचना का उपयोग करती हैं, चाहे उन्हें किसी भी मेलबॉक्स प्रदाता ने भेजा हो। किसी भी रिपोर्ट की समीक्षा के दौरान इस फ़ील्ड संदर्भ का उपयोग करें:

• — रिपोर्टिंग संगठन (Google, Microsoft, Yahoo, आदि)। यह पुष्टि करता है कि किस मेलबॉक्स प्रदाता ने रिपोर्ट भेजी है। बड़े प्रदाता आमतौर पर प्रत्येक डोमेन के लिए अलग-अलग रिपोर्ट भेजते हैं।
• — रिपोर्ट में शामिल अवधि के प्रारंभ और समाप्ति के लिए यूनिक्स टाइमस्टैम्प दिए गए हैं। अधिकांश रिपोर्ट 24 घंटे की अवधि को कवर करती हैं, हालांकि कुछ प्रदाता कम अंतराल पर रिपोर्ट भेजते हैं।
• — निर्धारित समयावधि के दौरान सक्रिय DMARC नीति (p टैग) और SPF (aspf) तथा DKIM (adkim) के लिए संरेखण मोड। शिथिल संरेखण (r) उपडोमेन को संरेखण की शर्तों को पूरा करने की अनुमति देता है; सख्त संरेखण (s) के लिए सटीक मिलान आवश्यक है।
• — संदेश भेजने वाले का आईपी पता। भेजने वाली सेवा की पहचान करने के लिए इसे रिवर्स-डीएनएस करें।
• — रिपोर्ट अवधि के दौरान इस स्रोत आईपी से भेजे गए संदेशों की संख्या। अज्ञात आईपी से भेजे गए संदेशों की अधिक संख्या चिंता का विषय है।
• — डीएमआरसी का अंतिम निर्णय: कोई कार्रवाई नहीं की गई, क्वारंटाइन (स्पैम फोल्डर में डाला गया), या अस्वीकार (वापस भेज दिया गया)।
• स्रोत के लिए SPF और DKIM परिणाम। प्रत्येक में प्रमाणित डोमेन और उत्तीर्ण/अनुत्तीर्ण स्थिति दर्शाई गई है। प्रमाणित डोमेन और प्रेषक डोमेन के बीच संरेखण ही यह निर्धारित करता है कि DMARC समग्र रूप से उत्तीर्ण होता है या नहीं, न कि केवल SPF या DKIM का अलग-अलग उत्तीर्ण होना।

DMARC रिपोर्ट में क्या देखना चाहिए

एक बार जब आप इन चार पैटर्न को जान लेते हैं, तो DMARC रिपोर्ट को पढ़ना बहुत आसान हो जाता है। XML फ़ाइलों के ढेर को स्कैन करने के बजाय, आप प्रत्येक रिकॉर्ड को एक स्पष्ट श्रेणी में वर्गीकृत कर सकते हैं।

वैध प्रेषक जो dmarc=pass दिखा रहे हैं

यदि रिपोर्ट में dkim=pass और spf=pass दोनों के साथ आपका कोई ज्ञात प्रेषक, जैसे कि आपका ESP, मार्केटिंग प्लेटफ़ॉर्म, हेल्पडेस्क या CRM दिखाई देता है, तो इसका मतलब है कि उस स्रोत के लिए सेटअप सही ढंग से काम कर रहा है।

रिवर्स DNS के ज़रिए यह सत्यापित करें कि स्रोत IP अपेक्षित प्रदाता का है, विशेषकर अधिक संख्या में रिकॉर्ड होने पर। dmarc=pass वाले किसी ज्ञात IP से बड़ी मात्रा में ईमेल आने की संभावना है। एक बार इसकी पुष्टि कर लें, फिर इसे भविष्य की रिपोर्टों के लिए आधार मानें।

संदिग्ध स्रोत जिनमें संदेशों की संख्या अधिक हो

dmarc=fail के साथ सैकड़ों या हजारों संदेश भेजने वाले अपरिचित आईपी पते दो श्रेणियों में से एक में आते हैं: अनधिकृत प्रेषक जो सक्रिय रूप से आपके डोमेन की नकल कर रहे हैं, या एक भूला हुआ वैध प्रेषक (एक पुराना मार्केटिंग टूल, एक शैडो आईटी एकीकरण) जिसे कभी भी ठीक से प्रमाणित नहीं किया गया था।

आईपी ​​डब्ल्यूएचओआईएस और रिवर्स डीएनएस रिकॉर्ड की जांच करके छानबीन करें। एक ज्ञात स्पैम आईपी आमतौर पर स्पूफिंग की ओर इशारा करता है, जबकि एक अज्ञात एसएएएस प्लेटफॉर्म आमतौर पर प्रमाणीकरण समस्या की ओर संकेत करता है। इन दोनों मामलों में अलग-अलग प्रतिक्रियाओं की आवश्यकता होती है: स्पूफ किए गए मेल को ब्लॉक या अस्वीकार करें, लेकिन वैध प्रेषकों के लिए एसपीएफ या डीकेआईएम संरेखण को ठीक करें।

SPF विफल हो जाता है, लेकिन DKIM सफल हो जाता है: आमतौर पर फ़ॉरवर्डिंग

ऐसा संदेश जो SPF में विफल हो जाता है लेकिन DKIM में पास हो जाता है, अक्सर ईमेल फ़ॉरवर्डिंग की ओर इशारा करता है। फ़ॉरवर्डिंग सर्वर मूल प्रेषक के SPF रिकॉर्ड में सूचीबद्ध नहीं होता है, इसलिए SPF विफल हो जाता है। लेकिन DKIM अलग तरह से काम करता है। यह संदेश के हेडर पर हस्ताक्षर करता है, और ईमेल फ़ॉरवर्ड होने पर वह हस्ताक्षर अक्सर बरकरार रहता है। यही कारण है कि SPF के विफल होने पर भी DKIM पास हो सकता है।

जब भी SPF या DKIM में से कोई भी सही होता है, तो DMARC आमतौर पर सफल हो जाता है, इसलिए इन रिकॉर्ड्स में कोई समस्या नहीं है। जिन डोमेन में मेल फॉरवर्डिंग का उपयोग करने वाले प्राप्तकर्ता होते हैं, उनके लिए यह सामान्य व्यवहार है। यह रिपोर्ट दिखा रही है कि फॉरवर्डिंग प्रमाणीकरण को कैसे प्रभावित करती है, न कि DMARC सेटअप की विफलता को।

अज्ञात आईपी पतों से अचानक वॉल्यूम में वृद्धि: आमतौर पर यह स्पूफिंग होती है।

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

AbuseIPDB या Cisco Talos जैसे थ्रेट इंटेलिजेंस टूल में IP एड्रेस की जाँच करें। यदि IP एड्रेस स्पैम या दुरुपयोग से जुड़ा है, तो यह संकेत दुर्भावनापूर्ण हो सकता है। ऐसे में p=reject की ओर बढ़ना महत्वपूर्ण हो जाता है। एक बार सभी वैध प्रेषकों को ब्लॉक कर लेने के बाद, पूर्ण प्रवर्तन से नकली मेल को आपके व्यवसाय को नुकसान पहुँचाने से पहले ही ब्लॉक करने में मदद मिलती है। ईमेल प्रेषक की प्रतिष्ठा.

DMARC रिपोर्टों को पार्स करने और उनका विज़ुअलाइज़ेशन करने के उपकरण

अधिकांश टीमें रिपोर्ट प्राप्त होने के पहले सप्ताह के भीतर ही मैन्युअल XML समीक्षा से स्वचालित पार्सर पर स्विच कर जाती हैं। यह चुनाव मात्रा, बजट और विश्लेषण की गहराई पर निर्भर करता है।

शुरुआती टीमों के लिए, कभी-कभार मैन्युअल जाँच के लिए MXToolbox और निष्क्रिय निगरानी के लिए Postmark DMARC Digests एक व्यावहारिक और मुफ़्त संयोजन है। जब डोमेन की संख्या या दैनिक रिपोर्ट की मात्रा इतनी बढ़ जाए कि मैन्युअल समीक्षा अव्यावहारिक हो जाए, तो DMARCian जैसे समर्पित विश्लेषक का उपयोग करना शुरू कर दें।

रिपोर्ट से कार्रवाई तक: अपनी नीति को कब सख्त करें

DMARC रिपोर्ट पढ़ना तभी उपयोगी होता है जब आप उनका उपयोग निर्णय लेने के लिए करते हैं। प्रक्रिया सरल है: प्रत्येक प्रेषक की पहचान करें, संरेखण संबंधी समस्याओं को ठीक करें, और फिर प्रवर्तन की ओर बढ़ें।

• सूचीकरण चरण (सप्ताह 1-4, p=none पर): अपने डोमेन के रूप में संदेश भेजने वाले प्रत्येक वैध स्रोत की पहचान करें। यदि किसी स्रोत को संरेखण कार्य की आवश्यकता है, तो उसे पूरा करें। एसपीएफ, डीकेआईएम, और डीएमएआरसी प्रवर्तन की दिशा में आगे बढ़ने से पहले तैयारी करनी होगी।
• संरेखण चरण (सप्ताह 4-8, p=none पर): सुनिश्चित करें कि प्रत्येक वैध स्रोत SPF या DKIM का पालन करता है और 'प्रेषक' डोमेन के साथ संरेखित है। यदि कोई स्रोत SPF का पालन नहीं करता है, तो उसे SPF में जोड़कर, DKIM हस्ताक्षर सक्षम करके, या दोनों तरीकों से ठीक करें। प्रवर्तन कार्रवाई करने से पहले, यह सुनिश्चित करना आवश्यक है कि सभी वैध प्रेषकों के लिए कई लगातार रिपोर्ट चक्रों में 95% से अधिक की निरंतर पास दर हो।
• प्रवर्तन चरण (सप्ताह 8+ p=क्वारंटाइन पर, फिर p=अस्वीकार): जब रिपोर्टों से यह स्पष्ट हो जाए कि वैध प्रेषकों से कोई बड़ी विफलता नहीं आ रही है और संरेखण स्थिर है, तो p=quarantine पर जाएं। वहां 2-4 सप्ताह तक रहें और निगरानी जारी रखें। फिर p=reject पर जाएं। p=reject पर भी निगरानी बनाए रखें, क्योंकि स्टैक में जोड़े गए नए प्रेषक संरेखण संबंधी नई विफलताएं उत्पन्न कर सकते हैं।

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

DMARC डेटा को निर्णयों में परिवर्तित करना

DMARC एग्रीगेट रिपोर्ट ऑपरेशनल डेटा होती हैं। इनका उद्देश्य सैद्धांतिक जानकारी के लिए पढ़ना नहीं, बल्कि इनसे प्राप्त जानकारी के आधार पर कार्रवाई करना है। जिन वैध सेंडर्स का अलाइनमेंट सही नहीं बैठता, उन्हें ठीक करें। अपरिचित IP एड्रेस की जांच करें। जब आपके विश्वसनीय स्रोत लगातार सही तरीके से काम करने लगें, तब प्रवर्तन की दिशा में आगे बढ़ें।

लक्ष्य एक नीरस रिपोर्ट है: ज्ञात स्रोत, स्थिर सफलता दर, और अज्ञात आईपी से अचानक वॉल्यूम में कोई वृद्धि नहीं। यही पूर्वानुमानशीलता p=reject को सुरक्षित बनाती है, और यही p=reject आपके डोमेन को प्रतिरूपण से सुरक्षित रखता है।

अपने संरेखण चरण के हिस्से के रूप में, DeBounce के साथ अपनी प्रेषण सूचियों को सत्यापित करें। ईमेल सूची सत्यापन यह आपके प्रमाणित सेंडिंग स्ट्रीम में मौजूद सूचियों से अमान्य, अप्रचलित और उच्च जोखिम वाले पतों को हटा देता है, जिससे बाउंस रेट कम रहता है और प्रमाणीकरण के माध्यम से आप जो प्रतिष्ठा बना रहे हैं, वह सुरक्षित रहती है। अपनी सूची अपलोड करें, अनावश्यक पतों को हटा दें और इस विश्वास के साथ भेजें कि स्वच्छ प्रमाणीकरण और स्वच्छ डेटा एक साथ मिलकर काम कर रहे हैं।