Defaults.Exposed › सुधार › रिवर्स DNS (PTR)

रिवर्स DNS (PTR) को कैसे ठीक करें

रिवर्स DNS आपके व्यवसायिक ईमेल भेजने वाले सर्वर के लिए ID बैज है। जब Gmail या Microsoft 365 जैसा प्राप्तकर्ता प्रदाता देखता है कि भेजने वाले पते के पीछे कौन है और नाम जाँचता है, तो आपका मेल वैध दिखता है। जब कोई बैज नहीं होता — या नाम और नंबर सहमत नहीं होते — तो आपके पूरी तरह वास्तविक चालान और उद्धरण संदिग्ध माने जाते हैं और चुपचाप फेंके या अस्वीकार किए जाते हैं।

आपके व्यवसाय के लिए मुख्य बात: आपके चालान, उद्धरण और ग्राहक उत्तर चुपचाप स्पैम में आते हैं या कभी नहीं आते — इसलिए सौदे रुक जाते हैं, भुगतान देर से आते हैं, और ग्राहकों को लगता है आपने उन्हें अनदेखा किया, जिनमें से कोई भी आपके लिए किसी त्रुटि के रूप में नहीं दिखता।

यह आपको क्या खर्च कर सकता है

आप एक गर्म संभावित ग्राहक को एक उद्धरण भेजते हैं, वह उनके स्पैम में चला जाता है, और वे उस प्रतिस्पर्धी के साथ जाते हैं जिसने 'वास्तव में जवाब दिया' — और आपको पता ही नहीं चलता कि ईमेल पहुँचा नहीं।
ग्राहकों के लिए चालान जंक में चले जाते हैं, भुगतान हफ्तों देर से आते हैं, और आपके नकदी प्रवाह को नुकसान होता है क्योंकि कोई भी ईमेल कभी नहीं देखा।
एक ग्राहक शिकायत करता है कि आपने उनके सवाल का जवाब कभी नहीं दिया — लेकिन आपने दिया था; उनके मेल प्रदाता ने आपका उत्तर चुपचाप फेंक दिया क्योंकि आपका भेजने वाला सर्वर साबित नहीं कर सका कि वह कौन था।
आपका डोमेन बाकी सब पर एक नए क्लाइंट की सुरक्षा समीक्षा में पास हो जाता है, फिर इसलिए फ्लैग किया जाता है क्योंकि आपके मेल सर्वर की कोई उचित पहचान नहीं है — एक छोटी सी बात जो आपको लापरवाह दिखाती है।
आप अपने न्यूज़लेटर और चालान भेजने के लिए एक सस्ते VPS या एक नए ऐप पर गए, और रात भर में आपकी डिलीवरी दर गिर गई — क्योंकि उस नए भेजने वाले सर्वर में कोई रिवर्स-DNS बैज नहीं है और बड़े प्रदाता अब इस पर भरोसा नहीं करते।

यह क्यों मायने रखता है। हर प्रमुख ईमेल प्रदाता आपका मेल भेजने वाले सर्वर की पहचान जाँचता है, और वे इसे हर संदेश पर जाँचते हैं। यदि वह सर्वर साबित नहीं कर सकता कि वह कौन है — या यदि उसका नाम और उसकी संख्या एक-दूसरे का खंडन करती है — तो आपका वास्तविक व्यावसायिक ईमेल स्पैम की तरह संभाला जाता है। आप उत्तर, भुगतान और विश्वास खोते हैं, और क्योंकि कुछ भी बाउंस नहीं होता, आपको आमतौर पर पता ही नहीं चलता।

संक्षिप्त संस्करण

जब आपका व्यवसाय एक ईमेल भेजता है, तो यह एक मेल सर्वर से निकलता है, और इंटरनेट पर हर सर्वर का एक संख्यात्मक पता होता है — उसका IP। रिवर्स DNS (एक “PTR रिकॉर्ड”) उस सर्वर का नाम बैज है: यह किसी को भी संख्या देखकर उसके पीछे के उचित नाम को खोजने देता है, जैसे mail.yourcompany.com।

