[ निदान एवं संसाधन ]

ईमेल प्रमाणीकरण मानक और स्रोत लाइब्रेरी

एक क्यूरेटेड प्राथमिक-स्रोत लाइब्रेरी प्रोटोकॉल नियमों, पैरामीटर पंजीकरण, प्रदाता दायित्वों और देखे गए कार्यान्वयन को अलग करती है। प्रत्येक प्रविष्टि उस प्रश्न की पहचान करती है जिसका उत्तर उसका स्रोत दे सकता है।

EmailAuth अनुसंधान टीम द्वारा · 6 मिनट पढ़ा

[ प्रमुख बिंदु ]

  • RFC 9989 वर्तमान कोर DMARC को कवर करता है; आरएफसी 9990 और 9991 विभिन्न रिपोर्ट प्रकारों को कवर करते हैं।
  • आधार हस्ताक्षर विनिर्देश के साथ-साथ DKIM एल्गोरिदम अपडेट का उपयोग करें।
  • IANA सक्रिय और ऐतिहासिक स्थिति उत्पाद-संगतता प्रमाणपत्र नहीं है।
  • प्रकाशन तिथियाँ, प्रदाता प्रवर्तन तिथियाँ और स्थानीय स्वीकृति अलग-अलग रिकॉर्ड हैं।
इस पेज पर

अधिकार और प्रश्न से प्रारंभ करें

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

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

DMARC कोर RFC 9989

RFC 9989 मई 2026 कोर है DMARC विशिष्टता, प्रमाणित पहचानकर्ताओं को कवर करते हुए, संरेखण, नीति खोज और मूल्यांकन-नीति शब्दार्थ। इसका आरएफसी संपादक सूचना रिकॉर्ड इसे प्रस्तावित मानक के रूप में पहचानता है; दस्तावेज़ मानक ट्रैक है और अप्रचलित आरएफसी 7489 और 9091 है। विरासत कार्यान्वयन अंतरों का अलग से परीक्षण करते हुए, वर्तमान मूल नियमों के लिए इसका उपयोग करें। नीति संस्करण DMARC1 ही रहता है, नए RFC नंबर से आविष्कृत संस्करण नहीं।

समग्र रिपोर्टिंग RFC 9990

RFC 9990 अलग मई 2026 समग्र-रिपोर्टिंग विनिर्देश है। आरएफसी संपादक रिकॉर्ड प्रस्तावित मानक स्थिति की पहचान करता है। यह रिपोर्ट संरचना, प्रसंस्करण, बाहरी गंतव्यों, डुप्लिकेट और गोपनीयता/सुरक्षा संबंधी विचारों को संबोधित करता है। इसे रिपोर्ट पार्सर की स्वीकृति के मामलों का समर्थन करना चाहिए, इसे सबूत के रूप में नहीं माना जाना चाहिए कि प्रत्येक रिसीवर पूरी रिपोर्ट भेजता है या डैशबोर्ड का कुल योग सही है।

विफलता रिपोर्टिंग RFC 9991

RFC 9991 मई 2026 मानक ट्रैक विफलता-रिपोर्टिंग विनिर्देश है, RFC 6591 अद्यतन करता है और प्रतिस्थापन में अन्य दो दस्तावेजों के साथ भाग लेता है RFC 7489. इसका फोकस संदेश-विशिष्ट निदान, रिपोर्टिंग प्रारूप, बाहरी गंतव्य और गोपनीयता है। इस समीक्षा के दौरान पढ़ा गया अलग सूचना-पृष्ठ दर-सीमित था; सफलतापूर्वक पढ़ा गया RFC पाठ बताई गई श्रेणी का समर्थन करता है। भ्रमित न करें विफलता रिपोर्ट समग्र आँकड़ों के साथ या मान लें कि आरयूएफ प्रकाशित करने से रिपोर्ट की गारंटी मिलती है।

SPF RFC 7208

RFC 7208, स्टैंडर्ड ट्रैक पर अप्रैल 2014 में प्रकाशित, परिभाषित करता है SPF पहचान, नीति रिकॉर्ड चयन, मूल्यांकन और परिणाम प्रबंधन। यह समझाने के लिए प्राथमिक प्रारंभिक बिंदु है permerror या DNS-क्वेरी-शब्द सीमा। अनुमत आईपी पतों की सूची में SPF कम करने या प्रत्येक DNS ऑपरेशन को समान रूप से मानने के बजाय प्रासंगिक अनुभाग और उसकी निर्भरताएँ पढ़ें।

DKIM RFC 6376 और एल्गोरिथम अपडेट

