DKIM क्या है?
DKIM (RFC 6376) भेजने वाले सर्वर को हर मेल एक प्राइवेट कुंजी से साइन करने देता है, जबकि उससे जुड़ी पब्लिक कुंजी _domainkey के नीचे TXT रिकॉर्ड के रूप में पब्लिश होती है (example.com के selector s1 के लिए s1._domainkey.example.com)। मेल लेने वाला सर्वर सिग्नेचर के s= और d= टैग में बताई कुंजी लाकर जाँचता है कि साइन किए हेडर और बॉडी बदले नहीं गए; RFC 8301 के अनुसार verifier 1024 बिट से छोटी RSA कुंजियाँ ठुकराते हैं, और 2048 बिट की सिफ़ारिश है।
DKIM रिकॉर्ड चेकर कैसे इस्तेमाल करें
- selector ढूँढें: डोमेन से आई कोई मेल खोलें, उसके मूल हेडर देखें और DKIM-Signature हेडर के s= और d= टैग पढ़ें।
- d= वाला डोमेन और selector लिखें, या पूरा कुंजी नाम डोमेन फ़ील्ड में पेस्ट करें।
- «DKIM जाँचें» दबाएँ और नतीजा, कुंजी का टाइप व लंबाई, और टेस्टिंग मोड चालू है या नहीं, पढ़ें।
- टैग टेबल, ग़लतियाँ और चेतावनियाँ देखें; सुधरा हुआ रिकॉर्ड पब्लिश करके दोबारा जाँचें।
- कुंजी रिकॉर्ड पब्लिश करने से पहले जाँचना हो तो उसे तीसरे फ़ील्ड में पेस्ट करें; वह आपके ब्राउज़र में पार्स होता है।
DKIM रिकॉर्ड चेकर की खूबियाँ
- HTTPS पर पब्लिक DNS से डोमेन के selector._domainkey की पब्लिक कुंजी लाना — मेल सेवा ने वहाँ CNAME रखवाया हो तो उसे भी फ़ॉलो करना
- कुंजी रिकॉर्ड के हर टैग की व्याख्या: v, k, p, t, s, h, n और ऐसा कोई भी टैग जिसे verifier नहीं जानते
- p= को डिकोड करके RSA कुंजी की लंबाई कुंजी से ही पढ़ना, और Ed25519 कुंजी की पहचान
- रद्द की गई कुंजी (खाली p=), टेस्टिंग मोड (t=y), 1024 या 2048 बिट से छोटी कुंजी और ग़लत रूप में पब्लिश हुई कुंजी पर चेतावनी
- एक selector पर दो कुंजी रिकॉर्ड, या वहाँ ऐसे TXT रिकॉर्ड जो कुंजी नहीं हैं — दोनों की सूचना
- तीसरे फ़ील्ड में पेस्ट किया कुंजी रिकॉर्ड पब्लिश करने से पहले आपके ब्राउज़र में जाँचा जाता है
- selector1._domainkey.example.com जैसा पूरा कुंजी नाम सीधे डोमेन फ़ील्ड में लिखा जा सकता है
इनपुट और आउटपुट
इनपुट
- डोमेन नाम — सिग्नेचर का d= डोमेन; पूरा कुंजी नाम (selector._domainkey.domain) अपने-आप selector और डोमेन में बँट जाता है।
- Selector — DKIM-Signature हेडर का s= टैग; लाइव जाँच के लिए ज़रूरी, क्योंकि DNS selector की सूची नहीं देता।
- पेस्ट किया कुंजी रिकॉर्ड (वैकल्पिक) — TXT वैल्यू, सादी या ज़ोन फ़ाइल / DNS पैनल में दिखने वाले उद्धरण-चिह्नों के टुकड़ों में। यह भरा हो तो कोई लुकअप नहीं होता।
आउटपुट
- सारांश — नतीजा, कुंजी का टाइप, बिट में कुंजी की लंबाई और टेस्टिंग मोड चालू है या नहीं।
- रिकॉर्ड — जिस नाम पर क्वेरी हुई और वहाँ मिला रिकॉर्ड।
- कुंजी रिकॉर्ड के टैग — हर टैग का अर्थ और वैल्यू; कुंजी ख़ुद अपने शुरुआती अक्षरों और लंबाई तक छोटी दिखती है।
- त्रुटियाँ, चेतावनियाँ और आगे क्या करें — हर बात सरल भाषा में, और नतीजे से निकलने वाले अगले क़दम।
DKIM रिकॉर्ड चेकर का उदाहरण
github.com की Google Workspace कुंजी (selector google, अक्टूबर 2026)
इनपुट:
github.com · selector googleआउटपुट:
परिणाम: कुंजी सही ढंग से पब्लिश है · कुंजी का टाइप (k=): RSA · कुंजी की लंबाई (बिट): 2048 · टेस्टिंग (t=y): नहीं
क्वेरी किया गया नाम: google._domainkey.github.com
कुंजी रिकॉर्ड के टैग: v — संस्करण (DKIM1) — DKIM1 · k — कुंजी का टाइप — rsa · p — पब्लिक कुंजी (base64) — MIIBIjANBgkqhkiG9w0BAQEF… (392)DKIM रिकॉर्ड चेकर के नतीजे कैसे पढ़ें
«कुंजी सही ढंग से पब्लिश है»: verifier कुंजी लाकर इस्तेमाल कर सकता है, और कुंजी कम से कम 2048 बिट की है या Ed25519 है। कोई ख़ास मेल pass होगी या नहीं, यह फिर भी उसके सिग्नेचर पर निर्भर है।
«इस्तेमाल लायक़, चेतावनियों के साथ»: कुंजी काम करती है पर कुछ उसे कमज़ोर करता है — अक्सर 1024 बिट की RSA कुंजी, t=y टेस्टिंग मोड या कोई पुराना टैग।
«ग़लतियाँ हैं»: रिकॉर्ड इस्तेमाल नहीं हो सकता — p= में ग़लत base64, बताए टाइप से मेल न खाने वाली कुंजी, 1024 बिट से छोटी RSA कुंजी या टूटा टैग सिंटैक्स। इस selector से बने सिग्नेचर fail होते हैं।
«कुंजी रद्द है»: p= खाली है, जिसे RFC 6376 रद्द कुंजी कहता है। रिटायर हुए selector के लिए यह सामान्य है; दिक़्क़त तभी है जब मेल अब भी इससे साइन हो रही हो।
«कोई DKIM कुंजी नहीं»: उस नाम पर कुंजी वाला कोई TXT रिकॉर्ड नहीं। अक्सर selector ग़लत होता है, रिकॉर्ड अभी पब्लिश नहीं हुआ, या सेवा को ऐसा CNAME चाहिए जो बना नहीं।
DKIM रिकॉर्ड चेकर कब इस्तेमाल करें
- साइनिंग चालू करने से पहले पक्का करना कि मेल सेवा ने जो DKIM रिकॉर्ड पब्लिश करने को कहा था, वह अपनी जगह है।
- पता करना कि मेल DKIM में क्यों fail हो रही है: रद्द की गई कुंजी, ग़लत लिखा selector, या DNS पैनल में पेस्ट करते समय कटी हुई कुंजी।
- कुंजी बदलने की योजना: पुराना और नया selector जाँचना, और यह कि नई कुंजी 2048 बिट की हो।
- प्रोवाइडर के सेटअप पेज से मिला कुंजी रिकॉर्ड अपने ज़ोन में जोड़ने से पहले जाँचना।
समस्या निवारण
- अभी जोड़े selector पर «कोई DKIM कुंजी नहीं»: कई DNS पैनल आपके लिखे नाम के आगे डोमेन ख़ुद जोड़ देते हैं, इसलिए selector._domainkey.example.com लिखा रिकॉर्ड selector._domainkey.example.com.example.com पर पहुँच जाता है। ऐसे पैनल में सिर्फ़ selector._domainkey लिखें।
- «p= मान्य base64 नहीं है» या ग़लत लंबाई की कुंजी: पेस्ट करते समय कुंजी कट गई या टूट गई। लंबी कुंजी को ज़्यादा से ज़्यादा 255 अक्षरों की उद्धरण-चिह्नों वाली स्ट्रिंग में बाँटें, एक ही स्ट्रिंग के अंदर लाइन तोड़कर नहीं।
- आपकी मौजूदा मेल वाले selector पर «कुंजी रद्द है»: सेवा ने कुंजी बदल दी है और आपके DNS में पुरानी बची है, या उसका माँगा CNAME नहीं है। सेवा की मौजूदा DKIM सेटिंग से मिलाएँ।
- Selector स्वीकार नहीं हुआ: सिर्फ़ selector लिखें (जैसे s1), s1._domainkey नहीं; या पूरा कुंजी नाम डोमेन फ़ील्ड में लिखें।
- अनुरोध-सीमा वाला संदेश: हर जाँच एक DNS क्वेरी है, पर बाक़ी DNS टूल्स के साथ हर विज़िटर का एक साझा बजट होता है; दिखाए गए सेकंड रुककर फिर कोशिश करें।
DKIM रिकॉर्ड चेकर के बारे में अक्सर पूछे जाने वाले सवाल
डोमेन का DKIM selector कैसे पता करें?
डोमेन से आई कोई मेल खोलें, उसके मूल हेडर देखें (Gmail में «Show original») और DKIM-Signature हेडर ढूँढें: s= टैग selector है और d= साइन करने वाला डोमेन। आपकी मेल सेवा का एडमिन पेज भी बताता है कि वह कौन-सा selector पब्लिश करती है। DNS किसी डोमेन के selector की सूची नहीं देता, इसलिए चेकर उन्हें अपने-आप नहीं ढूँढ सकता।
खाली p= टैग का क्या मतलब है?
खाली p= का मतलब है कि कुंजी रद्द कर दी गई है (RFC 6376 §3.6.1)। उस selector से बने सिग्नेचर अब fail होते हैं। कुंजी बदलने के बाद पुराने selector के लिए यह सामान्य है; दिक़्क़त तभी है जब आपकी मेल अब भी उसी selector से साइन हो रही हो।
DKIM कुंजी कितनी लंबी होनी चाहिए?
RFC 8301 के अनुसार verifier 1024 बिट से छोटी RSA कुंजियाँ ठुकराते हैं, और साइन करने वालों को कम से कम 2048 बिट इस्तेमाल करनी चाहिए। Ed25519 कुंजियाँ (RFC 8463) छोटी और मज़बूत हैं, पर अभी हर मेल सर्वर उन्हें नहीं मानता, इसलिए उन्हें RSA कुंजी के साथ पब्लिश करें, उसकी जगह नहीं।
DKIM रिकॉर्ड में t=y का क्या मतलब है?
t=y बताता है कि कुंजी अभी टेस्ट हो रही है: verifier से कहा जाता है कि जिस मेल का सिग्नेचर fail हो उसे बिना साइन वाली मेल जैसा मानें। साइनिंग ठीक चलने लगे तो यह फ़्लैग हटा दें, वरना कुंजी से जितनी सुरक्षा मिलनी चाहिए उतनी नहीं मिलती।
क्या सही कुंजी रिकॉर्ड का मतलब है कि मेरी मेल DKIM में pass होगी?
अकेले नहीं। चेकर पुष्टि करता है कि पब्लिक कुंजी पब्लिश है और पढ़ी जा सकती है। मेल तभी pass होती है जब वह मिलती-जुलती प्राइवेट कुंजी से साइन हुई हो और साइन किए हेडर व बॉडी रास्ते में न बदले हों। असली नतीजा देखने के लिए मिली हुई मेल का Authentication-Results हेडर पढ़ें।
तकनीकी नोट्स
DKIM सिग्नेचर (RFC 6376) d= में साइन करने वाला डोमेन और s= में selector बताता है। verifier s._domainkey.d पर TXT रिकॉर्ड लाता है, p= से पब्लिक कुंजी पढ़ता है और सिग्नेचर में बताए हेडर व बॉडी के hash पर सिग्नेचर जाँचता है। selector की मदद से एक डोमेन एक साथ कई कुंजियाँ पब्लिश कर सकता है: हर मेल सेवा के लिए एक, या कुंजी बदलते समय पुरानी और नई।
कुंजी रिकॉर्ड टैग की एक सूची है: v=DKIM1 (वैकल्पिक, पर हो तो सबसे पहले), k= कुंजी का टाइप (डिफ़ॉल्ट rsa, RFC 8463 के तहत ed25519), p= base64 में कुंजी — खाली हो तो रद्द — और वैकल्पिक t=, s=, h= व n=। चेकर p= डिकोड करके उसकी ASN.1 संरचना से RSA modulus की लंबाई पढ़ता है; RFC 8301 के अनुसार verifier 1024 बिट से छोटी RSA कुंजियाँ ठुकराते हैं और साइन करने वालों से कम से कम 2048 बिट माँगी जाती है, और Ed25519 कुंजी ठीक 32 बाइट की raw कुंजी होनी चाहिए।
नतीजा: «कुंजी सही ढंग से पब्लिश है» जब कुंजी पढ़ी जा सके, सुझाई गई लंबाई की हो और चेतावनी लायक़ कुछ न हो; «इस्तेमाल लायक़, चेतावनियों के साथ» 1024 बिट की कुंजी, टेस्टिंग मोड या किसी और चेतावनी पर; «ग़लतियाँ हैं» जब verifier कुंजी इस्तेमाल न कर सकें; «कुंजी रद्द है» खाली p= पर; «कोई DKIM कुंजी नहीं» जब नाम पर कोई कुंजी रिकॉर्ड न हो।
सीमाएँ और कार्यप्रणाली
चेकर को selector चाहिए। DNS किसी डोमेन के selector की सूची नहीं देता, और आम नामों का अनुमान लगाने से उनमें से कुछ ही मिलेंगे।
यह पब्लिश हुई कुंजी जाँचता है, सिग्नेचर नहीं: यह नहीं बता सकता कि कोई ख़ास मेल सही साइन हुई या रास्ते में बदली। यह मेल लेने वाले सर्वर का जोड़ा Authentication-Results हेडर बताता है।
कुंजी Cloudflare एज पर चल रहा Mutqan सर्वर Cloudflare के पब्लिक रिज़ॉल्वर से पढ़ता है; अभी-अभी पब्लिश हुआ रिकॉर्ड कैश जवाबों की मियाद ख़त्म होने तक शायद न दिखे।
सुरक्षा और गोपनीयता
लाइव जाँच में डोमेन और selector Mutqan सर्वर तक जाते हैं, जो HTTPS पर Cloudflare के पब्लिक DNS से सिर्फ़ उस एक कुंजी नाम के बारे में पूछता है; कुछ भी स्टोर नहीं होता। पेस्ट किया कुंजी रिकॉर्ड आपके ब्राउज़र से बाहर नहीं जाता। DKIM पब्लिक कुंजी स्वभाव से सार्वजनिक है — प्राइवेट कुंजी कभी कहीं पेस्ट न करें।
संदर्भ
- RFC 6376: DomainKeys Identified Mail (DKIM) SignaturesDKIM सिग्नेचर और selector._domainkey पर पब्लिक-कुंजी रिकॉर्ड: उसके टैग (v, k, p, t, s, h, n) और verifier कुंजी को कैसे ढूँढकर इस्तेमाल करता है।
- RFC 8301: Cryptographic Algorithm and Key Usage Update to DomainKeys Identified Mail (DKIM)साइन करने के लिए rsa-sha1 बंद करता है, verifier से 1024 बिट से छोटी RSA कुंजियाँ ठुकराने को कहता है और साइन करने वालों से कम से कम 2048 बिट माँगता है।
- RFC 8463: A New Cryptographic Signature Method for DomainKeys Identified Mail (DKIM)DKIM में Ed25519 सिग्नेचर जोड़ता है, जिसकी कुंजी p= में 32 बाइट की raw पब्लिक कुंजी के रूप में, k=ed25519 के साथ पब्लिश होती है।