बड़े प्राप्त करने वाले प्रदाता — Gmail, Microsoft 365, Yahoo — आपके भेजे हर संदेश पर उस बैज की जाँच करते हैं। एक सर्वर जो खुद का नाम बता सकता है, और जहाँ नाम और संख्या एक-दूसरे से सहमत हैं, एक वैध मेल सर्वर की तरह दिखता है। बिना बैज वाला सर्वर, या बैज जो मेल नहीं खाता, ठीक उन गुमनाम, अस्थायी मशीनों की तरह दिखता है जो स्पैमर उपयोग करते हैं। इसलिए आपके वास्तविक चालान और उद्धरण हर बातचीत संदेह के साथ शुरू करते हैं — और उनमें से बहुत सारे हार जाते हैं।

निराशाजनक हिस्सा यह है कि कुछ भी आपको नहीं बताता कि यह हो रहा है। कोई बाउंस नहीं, कोई त्रुटि नहीं। आपका ईमेल बस चुपचाप खराब प्रदर्शन करता है।

इससे आपको क्या नुकसान हो सकता है

ये हर दिन के तरीके हैं जिनसे गायब या मेल न खाने वाला रिवर्स-DNS रिकॉर्ड पैसे और विश्वास के नुकसान में बदलता है। हम कभी किसी वास्तविक व्यवसाय का नाम नहीं लेते — ये डेटा में हमें दिखने वाले पैटर्न हैं।

वह उद्धरण जो कभी नहीं पहुँचा। आप उस सुबह उद्धरण मांगने वाले एक संभावित ग्राहक को एक विस्तृत उद्धरण ईमेल करते हैं। उनका प्रदाता आपके भेजने वाले सर्वर को सत्यापित नहीं कर सकता, इसलिए संदेश स्पैम में डाल देता है। वे जंक खंगालते नहीं। दोपहर तक वे प्रतिस्पर्धी का उद्धरण ले चुके हैं — वह जो “वास्तव में दिखा।” आप इसे एक धीमे लीड के रूप में समझाते हैं; वास्तव में आपका ईमेल कभी देखा ही नहीं गया।
शून्य में चालान। आप एक अच्छे ग्राहक को चालान करते हैं। यह उनके जंक फ़ोल्डर में जाता है। तीस दिन बाद आप एक भुगतान का पीछा कर रहे हैं जो उनकी किसी गलती के बिना अतिदेय है — और अब एक अजीब बातचीत है, एक तनावपूर्ण रिश्ता, और एक नकदी-प्रवाह अंतर जो पूरी तरह से टाला जा सकता था।
“आपने कभी जवाब नहीं दिया।” एक ग्राहक नाराज है कि आपने उनके सवाल को अनदेखा किया। आपने नहीं किया — आपने उसी दिन जवाब दिया। उनके मेल प्रदाता ने आपके उत्तर को चुपचाप फेंक दिया क्योंकि आपका भेजने वाला सर्वर अविश्वसनीय लगा। आप किसी ऐसी चीज़ के लिए अव्यावसायिक दिखते हैं जो आपने वास्तव में सही किया।
DIY भेजने वाला सर्वर जिसने सब कुछ चुपचाप जहर दिया। पैसे बचाने के लिए, आपका मेल (या बस आपके न्यूज़लेटर और स्वचालित चालान) एक सस्ते VPS या एक नए भेजने वाले ऐप के माध्यम से जाने लगा। उस सर्वर को कभी रिवर्स-DNS बैज नहीं मिला। रात भर में, आपकी डिलीवरी दर सब में गिर गई — और क्योंकि कोई त्रुटि संदेश नहीं था, कारण का संदेह करने में महीने लग गए।
सुरक्षा-समीक्षा फ्लैग। एक बड़े क्लाइंट की IT टीम ऑनबोर्डिंग के दौरान आपके डोमेन पर एक रूटीन जाँच चलाती है। बाकी सब ठीक है, लेकिन आपके मेल सर्वर की कोई उचित पहचान नहीं है। यह एक छोटी तकनीकी बात है, लेकिन यह लापरवाही के रूप में पढ़ी जाती है — और अब आप डेडलाइन के दबाव में इसे ठीक कर रहे हैं, या इसे समझा रहे हैं, जबकि एक प्रतिस्पर्धी का डोमेन बस आसानी से निकल गया।

इन सभी में एक धागा: लागत आप पर पड़ती है, यह होने के दौरान अदृश्य है, और ठीक करना मुफ्त है।

यह वास्तव में क्या है

