DMARC रिपोर्ट असल में क्या है
rua= पते के साथ DMARC रिकॉर्ड प्रकाशित कीजिए और मेलबॉक्स प्रोवाइडर आपको
एग्रीगेट रिपोर्ट भेजने लगते हैं: हर प्रोवाइडर की ओर से रोज़ एक XML फ़ाइल, जिसमें हर
वह IP है जिसने आपके डोमेन के नाम से मेल भेजा, हर एक ने कितने संदेश भेजे, और SPF तथा DKIM पास हुए
और अलाइन थे या नहीं।
पहली फ़ाइल खोलने से पहले दो बातें जान लेना ठीक रहेगा:
- एग्रीगेट रिपोर्ट में संदेशों की सामग्री नहीं होती। न विषय, न प्राप्तकर्ता, न मूल पाठ। ये भेजने वाले IP के हिसाब से समूहित गिनतियाँ हैं। इसीलिए इन्हें इकट्ठा करना सुरक्षित है और इसीलिए ये नहीं बता सकतीं कि कौन सा संदेश फेल हुआ।
- ये फ़ोरेंसिक रिपोर्ट नहीं हैं।
ruf=पता हर संदेश के फेल होने के नमूने माँगता है, जिनमें हेडर और कभी-कभी उससे अधिक होता है। निजता के कारण ज़्यादातर प्रोवाइडर अब वे भेजते ही नहीं, इसलिए व्यवहार में DMARC की दृश्यता का मतलब एग्रीगेट रिपोर्ट ही है।
ये आपको वह एक चीज़ देती हैं जो और किसी तरह नहीं मिलती: दुनिया में हर उस चीज़ की सूची जो आपके डोमेन के नाम से ईमेल भेजती है, उन सिस्टमों समेत जो आपकी ही कंपनी में हैं और जिनकी सेटिंग किसी को याद नहीं। यही सूची पूरा मक़सद है, और यही नीति लागू करने की ओर सुरक्षित बढ़त को संभव बनाती है।
रिपोर्ट मिलनी कैसे शुरू करें
एक न्यूनतम रिकॉर्ड जो सिर्फ़ डेटा जमा करता है और डिलीवरी में कुछ नहीं बदलता:
v=DMARC1; p=none; rua=mailto:dmarc@example.com
यह _dmarc.example.com पर TXT रिकॉर्ड के रूप में जाता है। p=none का
मतलब है «कोई नीति मत लगाओ, बस बताओ» — यही सही शुरुआती बिंदु है और यह आपकी डिलीवरी को नुकसान नहीं
पहुँचा सकता। ऐसी रिपोर्ट का इंतज़ार करने से पहले, जो कभी आएँगी ही नहीं,
DNS लुकअप टूल से जाँच लें कि रिकॉर्ड
वाक़ई लाइव और पढ़ा जा सकने वाला है।
दो व्यावहारिक बातें। रिपोर्ट रोज़ और बहुत आती हैं, इसलिए उन्हें अपने नहीं, किसी अलग मेलबॉक्स पर भेजें। और अगर आप उन्हें किसी दूसरे डोमेन के पते पर चाहते हैं, तो उस डोमेन को अपने DNS रिकॉर्ड से इसकी इजाज़त देनी पड़ती है — यही अनुमति न होना सबसे आम वजह है कि रिपोर्ट चुपचाप कभी नहीं आतीं।
XML पढ़ना: तीन हिस्से
हर एग्रीगेट रिपोर्ट का ढाँचा एक जैसा है। एक बार देख लेने पर वह डराना बंद कर देता है।
हिस्सा 1: रिपोर्ट किसने भेजी
<report_metadata> रिपोर्ट करने वाली संस्था का नाम देता है, साथ में एक
पहचान संख्या और तारीख़ों की अवधि। ध्यान देने लायक अवधि ही है: रिपोर्ट आम तौर पर 24 घंटे की होती है
और एक-दो दिन बाद आती है, यानी जिस IP को आप देख रहे हैं उसने अतीत में भेजा था।
हिस्सा 2: उन्होंने जो नीति देखी
<policy_published> आपका अपना DMARC रिकॉर्ड है, जैसा उस प्रोवाइडर ने पढ़ा:
p (आपकी नीति), sp (सबडोमेन की), pct (जितना प्रतिशत लागू
करने को कहा) और अलाइनमेंट के तरीक़े। यह हिस्सा जाँच के काम आता है: अगर यह उससे मेल नहीं खाता जो आप
समझते हैं कि आपने प्रकाशित किया, तो रिकॉर्ड में सिंटैक्स की गड़बड़ी है या वह अभी फैला नहीं है।
हिस्सा 3: वे पंक्तियाँ जो मायने रखती हैं
फिर <record> तत्वों की एक शृंखला। हर एक एक ही IP से आए, एक ही नतीजे वाले
संदेशों का समूह है, कोई अकेला ईमेल नहीं। हर एक में स्रोत IP और गिनती के साथ
<row>, DMARC नतीजे और प्रोवाइडर ने असल में क्या किया यह बताने वाला
<policy_evaluated>, और नीचे के SPF तथा DKIM नतीजों वाला
<auth_results> होता है।
एक पंक्ति को व्यवहार में पढ़ना
इसी क्रम में चलिए और पंक्ति ख़ुद जवाब दे देगी:
- यह IP किसका है? देखिए। किसी जानी-पहचानी ईमेल प्लैटफ़ॉर्म का नाम मतलब यह आपकी ही सेवा है; अनजान नेटवर्क वही है जिसकी जाँच करनी है।
- कितने संदेश? दो संदेश शोर हैं। बीस हज़ार एक सिस्टम है।
<policy_evaluated><disposition>क्या कहता है?none,quarantineयाreject— प्रोवाइडर ने उसके साथ क्या किया।- SPF और DKIM पास हुए, और क्या वे अलाइन थे? यही जोड़ा पूरा निदान है, और वही अगला हिस्सा है।
चार संयोजन और हर एक का मतलब
DMARC तब पास होता है जब SPF या DKIM में से कोई एक पास हो और दिखने वाले From: डोमेन से अलाइन हो। इससे चार स्थितियाँ बनती हैं:
- SPF पास + DKIM पास। आपका ठीक से कॉन्फ़िगर किया भेजने वाला। कुछ नहीं करना।
- SPF पास, DKIM फेल। आम तौर पर कोई सेवा जो अधिकृत IP से बिना साइन किए भेज रही है। DKIM साइनिंग चालू कराएँ: अकेला SPF नाज़ुक है, क्योंकि संदेश फ़ॉरवर्ड होते ही टूट जाता है।
- SPF फेल, DKIM पास। अक्सर जायज़ फ़ॉरवर्ड हुई मेल: फ़ॉरवर्ड करने वाले का IP आपके SPF रिकॉर्ड में नहीं है, पर हस्ताक्षर बच गया। DMARC अकेले DKIM से पास हो जाता है — डिज़ाइन बिल्कुल यही है।
- दोनों फेल। या तो आपका कोई भेजने वाला जो कभी कॉन्फ़िगर ही नहीं हुआ, या कोई आपकी नक़ल कर रहा है। इन्हें अलग करना अगला हिस्सा है।
XML में एक जाल से सावधान रहें: कोई नतीजा <auth_results> में
pass दिखा सकता है और फिर भी DMARC फेल कर सकता है, क्योंकि प्रमाणित डोमेन From: डोमेन
से अलाइन नहीं था। अपने ही डोमेन से साइन करने वाली प्लैटफ़ॉर्म ठीक यही पैदा करती है। अगर यह
उलझा दे, तो SPF पास होना DMARC पास होना
क्यों नहीं है अलाइनमेंट को विस्तार से बताता है।
अपने भेजने वालों को स्पूफ़िंग से अलग करना
लगभग सबकी पहली रिपोर्ट डरावनी लगती हैं और उनमें से लगभग कुछ भी हमला नहीं होता। फेल होते IP को तीन ढेरों में बाँटिए:
- आपके ही, गलत कॉन्फ़िगर। कोई CRM, बिलिंग सिस्टम, टिकटिंग टूल, मार्केटिंग प्लैटफ़ॉर्म, ऐप्लिकेशन सर्वर। संकेत: IP किसी पहचाने जा सकने वाले प्रोवाइडर पर हल होता है, मात्रा दिन-ब-दिन स्थिर है, और संदेश डिलीवर हो रहे हैं। हल: उसे ठीक से अधिकृत करें, बेहतर हो DKIM के साथ।
- फ़ॉरवर्ड करने वाले। कम मात्रा, बिखरे IP, विश्वविद्यालय और छोटे मेल होस्ट, SPF फेल जबकि DKIM पास। यह समस्या नहीं है और आपकी तरफ़ से ठीक नहीं होती।
- असली स्पूफ़िंग। अनजान नेटवर्क, अक्सर झोंकों में, कई बार आपके कारोबार से बिल्कुल बाहर, दोनों जाँचों में फेल। तसल्ली की बात: नीति लागू होने पर यह मेल पहले ही ठुकराई जा रही है, और पूरा मक़सद यही है।
क्रम मायने रखता है। नीति सख़्त करने से पहले पहला पूरा ढेर पहचान लीजिए, क्योंकि नीति लागू होते ही आपका गलत कॉन्फ़िगर किया भेजने वाला बिना पहुँची मेल में बदल जाता है।
फ़ॉरवर्डिंग हमलावर जैसी क्यों दिखती है
यह हर किसी को एक बार उलझाता है। कोई मेलिंग लिस्ट या अलियास आपका संदेश अपने ही सर्वर से आगे भेजता है, इसलिए आपका SPF रिकॉर्ड ऐसे IP पर जाँचा जाता है जिसे आपने कभी अधिकृत नहीं किया, और फेल होता है — ठीक ही। रिपोर्ट में दिखता है कि एक अनजान IP आपके नाम से भेजते हुए SPF फेल कर रहा है, जो बिल्कुल दुरुपयोग जैसा पढ़ा जाता है।
दो निशानियाँ इन्हें अलग करती हैं। फ़ॉरवर्ड हुई मेल आम तौर पर DKIM पास करती रहती है, क्योंकि हस्ताक्षर संदेश के साथ चलता है, इसलिए कुल मिलाकर DMARC पास हो जाता है। और मात्रा कम होती है तथा बहुत से असंबद्ध IP में बँटी रहती है, एक जगह जमा नहीं। मेलिंग लिस्ट वह अपवाद हैं जो दोनों तोड़ सकती हैं: कुछ विषय बदल देती हैं या नीचे फ़ुटर जोड़ देती हैं, जिससे DKIM हस्ताक्षर अमान्य हो जाता है और एक जायज़ संदेश सब कुछ फेल करता दिखता है।
रिपोर्ट के सहारे नीति लागू करने तक पहुँचना
रिपोर्ट इसलिए हैं कि यह क़दम सुरक्षित हो सके। एक कारगर क्रम:
- जब तक रिपोर्ट उबाऊ न हो जाएँ,
p=noneपर रहिए — आम तौर पर कुछ हफ़्ते। आप इंतज़ार कर रहे हैं कि मिला हुआ हर जायज़ भेजने वाला अधिकृत हो जाए और नया कुछ न आए। - जैसे-जैसे मिलें, भेजने वालों को ठीक करते जाइए, DKIM को तरजीह देते हुए। DKIM वाला भेजने वाला फ़ॉरवर्डिंग से बच जाता है; सिर्फ़ SPF वाला नहीं।
p=quarantineपर जाइए, चाहें तो धीरे-धीरे बढ़ाने के लिएpct=के साथ। फेल होती मेल ग़ायब होने के बजाय स्पैम में जाती है, इसलिए गलती सुधारी जा सकती है।- फिर
p=reject, जब क्वारंटाइन शांत रह चुका हो। यही वह बिंदु है जहाँ आपके डोमेन की नक़ल करती मेल सचमुच ठुकराई जाती है। - उसके बाद भी रिपोर्ट पढ़ते रहिए। छह महीने बाद जुड़ने वाला कोई नया वेंडर फेल होते IP के रूप में दिखेगा, और आप उसे तब देखना चाहेंगे, इससे पहले कि कोई बताए कि उसके बिल बाउंस हो रहे हैं।
पहले ही दिन p=reject मत लगाइए। नीति लागू करने को सुरक्षित बनाने वाली इकलौती चीज़
रिपोर्ट से मिली सूची है, और उसे पूरा होने में हफ़्ते लगते हैं।
SPF, DKIM और DMARC की गाइड ख़ुद
रिकॉर्ड पर है।
आम गलतियाँ
- रिपोर्ट पढ़े बिना
p=rejectपर कूद जाना। भूला हुआ सिस्टम अक्सर वही होता है जो आपके ग्राहकों को बिल भेजता है। - हर पंक्ति को एक संदेश मान लेना। पंक्ति एक ही IP से आए, एक ही नतीजे वाले संदेशों का समूह है।
- हर फेल होते IP को हमलावर मानना। शुरुआती ज़्यादातर फेल आपकी अपनी सेवाएँ और आम फ़ॉरवर्डिंग होती हैं।
- यह मान लेना कि
auth_resultsमेंpassका मतलब DMARC पास है। दिखने वाले From: डोमेन से अलाइनमेंट के बिना ऐसा नहीं है। - रिपोर्ट किसी इंसान के मेलबॉक्स पर भेजना। वे दर्जनों प्रोवाइडर से रोज़ आती हैं। अलग पता इस्तेमाल करें।
- सबडोमेन नीति भूल जाना।
sp=के बिना सबडोमेनpको विरासत में लेते हैं, जो रोलआउट के दौरान शायद आपको न चाहिए हो। - सिर्फ़ SPF ठीक करना। SPF फ़ॉरवर्डिंग पर टूटता है; उसके पार DMARC को DKIM ही ले जाता है।
- reject तक पहुँचकर रिपोर्ट बंद कर देना। तभी तो वे शुरुआती चेतावनी की व्यवस्था बनती हैं।
संक्षेप में
DMARC एग्रीगेट रिपोर्ट आपके डोमेन के नाम से भेजने वाले हर IP की रोज़ाना XML सूची है, गिनतियों और
SPF/DKIM नतीजों के साथ — संदेशों की सामग्री के बिना। हर पंक्ति चार क़दमों में पढ़िए: IP पहचानिए,
मात्रा देखिए, disposition पढ़िए, फिर जाँचिए कि SPF या DKIM पास हुआ और अलाइन था या नहीं।
उम्मीद रखिए कि शुरुआती ज़्यादातर फेल आपकी ही बिना कॉन्फ़िगर सेवाएँ और आम फ़ॉरवर्डिंग होंगी, स्पूफ़िंग
नहीं; जहाँ हो सके भेजने वालों को DKIM के साथ ठीक कीजिए; और p=none से क्वारंटाइन और
फिर reject पर तभी जाइए जब रिपोर्ट शांत हो जाएँ। अपना _dmarc रिकॉर्ड प्रकाशित और
पढ़ा जा सकने वाला है या नहीं, यह मुफ़्त
DNS लुकअप टूल से जाँचें, और अगर रिपोर्ट
में कोई SPF नतीजा उलटा लगे तो
SPF जाँच गाइड उसकी वजह बताती है।
संबंधित टूल और गाइड:
- DNS लुकअप — मान और TTL के साथ A, AAAA, MX, TXT, NS और अधिक DNS रिकॉर्ड क्वेरी करें, साथ ही रिवर्स DNS।
- आपका SPF रिकॉर्ड बार-बार फेल क्यों होता है (और कैसे ठीक करें) — अपना SPF रिकॉर्ड कैसे पढ़ें
अक्सर पूछे जाने वाले सवाल
DMARC एग्रीगेट रिपोर्ट में क्या होता है?⌄
एक XML फ़ाइल, आम तौर पर एक मेलबॉक्स प्रोवाइडर की 24 घंटे की, जिसमें हर वह IP है जिसने आपके डोमेन के नाम से मेल भेजा, हर एक ने कितने संदेश भेजे, SPF और DKIM पास हुए तथा अलाइन थे या नहीं, और प्रोवाइडर ने क्या किया। इसमें संदेशों की सामग्री नहीं होती — न विषय, न प्राप्तकर्ता, न मूल पाठ।
DMARC रिपोर्ट मिलनी कैसे शुरू करूँ?⌄
_dmarc.आपकाडोमेन पर एक TXT रिकॉर्ड प्रकाशित करें जिसमें हो: v=DMARC1; p=none; rua=mailto: आपका पता। p=none कोई नीति लागू नहीं करता, इसलिए डिलीवरी पर असर नहीं डाल सकता। अलग मेलबॉक्स इस्तेमाल करें, क्योंकि रिपोर्ट रोज़ कई प्रोवाइडर से आती हैं, और ध्यान रखें कि दूसरे डोमेन के पते पर भेजने के लिए उस डोमेन को अपने DNS रिकॉर्ड से इजाज़त देनी होती है।
DMARC रिपोर्ट में अनजान IP क्यों दिखते हैं?⌄
आम तौर पर दो निर्दोष वजहों से: आपकी ही कोई सेवा जो कभी अधिकृत नहीं हुई — CRM, बिलिंग या टिकटिंग सिस्टम — या आम मेल फ़ॉरवर्डिंग, जहाँ फ़ॉरवर्ड करने वाला अपने IP से भेजता है और SPF फेल होता है जबकि DKIM पास रहता है। असली स्पूफ़िंग अक्सर झोंकों में, असंबद्ध नेटवर्कों से आती है और दोनों जाँचों में फेल होती है।
p=reject पर जाना कब सुरक्षित है?⌄
जब आपकी रिपोर्ट कुछ हफ़्तों से शांत हों: हर जायज़ भेजने वाला पहचाना और अधिकृत हो चुका हो, बेहतर हो DKIM के साथ, और नया कुछ न दिख रहा हो। पहले p=quarantine से गुज़रें, जहाँ फेल होती मेल ठुकराए जाने के बजाय स्पैम में जाती है, ताकि कोई भी गलती सुधारी जा सके।
किसी पंक्ति में SPF pass और DMARC fail क्यों दिखता है?⌄
क्योंकि DMARC प्रमाणीकरण के साथ अलाइनमेंट भी माँगता है: जिस डोमेन ने SPF पास किया वह दिखने वाले From: डोमेन से मेल खाना चाहिए। अपने रिटर्न पाथ से भेजने वाली प्लैटफ़ॉर्म अपने डोमेन पर SPF पास करती है, जो आपके डोमेन के लिए कुछ नहीं करता, इसलिए अलाइनमेंट जाँच फेल होती है और उसके साथ DMARC भी।
वेब डेवलपमेंट और सुरक्षा में 15+ वर्षों का व्यावहारिक अनुभव। व्यावहारिक वेब सुरक्षा पर ध्यान: वेबसाइटों को सुरक्षित, भरोसेमंद और समस्या-निवारण में आसान रखना। BuildToolForge इन जाँचों को मुफ़्त, निजी और समझने योग्य बनाने के लिए है। जहाँ संभव हो, टूल आपके ब्राउज़र में चलते हैं, और आप किसी टूल में जो कुछ भी दर्ज करते हैं वह संग्रहीत नहीं होता।
हम अपनी गाइड कैसे लिखते हैं: हर गाइड व्यावहारिक अनुभव से लिखी जाती है, आधिकारिक मानकों से जाँची जाती है और असली डोमेन पर हमारे अपने टूल से परखी जाती है। मानक या टूल बदलने पर हम गाइड अपडेट करते हैं। कोई गलती मिली? हमें contact@buildtoolforge.com पर ईमेल करें।