RFC 6376, स्टैंडर्ड ट्रैक पर सितंबर 2011 में प्रकाशित, परिभाषित करता है DKIM हस्ताक्षर, चयनकर्ता, कुंजियाँ और सत्यापन। इसके क्रिप्टोग्राफ़िक प्रावधानों को पढ़ें RFC 8301, जनवरी 2018, और RFC 8463, सितंबर 2018। पूर्व RSA-SHA1 को प्रतिबंधित करता है और RSA प्रमुख आवश्यकताओं को मजबूत करता है; उत्तरार्द्ध परिभाषित करता है Ed25519 उपयोग। प्रत्येक मूल एल्गोरिथम अनुशंसा को चालू किए बिना एक पुराना आधार दस्तावेज़ उपयोगी बना रहता है।

SMTP DNS और स्पष्ट कोई मेल नहीं

RFC 5321, अक्टूबर 2008, SMTP परिवहन और लक्ष्य-रिज़ॉल्यूशन नियमों की आपूर्ति करता है। RFC 1034 और RFC 1035, नवंबर 1987, मूलभूत DNS अवधारणाएं और रिकॉर्ड संरचना प्रदान करें। उपयोग RFC 2308, मार्च 1998, अप्रचलित नकारात्मक-कैशिंग शॉर्टकट के बजाय नकारात्मक-उत्तर भेदों के लिए। ये संदर्भ बाद के अपडेट के साथ शुरुआती बिंदु हैं, पूर्ण आधुनिक DNS कार्यान्वयन विनिर्देश नहीं।

RFC 7505, जून 2015, एक ऐसे डोमेन के लिए नल MX को परिभाषित करता है जो स्पष्ट रूप से कोई मेल स्वीकार नहीं करता है। इसका प्रेषक मार्गदर्शन किसी भी तरह के लिए नल-एमएक्स डोमेन का उपयोग करने के प्रति सावधान करता है मेल प्रेषक या पहचान से दृश्यमान: प्राप्तकर्ता उस ट्रैफ़िक को अस्वीकार कर सकते हैं। उस प्रेषक मार्गदर्शन को SPF और SMTP के शून्य रिवर्स-पथ से अलग रखें। जानबूझकर किया गया नो-मेल रिकॉर्ड कोई गुम या ख़राब MX नहीं है।

प्रमाणीकरण परिणाम उद्गम RFC 8601

RFC 8601, मई 2019, परिभाषित करता है Authentication-Results शीर्षलेख और इसके विश्वास संबंधी विचार। इसका उपयोग यह मूल्यांकन करते समय करें कि प्रमाणीकरण दावा किसने किया और क्या वह दावा प्राप्तकर्ता प्रणाली की विश्वसनीय सीमा के अंदर है। यह किसी संदेश से कॉपी किए गए मनमाने हेडर को प्रमाणित साक्ष्य में नहीं बदलता है, न ही यह पास टोकन से इनबॉक्स प्लेसमेंट स्थापित करता है।

IANA पैरामीटर रजिस्ट्रियां

The DMARC पैरामीटर रजिस्ट्री, पुनर्प्राप्त रिकॉर्ड में 22 मई 2026 को अद्यतन किया गया, टैग को संदर्भों और सक्रिय या ऐतिहासिक स्थिति से जोड़ता है। यह पीसीटी, आरएफ और आरआई को ऐतिहासिक चिह्नित करता है और इसमें एनपी, पीएसडी और टी जैसे सक्रिय टैग शामिल हैं। DKIM पैरामीटर रजिस्ट्री पंजीकृत हस्ताक्षर टैग और संबंधित परिभाषाओं की पहचान करता है। पंजीकरण एक शब्दावली संदर्भ है, यह प्रमाण नहीं है कि परिनियोजन किसी पैरामीटर का सही ढंग से समर्थन करता है।

स्थिति और कार्यान्वयन अलग-अलग साक्ष्य हैं

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

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

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

[ ले लेना ]

दस्तावेज़ के अधिकार, स्थिति और दायरे का आवश्यकता से मिलान करें, फिर कार्यान्वयन साक्ष्य अलग से एकत्र करें।

[भूमिका के अनुसार]

आपके लिए इसका क्या मतलब है

व्यावहारिक अगले चरणों के लिए अपनी भूमिका चुनें।

प्रोटोकॉल समीक्षक

दावे के लिए सही प्राधिकारी चुनें

एक बेस आरएफसी, एल्गोरिदम अपडेट और रजिस्ट्री संबंधित लेकिन अलग-अलग उद्देश्यों को पूरा करते हैं।

