अच्छी ईमेल के लिए DNS रिकॉर्ड ट्रबलशूटिंग एक असुविधाजनक तथ्य से शुरू होती है: जब SPF, DKIM या कोई ट्रैकिंग CNAME सत्यापित नहीं होता, तो कारण शायद ही कभी वह रिकॉर्ड होता है जिसे आप प्रकाशित करना चाहते थे। आमतौर पर कारण यह होता है कि आपके DNS पैनल ने उसे कैसे स्टोर किया। 255 अक्षरों से लंबी कुंजी, दो बार जुड़ा हुआ डोमेन नाम, कोट्स की जोड़ी जो वैल्यू का हिस्सा बन गई, दूसरा SPF रिकॉर्ड, या कैश से अभी तक न हटा पुराना उत्तर। हम इनमें से हर एक को देखेंगे, dig और nslookup से उन्हें जाँचने का तरीका दिखाएँगे, और अंत में एक तालिका देंगे जिसे आप लक्षण के आधार पर इस्तेमाल कर सकते हैं।
DNS में ईमेल रिकॉर्ड कैसे रहते हैं
हर ईमेल ऑथेंटिकेशन विधि कुछ रिकॉर्ड प्रकारों पर टिकी होती है। SPF और DKIM TXT रिकॉर्ड के रूप में प्रकाशित होते हैं, DMARC एक TXT रिकॉर्ड है जो _dmarc से शुरू होने वाले नाम पर होता है, और कई सेंडिंग प्लेटफ़ॉर्म रिटर्न-पाथ या ट्रैकिंग होस्टनाम के लिए CNAME रिकॉर्ड माँगते हैं। MX रिकॉर्ड इनबाउंड मेल को रूट करते हैं। रिज़ॉल्वर किसी नाम और प्रकार के बारे में पूछता है, और उत्तर के साथ एक time to live, यानी TTL, आता है, जो हर कैश को बताता है कि वह उसे कितनी देर तक दोबारा इस्तेमाल कर सकता है।
तीन बातें ज़्यादातर परेशानी समझा देती हैं। पहली, DNS पैनल किसी ज़ोन के ऊपर बने सुविधाजनक फ्रंट एंड हैं, और हर पैनल नामों, कोट्स और विभाजन के बारे में अपने फ़ैसले खुद करता है। दूसरी, कैश कई स्तरों पर होते हैं, इसलिए एक ही नाम कुछ समय तक अलग-अलग जगहों पर अलग उत्तर दे सकता है। तीसरी, कुछ रिकॉर्ड प्रकार एक ही नाम पर एक-दूसरे को बाहर कर देते हैं। रिकॉर्ड के पूरे सेट को हम हमारी ऑथेंटिकेशन गाइड में और सत्यापन प्रक्रिया को अपना सेंडिंग डोमेन सत्यापित करना में बताते हैं। यह लेख उनका निदान-संबंधी साथी है।
सबसे पहले सही जगह जाँचें: ऑथोरिटेटिव नेमसर्वर
कुछ भी बदलने से पहले पता करें कि असल में क्या प्रकाशित है। आपके लैपटॉप जैसा कोई सार्वजनिक रिज़ॉल्वर पुराना उत्तर पकड़े हो सकता है। ऑथोरिटेटिव नेमसर्वर वे सर्वर हैं जिनके पास आपका ज़ोन है और जो निर्णायक उत्तर देते हैं, इसलिए हम हमेशा पहले उन्हीं से पूछते हैं।
# 1. Find the authoritative nameservers for the domain
dig NS example.com +short
# 2. Ask one of them directly for the record (no cache involved)
dig TXT selector1._domainkey.example.com @ns1.dns-host.example +noall +answer
# 3. Compare with what a public resolver says
dig TXT selector1._domainkey.example.com @9.9.9.9 +noall +answer
# 4. Check the TTL and the negative caching value
dig SOA example.com @ns1.dns-host.example +noall +answer
# nslookup equivalent
nslookup -type=TXT selector1._domainkey.example.com ns1.dns-host.exampleअगर ऑथोरिटेटिव उत्तर गलत है, तो समस्या पैनल में है: रिकॉर्ड ठीक करें। अगर ऑथोरिटेटिव उत्तर सही है और सार्वजनिक रिज़ॉल्वर का उत्तर अलग है, तो समस्या कैश की है: इंतज़ार करें। अगर दोनों सही हैं और सत्यापन फिर भी विफल है, तो संभवतः आप गलत नाम जाँच रहे हैं, या प्लेटफ़ॉर्म को कोई दूसरा रिकॉर्ड प्रकार चाहिए। यह एक तुलना इस लेख की किसी भी अन्य बात से ज़्यादा अटकलबाज़ी खत्म करती है।
सुझाव: ऐसी मशीन से जाँचें जो आपके अपने DNS कैश का उपयोग नहीं करती, और याद रखें कि वेब-आधारित चेकर का परिणाम उस चेकर के रिज़ॉल्वर को दर्शाता है, आपके को नहीं।
255 अक्षरों से लंबे TXT स्ट्रिंग और DKIM 2048-बिट कुंजियाँ
TXT रिकॉर्ड में एक या अधिक कैरेक्टर-स्ट्रिंग होती हैं, और हर कैरेक्टर-स्ट्रिंग 255 बाइट तक सीमित है। यह RFC 1035 के मूल DNS फ़ॉर्मैट से आता है, जो हर स्ट्रिंग को एक-बाइट की लंबाई के साथ स्टोर करता है। एक रिकॉर्ड में कई स्ट्रिंग हो सकती हैं, और SPF तथा DKIM के लिए रिसीवर उन्हें क्रम से, बिना स्पेस जोड़े, जोड़ लेता है। दोनों के विनिर्देश यही कहते हैं (SPF के लिए RFC 7208, DKIM के लिए RFC 6376)।
व्यावहारिक असर DKIM पर पड़ता है। base64 में 1024-बिट RSA पब्लिक की, वर्ज़न और कुंजी-प्रकार के टैग जोड़ने पर, सीमा के काफ़ी करीब बैठती है, जबकि 2048-बिट कुंजी लगभग दोगुनी लंबी होती है, इसलिए अकेली p= वैल्यू कई सौ अक्षरों की होती है। इसे एक से अधिक स्ट्रिंग के रूप में स्टोर करना ही पड़ता है। हमारी DKIM कुंजी रोटेशन, सेलेक्टर और कुंजी लंबाई की गाइड बताती है कि 2048-बिट कुंजियाँ मेहनत के लायक क्यों हैं।
| आपका पैनल कैसे व्यवहार करता है | आपको क्या करना चाहिए | कैसे सत्यापित करें |
|---|---|---|
| लंबी वैल्यू अपने आप विभाजित करता है | पूरी वैल्यू एक बार चिपकाएँ, बिना कोट्स और बिना लाइन ब्रेक के | dig कई कोट की हुई स्ट्रिंग दिखाता है जो मिलकर पूरी कुंजी पढ़ी जाती हैं |
| आपसे कोट किए हुए टुकड़े दर्ज कराता है | 255 से कम वाले किसी भी बिंदु पर विभाजित करें, हर भाग को कोट्स में रखें, और एक स्पेस से अलग करें | जुड़ा हुआ पाठ मूल कुंजी से हू-ब-हू मेल खाता है |
| 255 अक्षरों से अधिक की वैल्यू अस्वीकार करता है | लंबे रिकॉर्ड की सेटिंग या दूसरा रिकॉर्ड एडिटर खोजें; कोई न हो तो होस्ट से पूछें | लुकअप कटी हुई नहीं, पूरी कुंजी लौटाता है |
| चुपचाप वैल्यू को काट देता है | टुकड़ों में फिर से दर्ज करें और परिणाम वापस पढ़ें | जो कुंजी जल्दी खत्म हो जाती है वह कुंजी या सिंटैक्स त्रुटि के साथ DKIM में विफल होती है |
सही विभाजन कैसा दिखता है
नीचे का उदाहरण विभाजित रिकॉर्ड का स्वरूप दिखाता है। कुंजी का पाठ काल्पनिक और उदाहरण के लिए छोटा किया हुआ है। असली रिकॉर्ड में टुकड़े मिलकर आपके प्लेटफ़ॉर्म द्वारा दी गई पूरी कुंजी बनाते हैं।
selector1._domainkey.example.com. 3600 IN TXT (
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA"
"q1x2example0invented0key0chunk0one0aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
"bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb"
"IDAQAB" )दो गलतियाँ आम हैं। कुंजी को विभाजित करते समय उसके अंदर स्पेस न जोड़ें, क्योंकि रिसीवर स्ट्रिंग को जोड़ता है और स्पेस कुंजी का हिस्सा बन जाएगा। और रिकॉर्ड को सेलेक्टर या टैग नामों के बीच में न काटें। अगर विभाजित कुंजी विफल हो, तो जुड़े हुए परिणाम की मूल से अक्षर-दर-अक्षर तुलना अपनी आँखों से नहीं, टेक्स्ट डिफ़ से करें।
रजिस्ट्रार और DNS पैनल की खामियाँ
एक ही रिकॉर्ड को चार पैनलों में चार अलग तरीकों से दर्ज किया जा सकता है। ये वे खामियाँ हैं जो हम सबसे अधिक देखते हैं।
डोमेन दो बार जुड़ जाता है
कई पैनल ज़ोन का नाम अपने आप जोड़ देते हैं। अगर आप होस्ट फ़ील्ड में selector1._domainkey.example.com लिखते हैं, तो पैनल selector1._domainkey.example.com.example.com स्टोर कर सकता है। लक्षण यह है कि रिकॉर्ड पैनल में मौजूद है लेकिन सही नाम का लुकअप कुछ नहीं लौटाता। केवल सापेक्ष हिस्सा, selector1._domainkey, दर्ज करें, और apex के लिए पैनल के अनुसार @ का उपयोग करें या फ़ील्ड खाली छोड़ें। ज़ोन फ़ाइलों में अंत का बिंदु आमतौर पर नाम को पूर्ण रूप से योग्य (fully qualified) बताता है, लेकिन वेब पैनल अलग होते हैं, इसलिए सेव किया गया नाम dig से वापस पढ़ें।
कोट्स, लाइन ब्रेक और अदृश्य अक्षर
किसी वेब पेज या दस्तावेज़ से वैल्यू कॉपी करने पर स्मार्ट कोट्स, नॉन-ब्रेकिंग स्पेस या लाइन ब्रेक साथ आ सकते हैं। अगर पैनल भी अपने कोट्स जोड़ता है, तो वैल्यू की शुरुआत में शाब्दिक कोट कैरेक्टर आ सकता है, और जो रिकॉर्ड कोट से शुरू होता है वह v=spf1 या v=DKIM1 से शुरू नहीं होता, इसलिए पहचाना नहीं जाता। पहले किसी सादे टेक्स्ट एडिटर में चिपकाएँ, फिर पैनल में, और परिणाम वापस पढ़ें।
गलत रिकॉर्ड प्रकार या गलत नाम
प्लेटफ़ॉर्म कभी-कभी वहाँ TXT रिकॉर्ड माँगते हैं जहाँ आप CNAME की उम्मीद करते हैं, या इसके उलटा। प्रकार को ठीक वैसा ही इस्तेमाल करें जैसा बताया गया है। यह भी जाँचें कि आप सही ज़ोन में हैं: अगर डोमेन एक प्रदाता के नेमसर्वर इस्तेमाल करता है लेकिन आपने ज़ोन अपने रजिस्ट्रार पर संपादित किया, तो वह संपादन कभी परोसा ही नहीं जाता। पहले दिखाया गया NS लुकअप बताता है कि लाइव ज़ोन कहाँ है।
| पैनल में लक्षण | संभावित कारण | समाधान |
|---|---|---|
| रिकॉर्ड के नाम में डोमेन दो बार दिखता है | पैनल ने पूरे नाम में ज़ोन जोड़ दिया | केवल सापेक्ष नाम दर्ज करें |
| लुकअप आउटपुट में ही वैल्यू के शुरू और अंत में एक-एक कोट कैरेक्टर है | dig के TXT आउटपुट के लिए सामान्य है | किसी बदलाव की ज़रूरत नहीं |
| वैल्यू में एस्केप किए हुए कोट्स हैं या शुरुआत में कोट है | आपने कोट्स जोड़े और पैनल ने भी अपने जोड़े | अपने कोट्स हटाएँ |
| रिकॉर्ड सेव हो गया लेकिन लुकअप कुछ नहीं लौटाता | ऐसे ज़ोन को संपादित किया जिसे लाइव नेमसर्वर नहीं परोसते | NS रिकॉर्ड में बताए प्रदाता पर ज़ोन संपादित करें |
| पैनल नाम में अंडरस्कोर स्वीकार नहीं करता | पैनल में नाम की मान्यता का नियम | दूसरा एडिटर मोड इस्तेमाल करें या DNS प्रदाता से पूछें |
Apex पर CNAME, फ़्लैटनिंग और रिकॉर्ड टकराव
CNAME कहता है कि एक नाम दूसरे नाम का अलियास है, इसलिए रिज़ॉल्वर को उसका अनुसरण करना चाहिए और वहाँ के उत्तर इस्तेमाल करने चाहिए। इसी कारण CNAME उसी नाम पर किसी अन्य रिकॉर्ड के साथ नहीं रह सकता (RFC 1034 और RFC 2181)। आपके डोमेन की जड़, यानी apex, पर SOA और NS रिकॉर्ड होना अनिवार्य है, और आमतौर पर MX और TXT भी होते हैं, इसलिए apex पर CNAME वैध नहीं है।
कुछ DNS प्रदाता फ़्लैटनिंग या अलियास रिकॉर्ड प्रकार से इसका हल निकालते हैं। प्रदाता खुद लक्ष्य को देखता है और apex पर सामान्य address रिकॉर्ड लौटाता है। यह आपके रूट वेब पते को किसी होस्टेड सेवा की ओर इंगित करने के लिए उपयोगी है। ईमेल ऑथेंटिकेशन के लिए यह मदद नहीं करता। अगर कोई प्लेटफ़ॉर्म सबडोमेन जैसे होस्टनाम पर CNAME माँगता है, तो उसे उसी सबडोमेन पर लगाएँ। अगर कोई प्लेटफ़ॉर्म सीधे डोमेन पर CNAME माँगता है, तो उनसे TXT और address रिकॉर्ड जैसा विकल्प माँगें।
टकराव दूसरी तरफ़ से भी होता है। अगर आप ऐसे नाम के लिए CNAME जोड़ते हैं जिस पर पहले से TXT रिकॉर्ड है, उदाहरण के लिए कोई DKIM सेलेक्टर जिसे आपने पहले TXT के रूप में प्रकाशित किया था, तो पैनल के अनुसार उनमें से एक अस्वीकार या अनदेखा कर दिया जाएगा। CNAME जोड़ने से पहले पुराना रिकॉर्ड हटा दें। यह स्थिति प्रदाता बदलते समय आम है, और हमारी माइग्रेशन गाइड चरणों का क्रम बताती है।
डुप्लिकेट SPF रिकॉर्ड और अन्य डुप्लिकेट
एक डोमेन केवल एक SPF रिकॉर्ड प्रकाशित कर सकता है, जो v=spf1 से शुरू होने वाला TXT रिकॉर्ड है। अगर रिसीवर को दो मिलते हैं, तो परिणाम स्थायी त्रुटि होता है (RFC 7208), और SPF हर संदेश के लिए विफल होता है, केवल किसी एक वेंडर के संदेशों के लिए नहीं। ऐसा तब होता है जब दो टीमें अपने-अपने वेंडर द्वारा माँगा गया रिकॉर्ड जोड़ देती हैं।
| स्थिति | रिसीवर को क्या दिखता है | समाधान |
|---|---|---|
| दो TXT रिकॉर्ड, दोनों v=spf1 से शुरू | स्थायी त्रुटि, SPF पास नहीं होता | सभी include मैकेनिज़्म के साथ एक रिकॉर्ड में मिलाएँ |
| एक रिकॉर्ड, 10 से अधिक लुकअप | लुकअप सीमा के बाद स्थायी त्रुटि | include को फ़्लैटन करें या हटाएँ; SPF लुकअप गाइड देखें |
| _dmarc पर दो DMARC रिकॉर्ड | नीति अनदेखी की जा सकती है | एक ही रिकॉर्ड रखें |
| वही सेलेक्टर अलग कुंजियों के साथ दो बार प्रकाशित | कुंजी का चयन अनिश्चित | पुरानी कुंजी हटाएँ या नया सेलेक्टर इस्तेमाल करें |
सिद्धांत रूप में मिलाना सरल है: हर रिकॉर्ड से include और ip4 मैकेनिज़्म लें, उन्हें एक v=spf1 रिकॉर्ड में रखें, और अंत में एक ही all क्वालिफ़ायर लगाएँ। कठिन हिस्सा लुकअप की गिनती है, जिसे हम SPF permerror गाइड और एक डोमेन पर कई वेंडर प्रबंधित करना में समझाते हैं।
प्रॉक्सी किए हुए रिकॉर्ड: मेल के लिए DNS प्रॉक्सी बंद करें
कुछ DNS प्रदाता प्रॉक्सी मोड देते हैं, जो अक्सर रिकॉर्ड के पास रंगीन बादल के आइकन के रूप में दिखता है। इस मोड में प्रदाता उस नाम की क्वेरी का उत्तर अपने पतों से देता है और वेब ट्रैफ़िक को अपने नेटवर्क से गुज़ारता है। वेबसाइटों के लिए यह उपयोगी है और मेल के लिए अनुपयोगी।
अगर मेल से जुड़ा कोई CNAME प्रॉक्सी किया गया है, तो लुकअप अब वह लक्ष्य नहीं लौटाता जिसकी आपके सेंडिंग प्लेटफ़ॉर्म को अपेक्षा है। सत्यापन विफल होता है, ट्रैकिंग या रिटर्न-पाथ होस्टनाम सही सर्वर पर रिज़ॉल्व नहीं होते, और ट्रैकिंग डोमेन के HTTPS सर्टिफ़िकेट जारी नहीं हो पाते। प्रॉक्सी किया हुआ मेल सर्वर होस्टनाम SMTP कनेक्शन बिल्कुल स्वीकार नहीं करेगा, क्योंकि प्रॉक्सी मेल पोर्ट नहीं, वेब पोर्ट संभालता है। इसलिए ईमेल से जुड़े हर रिकॉर्ड को DNS only मोड पर सेट करें: MX लक्ष्य, मेल सर्वर के A रिकॉर्ड, रिटर्न-पाथ और ट्रैकिंग होस्टनामों के CNAME, और DKIM CNAME। TXT रिकॉर्ड कभी प्रॉक्सी नहीं होते, इसलिए वे प्रभावित नहीं होते। हमारी रिटर्न-पाथ और ट्रैकिंग डोमेन की गाइड बताती है कि ये होस्टनाम सीधे प्लेटफ़ॉर्म पर क्यों रिज़ॉल्व होने चाहिए।
जाँच: किसी प्रॉक्सी किए हुए नाम पर dig क्वेरी ऐसे पते लौटाती है जो आपके प्लेटफ़ॉर्म के नहीं हैं, भले ही आपने CNAME सेव किया हो। यह संकेत है कि प्रॉक्सी चालू है।
TTL के विकल्प और बदलाव की योजना
TTL वह सेकंड की संख्या है जितनी देर रिज़ॉल्वर कोई उत्तर रख सकता है। लंबा TTL क्वेरी घटाता है और आपके नेमसर्वर थोड़ी देर उपलब्ध न हों तो रिकॉर्ड को अधिक लचीला बनाता है। छोटा TTL आपको गलती से जल्दी उबरने देता है। समझदारी इसी में है कि चरण के अनुसार इसे बदला जाए।
| चरण | सुझाया गया TTL | क्यों |
|---|---|---|
| नया रिकॉर्ड बनाना या टेस्ट करना | 300 से 600 सेकंड | सुधार जल्दी दिखते हैं |
| नियोजित बदलाव से पहले | बदलाव से काफ़ी पहले TTL घटाएँ, कम से कम मौजूदा TTL जितनी अवधि पहले | स्विच करने से पहले पुराने कैश समाप्त हो जाते हैं |
| बदलाव का दिन | इसे छोटा रखें | आप रोलबैक कर सकते हैं |
| स्थिर रिकॉर्ड | 3600 सेकंड से लेकर एक दिन तक | कम क्वेरी और आउटेज का कम जोखिम |
बदलाव की योजना की मुख्य बात यह है कि TTL घटाने से तुरंत मदद नहीं मिलती। जिन कैश के पास रिकॉर्ड पहले से है वे उसे पुराने TTL तक रखते हैं। अगर किसी रिकॉर्ड का TTL 86400 सेकंड है, तो बदलाव से कम से कम एक दिन पहले उसे घटाएँ। फिर वैल्यू बदलें, इंतज़ार करें, सत्यापित करें और TTL को दोबारा बढ़ाएँ।
प्रोपेगेशन और नेगेटिव कैशिंग
DNS बदलाव किसी एक बिंदु से फैलते नहीं हैं। कोई वैश्विक पुश नहीं होता। जिसे लोग प्रोपेगेशन कहते हैं, वह बस कैश के समाप्त होने में लगने वाला समय है। ज़ोन सेव और लोड होते ही ऑथोरिटेटिव सर्वर नई वैल्यू से उत्तर देते हैं, और हर रिज़ॉल्वर तब स्विच करता है जब उसकी कैश की गई कॉपी समाप्त होती है। कुछ रिज़ॉल्वर बहुत कम TTL को अनदेखा करते हैं या उत्तर थोड़ी देर ज़्यादा रखते हैं, इसलिए कुछ अतिरिक्त समय छोड़ें।
एक दूसरा कैश भी है जिसे भूलना आसान है: नेगेटिव कैश। अगर किसी रिज़ॉल्वर ने ऐसा नाम माँगा जो अभी मौजूद नहीं था, तो वह "नहीं मिला" उत्तर याद रखता है, और RFC 2308 के अनुसार उसका समय SOA रिकॉर्ड पर आधारित होता है (SOA TTL और उसके minimum फ़ील्ड में से छोटा)। अगर आपके प्लेटफ़ॉर्म ने रिकॉर्ड जोड़ने से कुछ मिनट पहले जाँच की थी, तो अब रिकॉर्ड मौजूद होने पर भी विफलता उस समय के खत्म होने तक कैश में रह सकती है।
एक हल किया हुआ उदाहरण
एक ऐसे डोमेन की कल्पना करें जिसका DKIM TXT रिकॉर्ड 10:00 बजे 3600 सेकंड के TTL के साथ प्रकाशित हुआ और जिसका SOA नेगेटिव कैशिंग समय 900 सेकंड है। 10:05 बजे प्लेटफ़ॉर्म बहुत जल्दी जाँचता है और "नहीं मिला" पाता है, इसलिए वह रिज़ॉल्वर विफलता को लगभग 10:20 तक कैश करता है। 10:10 बजे आपको टाइपो दिखता है, आप कुंजी सुधारकर सेव करते हैं। ऑथोरिटेटिव सर्वर अब नया उत्तर देते हैं। जिस रिज़ॉल्वर ने 10:00 बजे पहला रिकॉर्ड कैश किया था वह 11:00 बजे तक पुराना रिकॉर्ड परोस सकता है। जिसने "नहीं मिला" कैश किया था वह 10:20 तक वही परोस सकता है। इसलिए हर रिज़ॉल्वर से पूरी तरह साफ़ परिणाम आने में 11:00 बजे तक लग सकते हैं, लेकिन सीधे ऑथोरिटेटिव सर्वर तक जाने वाली जाँच 10:10 बजे पास हो जाती है। इस स्थिति में आप ऑथोरिटेटिव परिणाम से पुष्टि करते हैं कि आपका संपादन सही है, फिर verify बटन दोबारा दबाने से पहले सबसे लंबे कैश समय, यानी 60 मिनट, का इंतज़ार करते हैं।
जब प्लेटफ़ॉर्म जाँच अपने आप दोहराता है, तो हो सकता है आपको कुछ न करना पड़े। जब वह केवल बटन दबाने पर जाँचता है, तो आपके निकाले हुए सबसे लंबे कैश काल तक इंतज़ार करें। इंतज़ार के दौरान रिकॉर्ड को दोबारा न बदलें, क्योंकि हर बदलाव उन कैश की घड़ी फिर शुरू कर देता है जो रिफ़्रेश होते हैं।
लक्षणों के अनुसार निदान तालिका
| लक्षण | सबसे संभावित कारण | पहली जाँच | समाधान |
|---|---|---|---|
| प्लेटफ़ॉर्म कहता है कि DKIM रिकॉर्ड नहीं मिला | नाम दोहराया गया, गलत ज़ोन, या अभी प्रोपेगेट नहीं हुआ | ऑथोरिटेटिव सर्वर पर सेलेक्टर का सटीक नाम dig करें | होस्ट फ़ील्ड सुधारें या कैश का इंतज़ार करें |
| DKIM सत्यापित होता है लेकिन हस्ताक्षर कुंजी त्रुटि के साथ विफल होता है | कुंजी कट गई या स्पेस के साथ विभाजित हुई | TXT स्ट्रिंग जोड़ें और मूल से तुलना करें | बिना स्पेस के टुकड़ों में फिर से दर्ज करें |
| SPF permerror लौटाता है | दो SPF रिकॉर्ड या 10 से अधिक लुकअप | apex पर TXT को dig करें और v=spf1 रिकॉर्ड गिनें | रिकॉर्ड मिलाएँ, लुकअप घटाएँ |
| SPF रिकॉर्ड अनदेखा होता लगता है | वैल्यू में शाब्दिक कोट या शुरुआती स्पेस | ऐसी वैल्यू खोजें जो v=spf1 से शुरू नहीं होती | अनचाहे अक्षर हटाएँ |
| CNAME सेव होने से मना करता है | उस नाम पर कोई और रिकॉर्ड है, या नाम apex है | उस नाम पर सभी रिकॉर्ड प्रकार सूचीबद्ध करें | टकराव हटाएँ या सबडोमेन इस्तेमाल करें |
| CNAME मौजूद है लेकिन सत्यापन विफल है | DNS प्रॉक्सी चालू है, या लक्ष्य में टाइपो है | क्या dig अपेक्षित लक्ष्य लौटाता है? | DNS only करें, लक्ष्य सुधारें |
| आपके कंप्यूटर पर चलता है, प्लेटफ़ॉर्म पर विफल होता है | रिज़ॉल्वर के अलग कैश | ऑथोरिटेटिव सर्वर और दो सार्वजनिक रिज़ॉल्वर से क्वेरी करें | पुराने TTL का इंतज़ार करें |
| रिकॉर्ड मौजूद है लेकिन जाँच अब भी "नहीं मिला" बताती है | नेगेटिव कैशिंग | SOA वैल्यू और पहली जाँच का समय देखें | नेगेटिव कैश के समय तक इंतज़ार करें |
| DMARC रिपोर्ट में कोई नीति नहीं दिखती | रिकॉर्ड गलत नाम पर है | जाँचें कि नाम _dmarc से शुरू होता है | इसे _dmarc.yourdomain पर ले जाएँ |
हेडर-स्तर की समस्याओं की पुष्टि, रिकॉर्ड-स्तर की समस्याओं की तुलना में, संदेश में ही करना आसान है। DNS सही होने के बाद ऑथेंटिकेशन परिणामों का क्या अर्थ है, यह जानने के लिए ईमेल हेडर कैसे पढ़ें देखें।
एक व्यावहारिक प्रक्रिया जिसे आप दोहरा सकते हैं
- पहचानें। आपके प्लेटफ़ॉर्म द्वारा माँगा गया सटीक नाम और प्रकार लिख लें।
- खोजें। NS लुकअप से लाइव नेमसर्वर खोजें और पुष्टि करें कि आप उसी ज़ोन को संपादित कर रहे हैं।
- दर्ज करें। सापेक्ष होस्ट नाम इस्तेमाल करें, वैल्यू बिना अतिरिक्त कोट्स के चिपकाएँ, और लंबी स्ट्रिंग को तभी विभाजित करें जब आपके पैनल को इसकी ज़रूरत हो।
- वापस पढ़ें। ऑथोरिटेटिव सर्वर से क्वेरी करें और परिणाम की मूल से तुलना करें।
- सफ़ाई करें। डुप्लिकेट, उसी नाम वाले पुराने सेलेक्टर, और टकराने वाले रिकॉर्ड प्रकार हटाएँ।
- प्रॉक्सी बंद। पुष्टि करें कि मेल से जुड़े रिकॉर्ड DNS only पर सेट हैं।
- समझदारी से इंतज़ार करें। पुराने TTL और नेगेटिव कैशिंग समय में से जो लंबा हो उसकी गणना करें।
- सत्यापित करें। प्लेटफ़ॉर्म की जाँच चलाएँ और एक टेस्ट संदेश भेजें। प्रकाशित करने के लिए सटीक रिकॉर्ड नाम और वैल्यू के लिए अपना MigoSMTP अकाउंट या API दस्तावेज़ देखें।
मदद माँगने से पहले की चेकलिस्ट
- रिकॉर्ड का नाम ऑथोरिटेटिव नेमसर्वर से वापस पढ़ा गया है और ठीक वही है जो प्लेटफ़ॉर्म ने माँगा था।
- स्टोर किए गए नाम में कोई डोमेन प्रत्यय दो बार नहीं दिखता।
- वैल्यू में कोई चिपके हुए कोट्स, लाइन ब्रेक या लंबी कुंजियों के अंदर स्पेस नहीं हैं।
- स्ट्रिंग जोड़ने पर लंबी TXT वैल्यू पूरी मौजूद हैं।
- नाम पर केवल एक SPF रिकॉर्ड है, और लुकअप गिनती सीमा के भीतर है।
- कोई CNAME किसी अन्य रिकॉर्ड के साथ नाम साझा नहीं करता, और apex पर कोई CNAME नहीं है।
- मेल से जुड़ा हर रिकॉर्ड DNS only पर सेट है, प्रॉक्सी नहीं।
- दोबारा जाँचने से पहले आपने पुराने TTL और नेगेटिव कैशिंग समय का इंतज़ार किया है।
- आपने जिस ज़ोन को संपादित किया वही है जिसकी ओर NS रिकॉर्ड इशारा करते हैं।
किसी ऐसे रिकॉर्ड पर अटके हैं जो सत्यापित नहीं हो रहा? हमें रिकॉर्ड का नाम, आपकी प्रकाशित की हुई सटीक वैल्यू, और अपने ऑथोरिटेटिव नेमसर्वर के विरुद्ध dig क्वेरी का आउटपुट भेजें, और हम अंतर खोजने में आपकी मदद करेंगे।
आगे पढ़ने के लिए और स्रोत
अक्सर पूछे जाने वाले प्रश्न
मेरा DKIM रिकॉर्ड "बहुत लंबा" क्यों बता रहा है?
एक DNS कैरेक्टर-स्ट्रिंग में अधिकतम 255 बाइट आ सकते हैं, और base64 में 2048-बिट RSA पब्लिक की इससे लंबी होती है। रिकॉर्ड में कई स्ट्रिंग हो सकती हैं, और रिसीवर उन्हें बिना स्पेस के जोड़ लेते हैं। कुछ पैनल वैल्यू को अपने आप विभाजित कर देते हैं, कुछ आपसे कोट किए हुए टुकड़े माँगते हैं, और कुछ लंबी वैल्यू को सीधे अस्वीकार कर देते हैं। देखें कि आपका पैनल इसे कैसे संभालता है और TXT लुकअप से परिणाम की पुष्टि करें।
क्या मुझे अपनी TXT वैल्यू के चारों ओर कोट्स लगाने चाहिए?
यह पैनल पर निर्भर करता है। कई वेब फ़ॉर्म कोट्स खुद जोड़ देते हैं, इसलिए आप अपने कोट्स लगाएँ तो वैल्यू में शाब्दिक कोट कैरेक्टर आ जाता है और रिकॉर्ड पार्स नहीं होता। ज़ोन फ़ाइल एडिटर और कुछ कमांड लाइन टूल कोट्स की अपेक्षा रखते हैं। सेव करने के बाद रिकॉर्ड को dig से वापस पढ़ें, और अगर दोहरे या एस्केप किए हुए कोट्स दिखें तो अपने कोट्स हटा दें।
मेरा रिकॉर्ड selector._domainkey.example.com.example.com क्यों बन गया?
पैनल होस्ट फ़ील्ड में आप जो भी लिखते हैं उसके आगे आपका डोमेन जोड़ देता है। अगर आप पूरा नाम लिखते हैं, तो डोमेन दो बार जुड़ जाता है। केवल आपके डोमेन से पहले वाला हिस्सा लिखें, जैसे selector._domainkey, या पैनल में दिया गया संकेत अपनाएँ। अंत में बिंदु (.) आमतौर पर पैनल को बताता है कि नाम पूरा है, लेकिन हर पैनल इसे इस तरह नहीं मानता, इसलिए लुकअप से जाँच करें।
क्या मैं अपने रूट डोमेन पर CNAME लगा सकता हूँ?
मानक DNS इसकी अनुमति नहीं देता, क्योंकि CNAME किसी नाम पर अन्य रिकॉर्ड के साथ नहीं रह सकता और रूट डोमेन पर SOA तथा NS रिकॉर्ड होना अनिवार्य है। कुछ प्रदाता फ़्लैटनिंग या अलियास सुविधा देते हैं जो रूट पर address रिकॉर्ड लौटाती है। ज़रूरत हो तो इसे वेब ट्रैफ़िक के लिए इस्तेमाल करें, लेकिन रूट पर ईमेल के लिए आवश्यक TXT और MX रिकॉर्ड के विकल्प के रूप में इसका उपयोग न करें।
मेरे पास दो SPF रिकॉर्ड हैं। क्या यह सच में समस्या है?
हाँ। एक डोमेन को केवल एक ही SPF रिकॉर्ड प्रकाशित करना चाहिए, और एक से अधिक मिलने पर रिसीवर उनमें से किसी एक को चुनने के बजाय स्थायी त्रुटि लौटाते हैं। सभी मैकेनिज़्म को एक ही रिकॉर्ड में मिला दें। लुकअप सीमा पार किए बिना यह कैसे करें, यह हमारी "एक डोमेन पर कई वेंडर" वाली गाइड में समझाया गया है।
TTL कितना रखना चाहिए?
रिकॉर्ड बनाते या बदलते समय 300 से 3600 सेकंड जैसा छोटा TTL रखें, और जब सब कुछ स्थिर हो जाए तो कई घंटे से एक दिन तक का लंबा TTL रखें। सही संख्या इस संतुलन पर निर्भर करती है कि आप कितनी तेज़ी से रोलबैक कर सकते हैं और आपके नेमसर्वर पर कितना लोड पड़ता है।
मैंने रिकॉर्ड ठीक कर दिया, फिर भी जाँच विफल हो रही है। क्यों?
या तो कोई रिज़ॉल्वर अपना TTL खत्म होने तक पुराना उत्तर पकड़े हुए है, या वह नेगेटिव कैशिंग का समय खत्म होने तक कैश किया हुआ "नहीं मिला" उत्तर पकड़े हुए है, या आप उससे अलग नाम जाँच रहे हैं जिसे प्लेटफ़ॉर्म देखता है। सच्चाई जानने के लिए ऑथोरिटेटिव नेमसर्वर से क्वेरी करें, फिर कैश के खत्म होने का इंतज़ार करें।
मेल CNAME प्रॉक्सी क्यों नहीं होने चाहिए?
DNS प्रॉक्सी आपके रिकॉर्ड के असली लक्ष्य की जगह अपने पतों से क्वेरी का उत्तर देता है। मेल प्लेटफ़ॉर्म को CNAME का लक्ष्य या असली सर्वर का पता दिखना ज़रूरी है, इसलिए प्रॉक्सी किया हुआ रिकॉर्ड सत्यापन में विफल होता है और ट्रैकिंग या बाउंस हैंडलिंग को बिगाड़ सकता है। ऐसे रिकॉर्ड को DNS only पर सेट करें।
मुझे किस पर भरोसा करना चाहिए: dig, nslookup या वेब चेकर?
अगर आप जानते हैं कि वे क्या पूछते हैं, तो सभी ठीक हैं। dig और nslookup में आप सर्वर चुन सकते हैं, और यही प्रकाशन की समस्या को कैशिंग की समस्या से अलग करने की कुंजी है। वेब चेकर आमतौर पर किसी एक स्थान से सार्वजनिक रिज़ॉल्वर के ज़रिए क्वेरी करते हैं, इसलिए आपके लोकल परिणाम से अंतर का अर्थ अक्सर बस अलग कैश होता है।