DKIM की रोटेशन का मतलब है आपके मेल पर साइन करने वाली की-जोड़ी को किसी शेड्यूल पर या सुरक्षा संबंधी चिंता के बाद बदलना, बिना ऑथेंटिकेशन को तोड़े। यह जोखिम भरा लगता है क्योंकि एक गलत कदम से वैध मेल विफल हो सकते हैं, लेकिन DKIM का डिज़ाइन इसे सीधा बना देता है: सेलेक्टर आपको नई की पुरानी के बगल में प्रकाशित करने, साइनिंग बदलने और पुरानी की बाद में हटाने देते हैं। यह गाइड समझाती है कि यह कैसे काम करता है और चरण-दर-चरण योजना देती है।
DKIM साइनिंग और सेलेक्टर कैसे काम करते हैं
जब आपका प्लेटफ़ॉर्म कोई संदेश भेजता है, तो वह प्राइवेट की से सिग्नेचर बनाता है और उसे हेडर में जोड़ देता है। सिग्नेचर में साइनिंग डोमेन, जिसे d= लिखा जाता है, और एक सेलेक्टर, जिसे s= लिखा जाता है, का नाम होता है। प्राप्तकर्ता सर्वर इनसे एक DNS नाम बनाता है, selector._domainkey.domain, वहाँ प्रकाशित पब्लिक की लाता है और सिग्नेचर जाँचता है। अगर की मेल खाती है और संदेश के साइन किए गए हिस्से अपरिवर्तित हैं, तो DKIM पास होता है।
DKIM-Signature: v=1; a=rsa-sha256; d=mail.example.com; s=2026a;
h=from:to:subject:date:message-id; bh=...; b=...इस उदाहरण में सेलेक्टर 2026a है, इसलिए प्राप्तकर्ता सर्वर 2026a._domainkey.mail.example.com खोजता है। चूँकि सेलेक्टर बस एक लेबल है जो आप चुनते हैं, आप एक साथ कई प्रकाशित कर सकते हैं। रोटेशन की पूरी तरकीब यही है: पुराना सेलेक्टर पुराने मेल को सत्यापित करता रहता है जबकि नया सेलेक्टर नए मेल पर साइन करता है।
रोटेट क्यों करें
- जोखिम सीमित करें। जो प्राइवेट की वर्षों से मौजूद है, उसे ज़्यादा सिस्टम और लोगों ने देखा है। रोटेशन किसी पिछले लीक का मूल्य सीमित कर देता है।
- स्टाफ़ में बदलाव पर प्रतिक्रिया दें। अगर की तक पहुँच वाला कोई एडमिनिस्ट्रेटर चला जाए, तो की बदलने से बचा हुआ जोखिम खत्म हो जाता है।
- मज़बूत की पर जाएँ। कई पुराने डोमेन अब भी 1024-बिट की प्रकाशित करते हैं। रोटेशन अपग्रेड का स्वाभाविक मौका है।
- नीति का पालन करें। सुरक्षा समीक्षाएँ और कुछ ग्राहक प्रश्नावलियाँ पूछती हैं कि की कितनी बार बदली जाती हैं।
- प्रक्रिया का अभ्यास बनाए रखें। जो टीम साल में दो बार रोटेट करती है, वह आपातकालीन रोटेशन को शांति से संभाल लेती है।
रोटेशन डिलीवरेबिलिटी का टूल नहीं है। की बदलने से इनबॉक्स प्लेसमेंट अपने आप बेहतर नहीं होता। इसका उद्देश्य सुरक्षा और स्वच्छता है। इसे सावधानी से करें ताकि डिलीवरी को नुकसान न पहुँचे, और रेप्यूटेशन में उछाल की उम्मीद न रखें।
की की लंबाई चुनना
DKIM मानक साइनर के लिए न्यूनतम 1024 बिट तय करता है और 2048 बिट की सिफ़ारिश करता है। वेरिफ़ायर के लिए 1024 बिट से छोटी की स्वीकार करना ज़रूरी नहीं है। ज़्यादातर प्रेषकों के लिए आज का समझदारी भरा विकल्प 2048-बिट RSA है, जो बड़े प्रदर्शन-खर्च के बिना आरामदायक सुरक्षा-सीमा देता है।
| की की लंबाई | स्थिति | व्यावहारिक टिप्पणी |
|---|---|---|
| 512 बिट | स्वीकार्य नहीं | टूटी हुई मानी जाती है और आधुनिक प्राप्तकर्ता सर्वर उसे अस्वीकार करते हैं |
| 1024 बिट | न्यूनतम अनुमत, अब भी आम | काम करती है, लेकिन अगले रोटेशन पर अपग्रेड करें |
| 2048 बिट | सिफ़ारिश की गई | TXT मान को कई स्ट्रिंग में बाँटना या CNAME चाहिए |
| 4096 बिट | मानक द्वारा अनुमत | शायद ही कभी ज़रूरी, और रिकॉर्ड DNS के व्यावहारिक आकार की सीमा पार कर सकता है |
255 अक्षरों की सीमा
TXT रिकॉर्ड में एक स्ट्रिंग अधिकतम 255 अक्षर रख सकती है, और 2048-बिट पब्लिक की उससे लंबी होती है। इसलिए रिकॉर्ड में कई कोटेड स्ट्रिंग होती हैं, जिन्हें प्राप्तकर्ता सर्वर जोड़ लेता है। ज़्यादातर DNS प्रोवाइडर लंबा मान पेस्ट करने पर यह संभाल लेते हैं। अगर आपका नहीं संभालता, तो उसे हाथ से बाँटें या अपने भेजने वाले प्लेटफ़ॉर्म से CNAME विकल्प माँगें।
2026a._domainkey.mail.example.com. TXT ( "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOC..."
"...rest of the public key..." )शुरू करने से पहले: की प्रबंधन के दो मॉडल
| मॉडल | यह कैसे काम करता है | रोटेट करने के लिए आप क्या करें |
|---|---|---|
| प्लेटफ़ॉर्म-प्रबंधित (CNAME) | आप अपने सेलेक्टर से प्लेटफ़ॉर्म के नियंत्रण वाले नाम पर CNAME प्रकाशित करते हैं, और प्लेटफ़ॉर्म उसके पीछे की की बदलता है | बहुत कम या कुछ नहीं; शेड्यूल की पुष्टि करें और देखें कि CNAME बना रहे |
| ग्राहक-प्रबंधित (TXT) | आप पब्लिक की खुद प्रकाशित करते हैं, और प्लेटफ़ॉर्म उस प्राइवेट की से साइन करता है जो आपने दी या जो उसने जनरेट की | नीचे दी गई पूरी योजना का पालन करें |
| स्वयं-होस्टेड साइनिंग | आपका अपना मेल सर्वर साइन करता है, और प्राइवेट की आपके पास रहती है | की जनरेट करें, सर्वर कॉन्फ़िगरेशन और DNS अपडेट करें |
एक सुरक्षित रोटेशन योजना
- सेलेक्टर की सूची बनाएँ। डोमेन के लिए _domainkey के तहत प्रकाशित हर सेलेक्टर की सूची बनाएँ, और पहचानें कि हर एक का उपयोग कौन-सा सिस्टम करता है। अज्ञात सेलेक्टर अपने आप में एक निष्कर्ष हैं; जब तक पता न चले कि उनसे कौन साइन करता है, उन्हें न हटाएँ।
- नामकरण योजना चुनें। ऐसे सेलेक्टर इस्तेमाल करें जिनमें तारीख़ या क्रम हो, जैसे 2026a और 2027a, ताकि की एक नज़र में अलग पहचानी जा सकें।
- नई की जनरेट करें। 2048-बिट की-जोड़ी बनाएँ, या अपने प्लेटफ़ॉर्म से जारी करने को कहें। प्राइवेट की सिर्फ़ वहीं रखें जहाँ साइनिंग सिस्टम को उसकी ज़रूरत है।
- नई पब्लिक की प्रकाशित करें। नया सेलेक्टर रिकॉर्ड जोड़ें। पुराने को न छुएँ। पुष्टि करें कि वह आपके नेटवर्क के बाहर से रिज़ॉल्व होता है।
- स्विच करने से पहले परीक्षण करें। नए सेलेक्टर से एक टेस्ट संदेश साइन करें और प्राप्त हेडर में पुष्टि करें कि DKIM पास होता है।
- साइनिंग स्विच करें। सभी नए संदेशों के लिए नया सेलेक्टर इस्तेमाल करने हेतु साइनिंग कॉन्फ़िगरेशन बदलें। इसी क्षण से पुरानी की कुछ नया साइन नहीं करती।
- निगरानी करें। अगले कुछ दिनों में DMARC एग्रीगेट रिपोर्ट और बाउंस डेटा में DKIM विफलताओं के उछाल पर नज़र रखें।
- पीछे रह गए संदेशों का इंतज़ार करें। पुराना रिकॉर्ड कम से कम कुछ दिनों तक प्रकाशित रखें। कतार में अटके, दोबारा भेजे गए या फ़ॉरवर्ड किए गए संदेश भेजे जाने के समय नहीं, प्रोसेस होने के समय सत्यापित होते हैं।
- पुरानी की हटाएँ। पुराना सेलेक्टर रिकॉर्ड हटाएँ और हर उस सिस्टम से पुरानी प्राइवेट की मिटा दें जिसके पास वह थी।
- रोटेशन दर्ज करें। तारीख़, नया सेलेक्टर और अगले रोटेशन की तारीख़ अपने रनबुक में लिखें।
पुरानी की कितने समय तक रखें
पुरानी पब्लिक की तब तक DNS में रहनी चाहिए जब तक उससे साइन किया गया कोई भी मेल रास्ते में या सत्यापन की प्रतीक्षा में न हो सकता हो। सामान्य ट्रांज़ैक्शनल और मार्केटिंग मेल के लिए कुछ दिन काफ़ी हैं। अगर आप मेलिंग लिस्ट या ऐसी फ़ॉरवर्डिंग सेवाओं से भेजते हैं जो संदेश रोककर रखती हैं, या आपका रीट्राई शेड्यूल लंबा है, तो ज़्यादा इंतज़ार करें। पुरानी की को ज़रा ज़्यादा समय तक प्रकाशित रखने में कोई लागत नहीं है। उसे बहुत जल्दी हटाने से ऐसी विफलताएँ होती हैं जिनका निदान कठिन होता है।
क्या गलत हो सकता है, और उसे कैसे पहचानें
| समस्या | संकेत | समाधान |
|---|---|---|
| सेलेक्टर बेमेल | DKIM key not found के साथ विफल होता है | सिग्नेचर के s= मान की DNS नाम से तुलना करें |
| कटी हुई पब्लिक की | DKIM bad key या signature mismatch के साथ विफल होता है | की दोबारा पेस्ट करें और जाँचें कि स्ट्रिंग के सभी हिस्से मौजूद हैं |
| पुरानी की जल्दी हटा दी गई | विफलताएँ सिर्फ़ देरी से आए मेल पर | पुराना रिकॉर्ड बहाल करें और अगली बार ज़्यादा इंतज़ार करें |
| साइनिंग स्विच नहीं हुई | नया सेलेक्टर हेडर में कभी दिखता ही नहीं | साइनिंग कॉन्फ़िगरेशन और किसी भी कैश की गई सेटिंग को जाँचें |
| दो सिस्टम एक सेलेक्टर साझा करते हैं | एक सिस्टम के रोटेट करने के बाद रुक-रुक कर विफलताएँ | हर सिस्टम को उसका अपना सेलेक्टर दें |
| सफ़ाई के दौरान CNAME हटा दिया गया | प्लेटफ़ॉर्म-प्रबंधित की के लिए DKIM अचानक हर जगह विफल | CNAME को ठीक वैसे ही बहाल करें जैसा दिया गया था |
सफलता की पुष्टि के लिए रिपोर्ट का उपयोग करें
DMARC एग्रीगेट रिपोर्ट हर भेजने वाले स्रोत के लिए दिखाती हैं कि कितने संदेश DKIM और SPF में पास या विफल हुए। रोटेशन के बाद के दिनों में उन्हें जाँचें। साफ़ रोटेशन में नया सेलेक्टर दिखने लगता है और विफलताओं की संख्या स्थिर रहती है। अगर किसी एक स्रोत के लिए विफलताएँ बढ़ती हैं, तो संभवतः वह अब भी ऐसी की से साइन कर रहा है जो अब प्रकाशित नहीं है। हमारी DMARC एग्रीगेट रिपोर्ट गाइड बताती है कि उन्हें कैसे पढ़ें।
आपातकालीन रोटेशन
अगर आपको संदेह है कि प्राइवेट की उजागर हो गई है, तो तुरंत रोटेट करें और ओवरलैप की अवधि छोटी रखें। जितनी जल्दी सुरक्षित रूप से हो सके, नई की प्रकाशित करें और उस पर स्विच करें, फिर समझौता हुई की को हटा दें, भले ही कुछ देरी से आए मेल विफल हो जाएँ। पुरानी प्राइवेट की वाला हमलावर ऐसा जाली मेल साइन कर सकता है जो जब तक पब्लिक की प्रकाशित रहती है, आपके डोमेन के लिए DKIM पास कर ले, इसलिए उजागर रहने की अवधि कुछ देरी वाले संदेशों के नुकसान से ज़्यादा मायने रखती है। लागू DMARC और reject पॉलिसी ऐसी जालसाज़ियों का असर सीमित करती हैं, लेकिन की को फिर भी जल्दी हटाना चाहिए।
रोटेशन को नियमित बनाएँ
- रोटेशन की तारीख़ को साझा कैलेंडर में एक नामित ज़िम्मेदार व्यक्ति के साथ रखें।
- सेलेक्टर, उनका उपयोग करने वाले सिस्टम और उनकी निर्माण तिथियों की एक तालिका रखें।
- हर भेजने वाले सिस्टम के लिए एक अलग सेलेक्टर इस्तेमाल करें।
- DKIM विफलता दर पर अलर्ट लगाएँ, ताकि गलत रोटेशन घंटों के भीतर पकड़ में आ जाए।
- अगर प्रक्रिया आपकी टीम के लिए नई है, तो पहले किसी कम जोखिम वाले सबडोमेन पर अभ्यास करें।
रोटेशन की योजना बनाने में मदद चाहिए? हमें बताएँ कि आप कौन-से डोमेन और भेजने वाले सिस्टम इस्तेमाल करते हैं, और हम एक सुरक्षित क्रम सुझाएँगे।
आगे पढ़ें और स्रोत
अक्सर पूछे जाने वाले प्रश्न
DKIM सेलेक्टर क्या है?
सेलेक्टर एक लेबल है जो प्राप्तकर्ता सर्वर को बताता है कि कौन-सी पब्लिक की लानी है। सिग्नेचर में एक सेलेक्टर और एक डोमेन का नाम होता है, और प्राप्तकर्ता selector._domainkey.domain पर DNS रिकॉर्ड खोजता है। चूँकि सेलेक्टर नाम का हिस्सा है, एक डोमेन एक साथ कई की प्रकाशित कर सकता है, और यही रोटेशन को सुरक्षित बनाता है।
मुझे DKIM की कितनी बार रोटेट करनी चाहिए?
कोई एक अनिवार्य अंतराल नहीं है। कई संगठन साल में एक या दो बार रोटेट करते हैं, या तब जब प्राइवेट की तक पहुँच वाला कोई व्यक्ति संगठन छोड़ दे या किसी समझौते का संदेह हो। ऐसा शेड्यूल चुनें जिसका आप वास्तव में पालन करेंगे, और अगर कभी लगे कि की उजागर हो गई है तो जल्दी रोटेट करें।
मुझे DKIM की की कौन-सी लंबाई इस्तेमाल करनी चाहिए?
जहाँ आपका DNS प्रोवाइडर और भेजने वाला सिस्टम समर्थन करें, वहाँ 2048-बिट RSA इस्तेमाल करें। DKIM मानक के अनुसार साइनर को कम से कम 1024 बिट इस्तेमाल करने होते हैं और 2048 की सिफ़ारिश की जाती है, और वेरिफ़ायर को 1024 से छोटी की स्वीकार नहीं करनी चाहिए। लंबी की कंप्यूटिंग शक्ति बढ़ने पर ज़्यादा सुरक्षा-सीमा देती हैं।
मेरा DNS प्रोवाइडर मेरी 2048-बिट की क्यों अस्वीकार कर रहा है?
2048-बिट पब्लिक की 255 अक्षरों से लंबी होती है, जो TXT रिकॉर्ड में एक स्ट्रिंग की सीमा है। उसे कई कोटेड स्ट्रिंग में बाँटना पड़ता है जिन्हें प्राप्तकर्ता जोड़ लेता है। कई प्रोवाइडर यह अपने आप कर देते हैं; अगर आपका नहीं करता, तो उसे हाथ से बाँटें या प्लेटफ़ॉर्म द्वारा होस्ट किए गए रिकॉर्ड के लिए CNAME का उपयोग करें।
क्या स्विच करने के तुरंत बाद पुरानी की हटाना सुरक्षित है?
सुरक्षित नहीं है। संदेश कतारों में अटक सकते हैं या कई दिनों तक दोबारा भेजे जा सकते हैं, और प्राप्तकर्ता सर्वर संदेश को प्रोसेस करते समय सिग्नेचर सत्यापित करते हैं। पुराना रिकॉर्ड कम से कम कुछ दिनों तक प्रकाशित रखें, और अगर आप धीमे फ़ॉरवर्डिंग रास्तों से भेजते हैं तो ज़्यादा समय तक।
अगर मैं ऐसी की हटा दूँ जो अभी इस्तेमाल में है तो क्या होगा?
उस सेलेक्टर से साइन किए गए संदेश DKIM सत्यापन में विफल हो जाते हैं। अगर SPF अलाइन होता है तो DMARC फिर भी पास हो सकता है, लेकिन अगर SPF अलाइन नहीं है तो लागू DMARC पॉलिसी के तहत संदेश क्वारंटीन या रिजेक्ट हो सकता है। इसीलिए पहले साइनिंग बदली जाती है और पुरानी की बाद में हटाई जाती है।
क्या मेरा भेजने वाला प्लेटफ़ॉर्म मेरे लिए की रोटेट करता है?
कुछ प्लेटफ़ॉर्म DKIM की खुद प्रबंधित करते हैं और उन्हें एक CNAME के ज़रिए प्रकाशित करते हैं जिसे आप सिर्फ़ एक बार पॉइंट करते हैं, इसलिए रोटेशन उनकी तरफ़ होता है। अन्य एक स्थिर रिकॉर्ड देते हैं जिसे आपको खुद बदलना पड़ता है। रोटेशन की योजना बनाने से पहले जाँच लें कि आपका प्लेटफ़ॉर्म कौन-सा मॉडल इस्तेमाल करता है।
क्या अलग-अलग मेल स्ट्रीम के लिए अलग सेलेक्टर होने चाहिए?
हाँ, यह एक अच्छा अभ्यास है। ट्रांज़ैक्शनल, मार्केटिंग और आंतरिक सिस्टम के लिए अलग सेलेक्टर होने से किसी एक को बाकी को प्रभावित किए बिना रोटेट या रद्द करना आसान हो जाता है, और हेडर विश्लेषण भी साफ़ हो जाता है।
क्या मैं स्विच करने से पहले की का परीक्षण कर सकता हूँ?
हाँ। पहले नया रिकॉर्ड प्रकाशित करें, पुष्टि करें कि वह रिज़ॉल्व हो रहा है, फिर नए सेलेक्टर से साइन किए गए टेस्ट संदेश अपने नियंत्रण वाले इनबॉक्स में भेजें और पूरा ट्रैफ़िक स्विच करने से पहले हेडर में जाँचें कि DKIM पास हो रहा है।