अगले कदम

  1. दस्तावेज़ पहचानकर्ता, स्थिति, दिनांक और प्रासंगिक अनुभाग रिकॉर्ड करें।
  2. पुराने मार्गदर्शन को लागू करने से पहले अपडेट और अप्रचलित रिश्तों को पढ़ें।
  3. मुख्य नीति और प्रत्येक रिपोर्टिंग विनिर्देश को अलग रखें।

संचालन स्वामी

किसी स्रोत का लागू आवश्यकता में अनुवाद करें

एक प्रकाशित नियम तभी परिचालन दावा बन जाता है जब उसका दायरा वास्तविक मार्ग और कार्यान्वयन के अनुकूल हो।

अगले कदम

  1. प्रभावित उत्पाद, क्लाउड, प्रेषकों और प्राप्तकर्ताओं की पहचान करें।
  2. एक मालिक नियुक्त करें और एक अवलोकन योग्य स्वीकृति शर्त परिभाषित करें।
  3. आधिकारिक-स्रोत असहमति और गुम कार्यान्वयन साक्ष्य को सुरक्षित रखें।

पुस्तकालय का रखवाला

समय-समय पर उपयोगी सन्दर्भों को सुरक्षित रखें

एक संदर्भ संसाधन को स्थिर नेविगेशन और दृश्यमान रखरखाव इतिहास की आवश्यकता होती है।

अगले कदम

  1. शीर्षक या व्याख्यात्मक पाठ विकसित होने पर प्रविष्टि एंकर बनाए रखें।
  2. परिभाषित ट्रिगर्स पर रजिस्ट्री स्थिति और स्रोत संशोधन की समीक्षा करें।
  3. आंशिक पठन को पूर्ण समीक्षा माने बिना अप्राप्य स्रोतों की रिपोर्ट करें।

[ पूछे जाने वाले प्रश्न ]

अक्सर पूछे जाने वाले प्रश्नों

कौन सा वर्तमान दस्तावेज़ DMARC नीति और संरेखण को परिभाषित करता है?

RFC 9989 , मई 2026 में प्रकाशित हुआ। इसका आरएफसी संपादक रिकॉर्ड प्रस्तावित मानक स्थिति की पहचान करता है, और यह आरएफसी 7489 और 9091 को अप्रचलित कर देता है। यह साबित नहीं करता है कि किसी विशेष रिसीवर ने इसे अपनाया है।

समग्र और विफलता रिपोर्टिंग को अलग-अलग क्यों सूचीबद्ध किया गया है?

RFC 9990 समग्र रिपोर्टिंग को परिभाषित करता है; RFC 9991 संदेश-विशिष्ट विफलता रिपोर्टिंग को परिभाषित करता है और RFC 6591 अद्यतन करता है। उनके प्रारूप, साक्ष्य और गोपनीयता निहितार्थ भिन्न-भिन्न हैं।

क्या नए DMARC RFC का मतलब यह है कि DNS संस्करण DMARC2 बन जाएगा?

नहीं, वर्तमान नीति सिंटैक्स DMARC1 को बरकरार रखता है। दस्तावेज़ संख्या पॉलिसी संस्करण टैग का मान नहीं है।

क्या मूल DKIM एल्गोरिथम टेक्स्ट को अकेले इस्तेमाल किया जा सकता है?

नहीं, RFC 8301 और RFC 8463 सहित लागू अद्यतनों के साथ RFC 6376 पढ़ें। वे आधार विनिर्देश के प्रत्येक भाग को बदलने के बजाय क्रिप्टोग्राफ़िक आवश्यकताओं को बदलते या विस्तारित करते हैं।

IANA सक्रिय टैग क्या स्थापित करता है?

यह एक पंजीकृत वर्तमान पैरामीटर और उस रजिस्ट्री के भीतर उसके संदर्भ की पहचान करता है। यह साबित नहीं करता है कि कोई उत्पाद इसे स्वीकार करता है या सभी संबंधित शब्दार्थों को लागू करता है।

क्या इंटरनेट-ड्राफ्ट प्रकाशित मानक के समान है?

नहीं, यह एक कामकाजी दस्तावेज़ है। इसके पाठ को वर्तमान प्रकाशित प्रोटोकॉल आवश्यकता के रूप में मानने से पहले प्रकाशन और स्थिति रिकॉर्ड की जाँच करें।

परस्पर विरोधी प्रदाता पृष्ठों को कैसे रिकॉर्ड किया जाना चाहिए?

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