सामान्य DNS एक नाम को एक संख्या में बदलता है: आप yourcompany.com टाइप करते हैं, और DNS कनेक्ट होने के लिए IP पता वापस देता है। रिवर्स DNS विपरीत करता है — यह एक संख्या को वापस एक नाम में बदलता है। IP 203.0.113.10 को दिए जाने पर, एक रिवर्स लुकअप (एक “PTR रिकॉर्ड”) mail.yourcompany.com का जवाब देता है।

प्राप्तकर्ता क्यों परवाह करते हैं: जब आपका मेल सर्वर एक संदेश डिलीवर करने के लिए Gmail से जुड़ता है, Gmail कनेक्टिंग IP देखता है। एक गंभीर मेल फ़िल्टर सबसे पहले जो करता है वह है “यह मशीन कौन है?” — उस IP पर रिवर्स लुकअप करके। एक वास्तविक व्यावसायिक मेल सर्वर का जवाब होता है (mail.yourcompany.com)। एक डिस्पोजेबल स्पैम मशीन का आमतौर पर नहीं होता, या एक सामान्य प्रदाता-निर्धारित नाम होता है जैसे host-203-0-113-10.someisp.net। इसलिए बैज की उपस्थिति और गुणवत्ता आपके मेल पर लागू पहले विश्वास संकेतों में से एक है — SPF, DKIM, या संदेश सामग्री के देखे जाने से भी पहले।

यह आपकी वेबसाइट नहीं, मेल सर्वर की जाँच करता है। यह लोगों को भ्रमित करता है। आपकी वेबसाइट का पता अक्सर एक CDN या प्रॉक्सी (जैसे Cloudflare) के पीछे होता है और कभी एक मिलान बैज नहीं होगा — और यह ठीक है, क्योंकि ईमेल के लिए रिवर्स DNS MX मेल सर्वर के IP के बारे में है, एक पूरी तरह से अलग मशीन। यह जाँच सही ढंग से आपके डोमेन के प्राथमिक मेल सर्वर (सबसे कम प्राथमिकता MX रिकॉर्ड) को देखती है, इसे अपने IP पर हल करती है, और उस IP पर बैज जाँचती है।

वह आधा जो अधिकांश सेटअप गलत पाते हैं: इसे दोनों दिशाओं में मेल खाना होगा। अकेले नाम होना पर्याप्त नहीं है। Gmail और अन्य बड़े फ़िल्टर कुछ अधिक सख्त करते हैं, जिसे फॉरवर्ड-कन्फर्म्ड रिवर्स DNS (FCrDNS) कहते हैं:

IP खोजें → एक नाम पाएं (जैसे mail.yourcompany.com)।
अब उस नाम को वापस खोजें → इसे उसी IP पर हल होना चाहिए जिससे आपने शुरू किया था।

यदि दोनों दिशाएं सहमत हैं, तो सर्वर पुष्टि और पूरी तरह विश्वसनीय है। यदि कोई नाम है लेकिन यह कहीं और (या कहीं नहीं) इंगित करता है, तो सर्वर केवल आधा-भरोसेमंद है।

यही बात इस जाँच को स्कोर करती है:

फॉरवर्ड-कन्फर्म्ड (FCrDNS): IP एक होस्ट का नाम देता है, और वह होस्ट उसी IP पर वापस इंगित करता है। पूर्ण अंक — यह सही कॉन्फ़िगरेशन है।
बैज मौजूद है लेकिन पुष्टि नहीं होती: एक PTR रिकॉर्ड है, लेकिन नाम मेल सर्वर के IP पर वापस हल नहीं होता। आंशिक क्रेडिट केवल।
कोई बैज नहीं: मेल सर्वर के IP पर कोई PTR रिकॉर्ड नहीं। कोई क्रेडिट नहीं।

इसे कैसे ठीक करें (मुफ्त, किसी के ~10 मिनट)

इस अनुभाग को उन लोगों को सौंपें जो आपके मेल सर्वर के IP पते के मालिक हैं — आमतौर पर आपका ईमेल या होस्टिंग प्रदाता, या स्व-होस्टेड बॉक्स के लिए आपका डेटा-सेंटर — और ध्यान दें कि ठीक करना मुफ्त है। यह एक ईमेल सेटिंग है जिसे आप लगभग निश्चित रूप से अपने सामान्य DNS पैनल में स्वयं नहीं बदल सकते, क्योंकि रिवर्स DNS उस व्यक्ति द्वारा नियंत्रित होता है जो IP का मालिक है, न कि वह जो डोमेन का मालिक है।

