read receipts
दस सेकंड में किसी कंपनी की DMARC पॉलिसी कैसे पढ़ें (और यह आपको क्या नहीं बताता)
जो लाइन डोमेन मालिक को नकली मेल के साथ क्या करना चाहता है, यह सार्वजनिक है और एक लुकअप दूर है। यह एक घोषित वरीयता है — स्पैम फ़िल्टर नहीं, और न ही आपके इनबॉक्स के बारे में कोई वादा।
एक DNS लुकअप आपको बताता है कि किसी कंपनी ने दुनिया के मेल सर्वरों से अपने नाम में भेजे गए नकली मेल के साथ क्या करने के लिए कहा है। रिकॉर्ड सार्वजनिक है, और कमांड एक लाइन है: dig +short TXT _dmarc.example.com। जो वापस आता है वह सेटिंग्स की एक छोटी स्ट्रिंग है, और इसके अंदर एक निर्देश है — p=none, p=quarantine या p=reject — जो डोमेन मालिक की वरीयता को बताता है जब एक संदेश उस डोमेन का उपयोग करते हुए प्रमाणीकरण में विफल होता है।
वर्तमान विशेषता, RFC 9989, मई 2026 में एक IETF मानक ट्रैक दस्तावेज़ के रूप में प्रकाशित, पुराने RFC 7489 को प्रतिस्थापित किया। यह तीन मानों को लगभग संक्षिप्त रूप से परिभाषित करता है:
p=none— "डोमेन मालिक कोई वरीयता व्यक्त नहीं करता है।"p=quarantine— "डोमेन मालिक इस तरह के मेल को संदिग्ध मानता है। यह संभव है कि मेल मान्य हो, हालांकि विफलता एक महत्वपूर्ण चिंता पैदा करती है।"p=reject— "डोमेन मालिक इस तरह की सभी विफलताओं को एक स्पष्ट संकेत मानता है कि डोमेन नाम का उपयोग मान्य नहीं है।"
उन शब्दों को फिर से पढ़ें, क्योंकि वे DMARC की अधिकांश व्याख्याओं की तुलना में कमजोर हैं। एक नीति एक वरीयता है, प्रेषक द्वारा प्रकाशित की गई है ताकि प्राप्तकर्ता इस पर विचार कर सकें। यह एक निर्देश नहीं है जिसे प्राप्तकर्ता को पालन करने के लिए बाध्य किया जाता है। RFC 9989 एक वाक्य में ऐसा कहता है: "किसी भी संदेश का अंतिम प्रबंधन हमेशा स्थानीय नीति का मामला है और मेल प्राप्तकर्ता के विवेक पर छोड़ा जाता है।" एक ही अनुभाग परिणाम के दोनों हिस्सों को जोड़ता है — प्राप्तकर्ता "एक संदेश को अस्वीकार या क्वारंटाइन करना पसंद कर सकता है भले ही वह DMARC सत्यापन जांच पास करे," और वे "केवल 'reject' की प्रकाशित नीति के कारण संदेशों को अस्वीकार नहीं करना चाहिए," ठीक इसलिए कि वैध मेल जो तरीकों से भेजे जाते हैं DMARC नहीं बता सकता, और मेलिंग सूचियां, प्रक्रिया में नष्ट न हों।
तो p=none वास्तव में क्या स्वीकार करता है? इससे कम कि इसके लिए आमतौर पर आरोप लगाया जाता है। विशेषता के अपने शब्दों में यह निगरानी मोड है: डोमेन मालिक समग्र रिपोर्ट एकत्र कर रहा है और "DMARC सत्यापन में विफल संदेशों के लिए कोई प्रबंधन वरीयता व्यक्त नहीं करता है," जबकि एक प्राप्तकर्ता जो DMARC तैनात करता है "अभी भी" डोमेन के उपयोग को सत्यापित कर सकता है। यह प्राप्त करने वाले के अंत में कुछ भी बंद नहीं करता है। आपके प्रदाता की स्पैम फ़िल्टरिंग, प्रतिष्ठा स्कोरिंग, URL जांच और संलग्न विश्लेषण अलग मशीनरी है जो भेजने वाले द्वारा प्रकाशित किए गए के बावजूद चलती है। p=none डोमेन में आने वाला एक नकली संदेश रिकॉर्ड द्वारा आपके इनबॉक्स को बढ़ावा नहीं दिया जाता है; इसे बस प्राप्तकर्ता को बिना किसी घोषित वरीयता के सौंपा जाता है, और प्राप्तकर्ता निर्णय लेता है।
गलतफहमी का दूसरा हिस्सा दूसरे तरीके से चलता है। DMARC एक फिशिंग ईमेल के खतरनाक हिस्से को नहीं पढ़ता है। इसकी अपनी विशेषता सूचीबद्ध करती है कि जानबूझकर क्षेत्र से बाहर क्या है, और "content analysis" उस सूची में है, उन शब्दों में। यह भी बताता है कि DMARC "दृष्टि से समान डोमेन नामों के उपयोग या RFC5322.From मानव-पठनीय प्रदर्शन नाम के दुरुपयोग को संबोधित नहीं करता है" — दो ट्रिक्स जो अधिकांश ब्रांड-प्रतिरूपण मेल ले जाती हैं। और पास की मूल्य पर: "एक DMARC पास अपने आप से यह गारंटी नहीं देता है कि प्राप्तकर्ता के इनबॉक्स में डिलीवरी सुरक्षित या वांछनीय होगी।" एक सही तरीके से प्रमाणीकृत संदेश एक डिस्पोजेबल डोमेन से DMARC को स्वच्छ रूप से पास करता है। DMARC उत्तर देता है कि किसको From: हेडर में डोमेन का उपयोग करने के लिए अधिकृत किया गया था। और कुछ नहीं।
यह वह जगह है जहां 2024 की बल्क-प्रेषक नियम नियमित रूप से गलत रिपोर्ट किए जाते हैं, इस लेख के पहले संस्करण में भी सहित। Google के प्रेषक दिशानिर्देश Gmail खातों के लिए 5,000 या अधिक संदेश प्रति दिन भेजने वाले प्रेषकों को "अपने भेजने वाले डोमेन के लिए DMARC ईमेल प्रमाणीकरण सेट करें" की आवश्यकता है, और फिर कहते हैं, एक ही सांस में: "आपकी DMARC प्रवर्तन नीति none के लिए सेट की जा सकती है।" Yahoo का अपना Sender Hub, जिसे अलग से पढ़ा जाना चाहिए बजाय Google की नकल मानने के, आवश्यकता को "कम से कम p=none - DMARC के साथ एक मान्य DMARC नीति प्रकाशित करें अवश्य पास करें" के रूप में बताता है, और कोई संख्यात्मक मात्रा थ्रेसहोल्ड प्रकाशित नहीं करता है। दोनों सेटिंग की आवश्यकताएं फरवरी 2024 से प्रभावी हुईं। कोई भी किसी को p=none से दूर जाने के लिए मजबूर नहीं करता है। दोनों वास्तव में जो मजबूर करते हैं वह प्रमाणीकरण है जो पंक्तिबद्ध है: Google की आवश्यकता है कि "प्रेषक के From: हेडर में डोमेन SPF डोमेन या DKIM डोमेन के साथ संरेखित होना चाहिए," और Yahoo कहते हैं कि आराम संरेखण स्वीकार्य है। संरेखण, गंभीरता नहीं, गेट है।
जो डोमेन को निगरानी में रखने का वास्तविक कारण छोड़ता है, और यह परिचालन के बजाय कायरतापूर्ण है। quarantine या reject पर जाने का मतलब है कि पहले हर सेवा को खोजना जो आपके नाम में मेल भेजता है — वेतन, टिकटिंग, विपणन, एक सहायता डेस्क जिसे कोई प्रलेखित नहीं किया — और संरेखित करने के लिए प्रत्येक को प्रमाणीकृत करना। मानक स्वयं खतरों को स्वीकार करता है जो इसे धीमा बनाते हैं: तीसरे पक्ष के प्रेषकों को न तो DMARC द्वारा परिचय दिया जाता है और न ही बाहर रखा जाता है, अग्रेषण और मेलिंग सूचियां प्रेषक की कोई गलती के बिना संरेखण को तोड़ सकती हैं, और विशेषता उन विफलता तरीकों के लिए RFC 7960 पर प्राप्तकर्ताओं को इंगित करती है। एक संगठन जो p=none प्रकाशित करता है और अपनी रिपोर्ट पढ़ता है विशेषता जो क्रम बताता है वह काम कर रहा है। एक जो p=none प्रकाशित करता है और रिपोर्ट को अनदेखा करता है वह नहीं है। बाहर से, रिकॉर्ड अकेले आपको यह नहीं बता सकता कि आप दो में से कौन सा देख रहे हैं।
आपको लुकअप के लिए टर्मिनल की आवश्यकता नहीं है। मुफ्त लुकअप उपकरण — dmarcian का डोमेन चेकर, MXToolbox की DMARC जांच — रिकॉर्ड प्राप्त करते हैं और नीति को आपके लिए प्रिंट करते हैं। यह अपने बैंक, अपने वेतन प्रदाता, एयरलाइन के लिए करें जिससे आप उड़ते हैं। बस उत्तर को इसके लिए पढ़ें: डोमेन के मालिक द्वारा एक इरादे का बयान, आपके मेल प्रदाता द्वारा अपने आप से किए गए निर्णय में कई इनपुट में से एक, एक विशिष्ट प्रकार की जालसाजी के बारे में। यह दस सेकंड में पढ़ने में एक वास्तविक उपयोगी चीज है। यह इस बारे में एक वर्डिक्ट नहीं है कि अगला संदेश जो उस ब्रांड से होने का दावा करता है वह सुरक्षित है या नहीं।
सुधार, 20 अक्टूबर 2026। इस लेख के एक पहले संस्करण ने p=none को जालसाजी को इनबॉक्स में पहुंचाने के रूप में वर्णित किया और p=reject को एकमात्र सेटिंग के रूप में जो एक स्पूफ़्ड संदेश को अवरुद्ध करता है, कहा कि 2024 की Google और Yahoo बल्क-प्रेषक नियमों ने p=none से प्रेषकों को दूर कर दिया, और लगभग एक तिहाई डोमेन का एक आंकड़ा प्रवर्तन पर उद्धृत किया। नीति विवरण RFC 9989 के विरुद्ध सुधारे गए हैं; Google और Yahoo दोनों वास्तव में p=none स्वीकार करते हैं, ऊपर अपने अपने प्रलेखन से उद्धृत किया गया है; और प्रवर्तन आंकड़ा हटाया गया है क्योंकि अंतर्निहित रिपोर्ट अपने नमूने या भाजक को प्रकाशित नहीं करती है। लेख अब यह भी बताता है कि DMARC क्या परीक्षा नहीं करता है।
स्रोत
- RFC 9989 — Domain-based Message Authentication, Reporting, and Conformance (DMARC) — IETF, Standards Track, May 2026; obsoletes RFC 7489. Policy values §4.7, Monitoring Mode §3.2.12, out-of-scope list §2.4, policy enforcement §5.4
- Google — Email sender guidelines — Requirements in force from 1 February 2024, including "Your DMARC enforcement policy can be set to none" and the 5,000-messages-a-day threshold (checked 20 October 2026)
- Yahoo Sender Hub — Best practices — Yahoo's own bulk-sender requirements: "Publish a valid DMARC policy with at least p=none"; no numeric volume threshold published (checked 20 October 2026)
- DMARC.org — Overview — Plain-language introduction to SPF, DKIM and identifier alignment
- dmarcian Domain Checker — Free lookup that fetches and reads a domain's DMARC record