क्या यह लाइब्रेरी कमीशनिंग रजिस्टर पूरा करती है?

नहीं, यह महत्वपूर्ण स्रोत प्रविष्टियाँ और प्रस्तावित स्वामी भूमिकाएँ प्रदान करता है। संगठन-विशिष्ट स्वामी, प्रभावी-तिथि प्रयोज्यता, स्वीकृति साक्ष्य और अलग-अलग कार्य-कार्यक्षमता का सेवन खुला रहता है।

[ सूत्रों का कहना है ]

सूत्रों का कहना है

  1. IANA DKIM पैरामीटर रजिस्ट्री
  2. IANA DMARC पैरामीटर रजिस्ट्री
  3. RFC 1034 : डोमेन नाम अवधारणाएं और सुविधाएं
  4. RFC 1035 : डोमेन नाम कार्यान्वयन और विशिष्टता
  5. RFC 2026 : इंटरनेट मानक प्रक्रिया संशोधन 3
  6. RFC 2308 : DNS क्वेरीज़ की नकारात्मक कैशिंग
  7. RFC 5321 : सरल मेल ट्रांसफर प्रोटोकॉल
  8. RFC 6376 : डोमेनकीज़ ने मेल हस्ताक्षरों की पहचान की
  9. RFC 7208 : प्रेषक नीति ढांचा
  10. RFC 7505 : एक नल MX नो सर्विस रिसोर्स रिकॉर्ड
  11. RFC 8301 : क्रिप्टोग्राफ़िक एल्गोरिथम और DKIM के लिए मुख्य उपयोग अद्यतन
  12. RFC 8463 : DKIM के लिए एक नई क्रिप्टोग्राफ़िक हस्ताक्षर विधि
  13. RFC 8601 : संदेश प्रमाणीकरण स्थिति को इंगित करने के लिए संदेश हेडर फ़ील्ड
  14. RFC 9989 : डोमेन-आधारित संदेश प्रमाणीकरण रिपोर्टिंग और अनुरूपता
  15. RFC 9989 के लिए RFC संपादक सूचना रिकॉर्ड
  16. RFC 9990 : DMARC समग्र रिपोर्टिंग
  17. RFC 9990 के लिए RFC संपादक सूचना रिकॉर्ड
  18. RFC 9991 : DMARC विफलता रिपोर्टिंग

[ शब्दकोष ]

शब्दकोष

मानक ट्रैक
इंटरनेट मानक पथ पर विशिष्टताओं के लिए एक दस्तावेज़ श्रेणी; सटीक परिपक्वता स्थिति की जांच अलग से की जानी चाहिए।
प्रस्तावित मानक
आरएफसी 9989 और 9990 के लिए पुनर्प्राप्त आरएफसी संपादक रिकॉर्ड में दिखाई गई विशिष्ट स्थिति; यह इंटरनेट-ड्राफ्ट नहीं है.
इंटरनेट-ड्राफ्ट
एक कार्यशील IETF दस्तावेज़ जिसे केवल इसलिए प्रकाशित RFC के रूप में नहीं माना जाना चाहिए क्योंकि इसका स्वरूपण उससे मिलता-जुलता है।
संबंध अद्यतन करता है
एक दस्तावेज़ संबंध जो दर्शाता है कि किसी अन्य आरएफसी के निर्दिष्ट प्रावधानों को बदल दिया गया है या बढ़ाया गया है, उन्हें एक साथ पढ़ने की आवश्यकता है।
स्वीकृति प्रमाण
एक प्रतिलिपि प्रस्तुत करने योग्य अवलोकन या परीक्षण जो दर्शाता है कि लागू स्थानीय आवश्यकता पूरी हो गई है, उस स्रोत से अलग जो इसे बताता है।

उद्यम उद्गम

शीर्ष वित्तीय संस्थान और सरकारें ही क्यों? अपने ईमेल सुरक्षा डैशबोर्ड हटा दिए।

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

EmailAuth एजेंटिक ईमेल उद्गम मंच है। हमारे एजेंट लागू करते हैं p=reject, तृतीय-पक्ष प्रेषकों को संरेखित रखें और अपने डोमेन को पूर्ण रूप से स्थानांतरित करें RFC 9989 अनुपालन, नया DMARC मानक, मानव-इन-द-लूप ऑडिटेबिलिटी के साथ।

सरकारों बड़े उद्यम टियर-1 वित्तीय संस्थान

सास · समर्पित किरायेदारी · एयर-गैप्ड ऑन-प्रिमाइसेस · BYOK एन्क्रिप्शन

ज्ञानधार