चरण 1 — भेजने वाले मेल सर्वर का IP खोजें।

dig MX yourcompany.com        # प्राथमिक (सबसे कम-प्राथमिकता) MX होस्ट खोजें
dig A mail.yourcompany.com    # उस होस्ट को उसके IP पर हल करें

उस IP को बैज की जरूरत है। वेबसाइट का IP उपयोग न करें — यह एक अलग मशीन है।

चरण 2 — IP मालिक से PTR रिकॉर्ड सेट करने के लिए कहें।

Google Workspace / Gmail: Google के अपने मेल सर्वरों के लिए स्वचालित रूप से प्रबंधित — यदि Google के माध्यम से ही भेजने वाला डोमेन किसी तरह विफल दिखता है, तो Google सपोर्ट के साथ उठाएं।
Microsoft 365: Microsoft के सर्वरों के लिए समान रूप से स्वचालित रूप से प्रबंधित।
स्व-होस्टेड या VPS मेल सर्वर: अपने होस्टिंग प्रदाता या डेटा-सेंटर को एक टिकट खोलें जिसमें उनसे आपके IP के PTR (रिवर्स DNS) को आपके मेल होस्टनाम पर सेट करने के लिए कहें।
तृतीय-पक्ष भेजने वाला ऐप: यदि यह अपने साझा सर्वरों से भेजता है, तो प्रदाता रिवर्स DNS संभालता है — आपके लिए सेट करने के लिए कुछ नहीं है।

उन्हें वह रिकॉर्ड बताएं जो आप चाहते हैं, उदाहरण के लिए: 203.0.113.10 → mail.yourcompany.com।

चरण 3 — इसे फॉरवर्ड-कन्फर्म बनाएं (यह वह चरण है जिसे अधिकांश लोग छोड़ देते हैं)।

PTR कहता है 203.0.113.10 → mail.yourcompany.com (आपका प्रदाता यह सेट करता है)।
A रिकॉर्ड कहता है mail.yourcompany.com → 203.0.113.10 (आप इसे अपने DNS में सेट करते हैं)।

दोनों दिशाओं को एक-दूसरे पर इंगित करना होगा। केवल तभी यह फॉरवर्ड-कन्फर्म्ड और पूरी तरह विश्वसनीय है।

चरण 4 — अपना डोमेन फिर से जाँचें।

सामान्य गलतियाँ

मेल सर्वर के बजाय वेबसाइट के IP पर बैज सेट करना। ईमेल के लिए रिवर्स DNS MX सर्वर के बारे में है।
“PTR मौजूद है” पर रुकना। अकेले एक नाम केवल आंशिक विश्वास अर्जित करता है।
प्रदाता द्वारा PTR सेट करने के बाद A रिकॉर्ड भूलना। प्रदाता रिवर्स आधा सेट करता है; आपको अपने DNS में फॉरवर्ड आधा सेट करना होगा।
गलत पार्टी से पूछना। डोमेन रजिस्ट्रार या DNS होस्ट को अनुरोध भेजना IP मालिक के बजाय “हम ऐसा नहीं कर सकते” देता है।
सामान्य प्रदाता होस्टनाम। host-203-0-113-10.someisp.net जैसा PTR तकनीकी रूप से मौजूद है लेकिन आपके ब्रांड या विश्वास के लिए कुछ नहीं करता।

यह कहाँ फिट बैठता है

रिवर्स DNS सर्वर की पहचान है; SPF, DKIM और DMARC डोमेन का प्राधिकरण और एंटी-इम्पर्सनेशन लेयर है। वे अलग-अलग सवालों के जवाब देते हैं, और बड़े प्रदाता उन सभी की जाँच करते हैं। SPF सूचीबद्ध करता है कि कौन सी सेवाएं आपके रूप में भेज सकती हैं; DKIM क्रिप्टोग्राफ़िक रूप से आपके संदेशों पर हस्ताक्षर करता है; DMARC दोनों को एक साथ बांधता है और प्राप्तकर्ताओं को बताता है कि विफल मेल के साथ क्या करना है। रिवर्स DNS इन सभी के नीचे बैठता है, यह प्रमाणित करते हुए कि भेजने वाली मशीन एक वास्तविक, नामित मेल सर्वर है। हर एक ये ठीक करना मुफ्त है।

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

मैं तकनीकी नहीं हूँ — क्या मैं इसे स्वयं संभाल सकता हूँ?

आमतौर पर नहीं, और यह ठीक है। अधिकांश ईमेल सेटिंग के विपरीत, यह आपके अपने डोमेन के DNS में नहीं बदला जाता — यह उस व्यक्ति द्वारा सेट किया जाता है जो आपके मेल सर्वर के इंटरनेट पते (IP) का मालिक है, जो आपका ईमेल या होस्टिंग प्रदाता है। आपका काम बस उन्हें 'इसे कैसे ठीक करें' अनुभाग अग्रेषित करना है। यह उनकी तरफ से एक त्वरित परिवर्तन है, और यह मुफ्त है।

यदि मैं Google Workspace या Microsoft 365 उपयोग करता हूँ, तो क्या मैं पहले से कवर हूँ?

लगभग निश्चित रूप से हाँ — दोनों अपने स्वयं के मेल सर्वरों के लिए रिवर्स DNS स्वचालित रूप से प्रबंधित करते हैं, इसलिए उनके माध्यम से ही भेजने वाला डोमेन बिना कुछ किए पास करता है। यदि हमारी जाँच अभी भी इसे फ्लैग करती है, तो इसका मतलब लगभग हमेशा होता है कि आपका कुछ मेल एक अलग सर्वर के माध्यम से जाता है (आपका अपना बॉक्स, एक सस्ता VPS, या एक तृतीय-पक्ष भेजने वाला ऐप), और वही सर्वर है जिसमें इसका बैज गायब है।

क्या इसे ठीक करने से मेरा ईमेल टूट सकता है?

नहीं। यह केवल भेजने वाले सर्वर की पहचान रिकॉर्ड जोड़ता या सही करता है — यह नहीं बदलता कि आपका मेल कहाँ जाता है, इसे भेजने की अनुमति किसे है, या आपके इनबॉक्स की कोई सेटिंग। यह बस आपके पहले से भेजे गए ईमेल को अधिक भरोसेमंद और डिलीवर होने की संभावना बनाता है।

इसके और SPF, DKIM और DMARC के बीच क्या अंतर है?

वे तीन सवाल का जवाब देते हैं 'क्या यह डोमेन इस संदेश को भेजने की अनुमति है?' रिवर्स DNS एक अलग, पहले के सवाल का जवाब देता है: 'क्या भेजने वाली मशीन एक वास्तविक, पहचान योग्य मेल सर्वर है, या एक गुमनाम बॉक्स?' बड़े प्रदाता दोनों की जाँच करते हैं। आप उन सभी को सही चाहते हैं — लेकिन रिवर्स DNS वह है जो एक ब्रांड-नए या स्व-होस्टेड भेजने वाले सर्वर को SPF और DKIM के भी खेलने का मौका मिलने से पहले पकड़ता है।

हमारे पास एक रिवर्स-DNS रिकॉर्ड है लेकिन जाँच अभी भी पूरी तरह पास नहीं होती — क्यों?

क्योंकि एक नाम होना पर्याप्त नहीं है; नाम को दोनों दिशाओं में जाँचना होता है। बैज कहता है सर्वर को, मान लीजिए, mail.yourcompany.com कहा जाता है — लेकिन Gmail फिर उस नाम को खोजता है और उम्मीद करता है कि वह ठीक उसी IP पर वापस इंगित करे जिससे वे शुरू हुए थे। यदि यह नहीं करता (या कहीं और इंगित करता है), तो प्रदाता इसे अपुष्ट मानते हैं और केवल आधा भरोसा करते हैं। यह दो-दिशा मेल को फॉरवर्ड-कन्फर्म्ड रिवर्स DNS कहा जाता है, और यह वह हिस्सा है जिसे अधिकांश सेटअप याद करते हैं।

क्या ठीक करना वास्तव में मुफ्त है, या यह एक पेड अपसेल है?

ठीक करना हमेशा मुफ्त होता है — यह आपके प्रदाता द्वारा किया गया एक छोटा कॉन्फ़िगरेशन परिवर्तन है, न कि कोई उत्पाद जो आप खरीदते हैं। जो कोई भी आपको बताता है कि रिवर्स DNS सेट अप करने के लिए एक पेड प्लान की आवश्यकता है वह गलत है। हम केवल यह निगरानी करने के लिए शुल्क लेते हैं कि यह समय के साथ सही रहे, कभी भी बदलाव करने के लिए नहीं।