Defaults.Exposed › सुधार › MX रिकॉर्ड (मेल सेटअप)
MX रिकॉर्ड (मेल सेटअप) को कैसे ठीक करें
MX रिकॉर्ड वह संकेतक है जो दुनिया को बताता है कि आपके डोमेन पर भेजे गए ईमेल कहाँ डिलीवर करने हैं। अगर यह गायब है या टूटा हुआ है, तो आपके व्यवसाय पर भेजा गया हर संदेश — ग्राहक पूछताछ, पासवर्ड रीसेट, चालान, अनुबंध — सीधे प्रेषक के पास वापस उछल जाता है। कोई MX नहीं, कोई इनबॉक्स नहीं।
आपके व्यवसाय के लिए मुख्य बात: यदि आपके MX रिकॉर्ड गायब या गलत हैं, तो आपका डोमेन बिल्कुल भी ईमेल प्राप्त नहीं कर सकता। जो ग्राहक आपको लिखते हैं उन्हें एक त्रुटि मिलती है और वे मान लेते हैं कि आप उन्हें अनदेखा कर रहे हैं या बंद हो गए हैं। आप संदेश कभी नहीं देखते — जिनमें सौदे, चालान और जरूरी समस्याएं भी शामिल हैं जिन पर जवाब की जरूरत थी।
यह आपको क्या खर्च कर सकता है
- एक संभावित ग्राहक आपके 'हमसे संपर्क करें' फ़ॉर्म को भरता है या आपके कार्ड पर दिए पते पर ईमेल करता है। संदेश उछल जाता है। वे दोबारा कोशिश नहीं करते — वे किसी प्रतिस्पर्धी के पास जाते हैं, और आपको पता ही नहीं चलता कि पूछताछ हुई थी।
- एक आपूर्तिकर्ता एक अतिदेय चालान और अंतिम नोटिस ईमेल करता है। दोनों चुपचाप उछल जाते हैं। आपको पहली बार तब पता चलता है जब कोई सेवा बंद हो जाती है या ऋण-वसूली पत्र आता है।
- आप एक नए टूल, बैंक पोर्टल, या सरकारी सेवा के लिए साइन अप करते हैं और वह आपके डोमेन पर एक सत्यापन या पासवर्ड-रीसेट ईमेल भेजता है। वह कभी नहीं आता, और आप किसी चीज़ से लॉक हो जाते हैं जिसकी आपको आज जरूरत है।
- ईमेल ठीक काम करता था, फिर किसी ने वेबसाइट को स्थानांतरित करते समय DNS बदल दिया और MX रिकॉर्ड गिरा दिए। दिनों तक, पूरी कंपनी का हर ईमेल चुपचाप गायब होता रहा जब तक किसी ने नोटिस नहीं किया कि इनबॉक्स शांत हो गया है।
- एक संभावित प्रतिरूपणकर्ता देखता है कि आपके डोमेन में कोई मेल सेटअप और कोई सुरक्षा नहीं है, और उसका उपयोग करना शुरू कर देता है — क्योंकि एक डोमेन जिसे कोई नहीं देख रहा वह दुरुपयोग करने में सबसे आसान है।
यह क्यों मायने रखता है। ईमेल डिलीवरी एक एकल DNS लुकअप पर निर्भर करती है: एक भेजने वाला मेल सर्वर पूछता है 'मैं इस डोमेन के लिए मेल कहाँ डिलीवर करूँ?' और आपके MX रिकॉर्ड से उत्तर पढ़ता है। यदि कोई उत्तर नहीं है, या वह कहीं नहीं इंगित करता, तो मेल अस्वीकार और उछाल दी जाती है। यह ईमेल प्लंबिंग का सबसे बुनियादी, सब-या-कुछ नहीं टुकड़ा है — जब यह गलत होता है, तो आपके ईमेल के बारे में बाकी कुछ भी मायने नहीं रखता, क्योंकि कुछ भी नहीं आता। (एकमात्र वैध अपवाद वह डोमेन है जो जानबूझकर कोई ईमेल प्राप्त न करने के लिए स्थापित किया गया है, जिसका अपना सही कॉन्फ़िगरेशन है।)
MX रिकॉर्ड क्या हैं, सरल शब्दों में
जब कोई आपके डोमेन पर किसी को ईमेल भेजता है, तो भेजने वाले मेल सर्वर को पहले एक सवाल का जवाब देना होता है: “मैं इस डोमेन के लिए मेल कहाँ डिलीवर करूँ?” यह आपके डोमेन के MX रिकॉर्ड — Mail eXchange के लिए संक्षिप्त — देखकर उत्तर पाता है। एक MX रिकॉर्ड बस आपके डोमेन की सेटिंग में एक संकेतक है जो कहता है “इस डोमेन के लिए ईमेल इस मेल सर्वर पर भेजें।”
यही पूरा काम है। MX रिकॉर्ड आपका ईमेल स्टोर नहीं करते, वे इसे सुरक्षित नहीं करते, और वे तय नहीं करते कि आपके नाम से भेजने की अनुमति किसे है। वे लिफाफे पर वह पता हैं जो डाक प्रणाली को बताता है कि कौन सा सॉर्टिंग कार्यालय आपका मेल संभालता है। पता सही करें और मेल आता है। इसे खाली छोड़ें या इसे गलत इमारत पर इंगित करें और मेल अडिलिवरेबल चिह्नित होकर सीधे वापस आता है।
यह ईमेल सेटअप का सबसे बुनियादी टुकड़ा है। हर अन्य ईमेल नियंत्रण — एंटी-स्पूफिंग, एन्क्रिप्शन, स्पैम फ़िल्टरिंग — यह मानता है कि मेल वास्तव में आप तक पहुँच सकता है। MX रिकॉर्ड इसे सत्य बनाते हैं।
इससे आपको क्या नुकसान हो सकता है
क्योंकि टूटा हुआ MX रिकॉर्ड आपके लिए चुपचाप विफल होता है — आप बस मेल प्राप्त करना बंद कर देते हैं, आपके अंत में कोई त्रुटि नहीं — नुकसान आमतौर पर देर से खोजा जाता है, जब यह पहले से हो चुका होता है। कुछ वास्तविक स्थितियाँ:
-
वह पूछताछ जो आप तक कभी नहीं पहुँची। एक संभावित ग्राहक आपकी वेबसाइट पर दिए पते पर ईमेल करता है। उनके लिए, संदेश डिलीवरी-विफलता नोटिस के साथ उछलता है; आपके लिए, कुछ नहीं होता। अधिकांश लोग उछाल के बाद फोन नहीं करते — वे मान लेते हैं कि आप रुचि नहीं रखते और अपनी सूची में अगली फर्म के पास जाते हैं। आपको पता ही नहीं चलता कि लीड थी, इसलिए आप यह भी नहीं माप सकते कि इसकी क्या कीमत चुकानी पड़ी।
-
वह चालान जिसे आपने ‘अनदेखा’ किया। एक आपूर्तिकर्ता एक चालान, फिर एक अनुस्मारक, फिर एक अंतिम नोटिस भेजता है — सब उछलते हैं। रिश्ता बिगड़ता है, एक सेवा निलंबित हो जाती है, या एक छोटा बिल क्रेडिट-नियंत्रण समस्या बन जाता है, सब इसलिए क्योंकि मेल किसी के सामने कभी नहीं पड़ा।
-
अपने खातों से लॉक आउट। आप पासवर्ड रीसेट करने, एक नए बैंकिंग या सरकारी पोर्टल को सत्यापित करने, या सॉफ्टवेयर लाइसेंस का दावा करने की कोशिश करते हैं। पुष्टिकरण ईमेल आपके डोमेन पर भेजा जाता है और गायब हो जाता है। अब एक रूटीन कार्य सबसे अनुचित समय पर एक सपोर्ट-टिकट परेशानी बन जाता है।
-
वेबसाइट का माइग्रेशन जिसने चुपचाप ईमेल को मार डाला। एक वेब डिज़ाइनर आपके DNS को एक नए प्रदाता पर ले जाता है और वेबसाइट रिकॉर्ड कॉपी करता है — लेकिन MX रिकॉर्ड नहीं। कई दिनों तक, आपकी कंपनी के हर पते पर हर ईमेल चुपचाप गायब हो जाता है जब तक कोई “यह थोड़ा शांत हो गया” को “हमारा ईमेल टूटा हुआ है” से नहीं जोड़ता।
-
परित्यक्त दिखना। एक डोमेन जो ईमेल प्राप्त नहीं कर सकता, ग्राहकों और स्वचालित विश्वास जाँचों दोनों के लिए, एक व्यवसाय के रूप में पढ़ा जाता है जो वास्तव में संचालित नहीं है। यह ठीक उस समय विश्वास को कम करता है जब आप स्थापित और विश्वसनीय दिखना चाहते हैं।
इनमें से कोई भी खुद घोषित नहीं होता। यही बात एक गायब MX रिकॉर्ड को उससे अधिक खतरनाक बनाती है जितना यह लगता है: जब तक आप नोटिस करते हैं, आप पहले ही वह मेल खो चुके होते हैं जो आपको कभी वापस नहीं मिलेगा।
यह वास्तव में क्या है
आपके डोमेन की DNS सेटिंग में कई प्रकार के रिकॉर्ड होते हैं। MX रिकॉर्ड वे हैं जो आने वाले ईमेल को नियंत्रित करते हैं। एक कार्यशील सेटअप एक या अधिक प्रविष्टियों जैसा दिखता है, प्रत्येक एक मेल सर्वर का नामकरण करती है और एक प्राथमिकता संख्या रखती है:
- मेल सर्वर का नाम (आपके ईमेल प्रदाता का “मेल एक्सचेंज” होस्ट)।
- एक प्राथमिकता संख्या — पहले कम संख्याओं का प्रयास किया जाता है। कई रिकॉर्ड एक प्रदाता को फॉल-बैक सर्वर प्रदान करने देते हैं, इसलिए यदि कोई एक व्यस्त या डाउन है तो भी मेल मिलता है।
‘अच्छा’ कैसा दिखता है: कम से कम एक वैध MX रिकॉर्ड जो आप वास्तव में जो ईमेल प्रदाता उपयोग करते हैं — Google Workspace, Microsoft 365, आपके वेब होस्ट की मेल सेवा, या इसी तरह — उसके मेल सर्वरों पर इंगित करे, जिसमें सटीक सर्वर नाम और प्राथमिकताएं हों जो वह प्रदाता आपको उपयोग करने के लिए कहता है।
एक महत्वपूर्ण अपवाद। कुछ डोमेन जानबूझकर कोई ईमेल प्राप्त न करने के लिए स्थापित किए जाते हैं — उदाहरण के लिए एक डोमेन जो केवल एक वेबसाइट के लिए या किसी ब्रांड की सुरक्षा के लिए उपयोग किया जाता है। इसे घोषित करने का सही तरीका एक null MX रिकॉर्ड है: एक एकल MX रिकॉर्ड जिसकी प्राथमिकता 0 है और होस्ट बस एक बिंदु (.) है। यह एक प्रकाशित इंटरनेट मानक (RFC 7505) है और यह गैर-प्राप्त डोमेन के लिए सही उत्तर है — प्रेषकों को तुरंत, स्पष्ट “यह डोमेन ईमेल स्वीकार नहीं करता” अस्वीकृति मिलती है। इस जाँच पर, एक सही ढंग से प्रकाशित null MX पूर्ण अंकों के साथ पास होता है — यह एक जानबूझकर, सही विकल्प है, न कि दोष। जो विफल होता है वह है बिल्कुल कुछ भी नहीं होना, जो किसी गलती से अलग नहीं है।
यह आपके ग्रेड पर क्यों महत्वपूर्ण है। यह एक स्कोर की गई जाँच है जो ईमेल सुरक्षा श्रेणी में 25 अंक तक के योग्य है। एक डोमेन जिसे ईमेल प्राप्त करना चाहिए लेकिन कोई MX रिकॉर्ड नहीं है उसे मध्यम-गंभीरता विफल के रूप में चिह्नित किया जाता है — क्योंकि व्यावहारिक रूप से, इसके पीछे का व्यवसाय ईमेल द्वारा पहुँचा नहीं जा सकता। एक सही ढंग से प्राप्त करने वाला डोमेन, या एक सही ढंग से प्रकाशित null MX, पूरे अंक अर्जित करता है।
इसे कैसे ठीक करें (मुफ्त, लगभग 5 मिनट)
इसे अपने IT व्यक्ति या वेब प्रदाता को सौंपें — ठीक करना मुफ्त है। MX रिकॉर्ड आपके डोमेन के DNS में रहते हैं, उसी स्थान पर जहाँ आपकी वेबसाइट का पता कॉन्फ़िगर किया गया है। जो कोई भी आपका डोमेन या वेबसाइट प्रबंधित करता है वह इसे मिनटों में बिना किसी लागत के कर सकता है। आप केवल मेलबॉक्स सेवा के लिए भुगतान करते हैं, और केवल तभी यदि आपके पास पहले से एक नहीं है।
ठीक करना इस पर निर्भर करता है कि आप दो में से किस स्थिति में हैं।
यदि आपके डोमेन को ईमेल प्राप्त करना चाहिए लेकिन कोई MX रिकॉर्ड नहीं है
आपको अपने डोमेन को अपने ईमेल प्रदाता के मेल सर्वरों पर इंगित करना होगा। अपने प्रदाता द्वारा प्रकाशित सटीक रिकॉर्ड का उपयोग करें — नीचे दिए गए उदाहरण सामान्य हैं, लेकिन हमेशा अपने प्रदाता के स्वयं के सेटअप पेज से वर्तमान मान कॉपी करें, क्योंकि वे बदलते हैं।
-
अपने DNS प्रदाता में लॉग इन करें — जहाँ भी आपके डोमेन की सेटिंग रहती है (उदाहरण के लिए Cloudflare, Blacknight, GoDaddy, आपका वेब होस्ट, या आपका रजिस्ट्रार)।
-
अपनी ईमेल सेवा के लिए MX रिकॉर्ड जोड़ें:
Google Workspace (वर्तमान एकल-रिकॉर्ड सेटअप):
MXहोस्ट: आपका डोमेन →smtp.google.com, प्राथमिकता1(पुराने Google Workspace खाते अभी भी पाँच-सर्वर सेट का उपयोग कर सकते हैं जो प्राथमिकता 1 परaspmx.l.google.comसे शुरू होता है और प्राथमिकताओं 5-10 परalt1–alt4सर्वरों के साथ। दोनों मान्य हैं — वह मिलाएं जो आपका Google Admin Console दिखाता है।)
Microsoft 365:
MXहोस्ट: आपका डोमेन →<your-domain-with-dashes>.mail.protection.outlook.com, प्राथमिकता0(Microsoft Admin Center में आपके लिए सटीक होस्टनाम उत्पन्न करता है — प्रारूप का अनुमान लगाने के बजाय वहाँ से कॉपी करें।)
अन्य प्रदाता (आपके वेब होस्ट का मेल, होस्टेड Zoho/Fastmail/आदि. मेलबॉक्स): उस प्रदाता के DNS-सेटअप निर्देशों से MX होस्ट नाम और प्राथमिकताएं ज्यों की त्यों कॉपी करें।
-
सहेजें, फिर प्रतीक्षा करें। DNS परिवर्तन प्रभावी होने में लगभग 15-30 मिनट लगते हैं (कभी-कभी अधिक)। अपने डोमेन पर एक पते पर एक परीक्षण ईमेल भेजें और पुष्टि करें कि यह आता है।
यदि आपके डोमेन को कोई ईमेल नहीं मिलना चाहिए
एक null MX प्रकाशित करें ताकि “यहाँ कोई ईमेल नहीं” स्थिति स्पष्ट और सही हो:
- अपने DNS प्रदाता में लॉग इन करें।
- प्राथमिकता
0और होस्ट.(एकल बिंदु) के साथ एक एकल MX रिकॉर्ड जोड़ें। - सहेजें। प्रेषकों को अब तुरंत, मानकों-अनुपालक अस्वीकृति मिलेगी, और यह जाँच पास होगी।
यदि आप DNS या होस्ट बदलने वाले हैं
माइग्रेशन से पहले, अपने वर्तमान MX रिकॉर्ड ठीक-ठीक रिकॉर्ड करें (और अपने SPF, DKIM और किसी भी अन्य मेल रिकॉर्ड)। माइग्रेशन के बाद, नए प्रदाता पर समान मानों और प्राथमिकताओं के साथ हर एक को फिर से बनाएं, और माइग्रेशन पूर्ण मानने से पहले एक परीक्षण ईमेल भेजें। माइग्रेशन के दौरान MX रिकॉर्ड भूलना एकल सबसे सामान्य तरीका है जिससे व्यवसाय गलती से अपना ईमेल ऑफलाइन कर लेते हैं।
सामान्य गलतियाँ
- null MX प्रकाशित करने के बजाय MX खाली छोड़ना। यदि डोमेन वास्तव में कोई मेल प्राप्त नहीं करता, तो null MX (
0 .) से कहें ऐसा। खाली अस्पष्ट है और एक दोष के रूप में पढ़ा जाता है; null MX सही, पूर्ण-क्रेडिट उत्तर है। - MX को गलत चीज़ पर इंगित करना। एक आश्चर्यजनक रूप से सामान्य त्रुटि आपके वेबसाइट सर्वर या एक पुराने प्रदाता पर लक्षित MX रिकॉर्ड है जिसे आप छोड़ चुके हैं। मेल सर्वर ईमानदारी से वहाँ डिलीवर करने की कोशिश करेंगे — और विफल होंगे। हमेशा उस प्रदाता से रिकॉर्ड कॉपी करें जो आज वास्तव में आपके मेलबॉक्स होस्ट करता है।
- वेबसाइट या DNS माइग्रेशन के दौरान MX छोड़ना। वेबसाइट वापस आती है, सब आराम करते हैं, और ईमेल चुपचाप मर जाता है। MX (और अन्य मेल रिकॉर्ड) को किसी भी माइग्रेशन चेकलिस्ट का अनिवार्य हिस्सा मानें।
- प्राथमिकताओं को हाथ से संपादित करना। प्राथमिकता संख्याएं न बनाएं या “व्यवस्थित” न करें। अपने प्रदाता द्वारा निर्दिष्ट बिल्कुल वही दर्ज करें, जिसमें सभी बैकअप सर्वर भी शामिल हैं, ताकि फॉल-बैक डिलीवरी काम करती रहे।
- यह मानना कि MX आपको स्पूफिंग से बचाता है। यह नहीं करता। MX केवल आने वाला मेल है। जालसाजी सुरक्षा SPF, DKIM और DMARC है — अलग रिकॉर्ड, अलग से जाँचे गए।
संक्षेप में
MX रिकॉर्ड आपके ईमेल लिफाफे पर पता है। जब वे सही होते हैं — या गैर-प्राप्त डोमेन के लिए सही ढंग से null पर सेट होते हैं — मेल आप तक पहुँचता है और यह जाँच पास होती है। जब वे गायब होते हैं, तो आपका व्यवसाय ईमेल द्वारा अपहुँच है और ऐसे संदेश खो रहा है जिन्हें वह कभी देखता भी नहीं। ठीक करना मुफ्त है, कुछ मिनट लेता है, और आज जो कोई भी आपका डोमेन प्रबंधित करता है उसे सौंपने लायक है।
अक्सर पूछे जाने वाले प्रश्न
मुझे कैसे पता चलेगा कि यह टूटा हुआ है? मेरा ईमेल ठीक लगता है।
यदि आप अभी सामान्य रूप से ईमेल प्राप्त कर रहे हैं, तो आपके MX रिकॉर्ड लगभग निश्चित रूप से काम कर रहे हैं — यह जाँच पास हो जाएगी। खतरा अदृश्य है: MX रिकॉर्ड वेबसाइट के माइग्रेशन, DNS प्रदाता परिवर्तन, या गलत टाइप की गई संपादन से बाहर हो जाते हैं, और एकमात्र लक्षण यह है कि आने वाला मेल शांत हो जाता है। चूंकि आपको कोई अलर्ट नहीं मिलता जब ईमेल आना बंद हो जाता है, व्यवसाय दिनों तक मेल खो सकते हैं। इस तरह की एक मुफ्त जाँच, और यह ध्यान देना कि आपका इनबॉक्स अचानक शांत हो गया है, यही तरीके हैं जिनसे आप इसे पकड़ते हैं।
हम इस सटीक डोमेन पर ईमेल नहीं भेजते या प्राप्त नहीं करते — हम केवल इसका उपयोग अपनी वेबसाइट के लिए करते हैं। क्या गायब MX एक समस्या है?
जरूरी नहीं — लेकिन 'यह डोमेन कोई ईमेल नहीं प्राप्त करता' कहने का सही तरीका है एक विशेष रिकॉर्ड प्रकाशित करना जिसे null MX कहते हैं (एक MX रिकॉर्ड '0 .'), न कि MX रिकॉर्ड को बस छोड़ देना। इसे सही तरीके से करने का मतलब है कि प्रेषकों को तुरंत, स्पष्ट 'यह डोमेन ईमेल नहीं लेता' अस्वीकृति मिलती है, और यह वास्तव में इस जाँच पर विफल के बजाय पास के रूप में गिना जाता है। बस इसे खाली छोड़ना एक गलत कॉन्फ़िगरेशन जैसा दिखता है। अपने IT व्यक्ति से null MX जोड़ने के लिए कहें — यह एक पंक्ति, मुफ्त परिवर्तन है।
क्या इसे ठीक करने में पैसे खर्च होंगे?
नहीं। MX रिकॉर्ड जोड़ना या सही करना मुफ्त है — यह आपके डोमेन की DNS सेटिंग में एक परिवर्तन है, जिसके लिए आप पहले से ही अपने डोमेन या होस्टिंग के हिस्से के रूप में भुगतान करते हैं। आप केवल ईमेल सेवा के लिए भुगतान करते हैं (उदाहरण के लिए Google Workspace या Microsoft 365 मेलबॉक्स) यदि आपके पास पहले से एक नहीं है। MX रिकॉर्ड बस आप जो मेलबॉक्स प्रदाता उपयोग करते हैं उस पर इंगित करते हैं।
MX रिकॉर्ड पर 'प्राथमिकता' का क्या मतलब है, और क्या मुझे इसकी चिंता करनी चाहिए?
प्रत्येक MX रिकॉर्ड में एक संख्या होती है — प्राथमिकता — और मेल सर्वर पहले सबसे कम संख्या का प्रयास करते हैं। यह इसलिए मौजूद है ताकि एक प्रदाता बैकअप सर्वर प्रदान कर सके: यदि मुख्य डाउन है, तो मेल अगले की ओर प्रवाहित होता है। आप आमतौर पर इन्हें स्वयं सेट नहीं करते; आप अपने ईमेल प्रदाता के सेटअप पेज से सटीक रिकॉर्ड (उनकी संख्याओं सहित) कॉपी करते हैं। बस सुनिश्चित करें कि आप उन्हें बिल्कुल जैसे दिए गए हैं वैसे दर्ज करें।
क्या MX रिकॉर्ड कॉन्फ़िगर होने से लोगों को मेरे नाम से ईमेल जाली बनाने से रोका जा सकता है?
नहीं — यह नियंत्रणों का एक अलग सेट है (SPF, DKIM और विशेष रूप से DMARC)। MX रिकॉर्ड केवल आने वाले मेल को संभालते हैं: आपके लिए संदेश कहाँ डिलीवर किए जाते हैं। एंटी-इम्पर्सनेशन बाहर जाने वाले मेल के बारे में है और प्राप्त करने वाले सर्वर जालसाजी के साथ क्या करते हैं। आपको दोनों की जरूरत है: MX ताकि आप प्राप्त कर सकें, और DMARC ताकि कोई आपकी बाहर जाने वाली पहचान नकली न बना सके। उन्हें यहाँ अलग-अलग जाँचा जाता है।
मेरे पास DNS या होस्ट बदलने की योजना है — मैं ईमेल टूटने से कैसे बचूं?
कुछ भी बदलने से पहले, अपने वर्तमान MX रिकॉर्ड ठीक-ठीक लिख लें (और अपने SPF, DKIM और किसी भी अन्य मेल-संबंधित रिकॉर्ड)। जब आप DNS को नए प्रदाता पर ले जाते हैं, तो बहु-दिवसीय ईमेल आउटेज का सबसे आम कारण यह है कि केवल वेबसाइट रिकॉर्ड कॉपी किए जाते हैं और MX रिकॉर्ड भूल जाते हैं। नए प्रदाता पर हर MX रिकॉर्ड को समान मानों और प्राथमिकताओं के साथ फिर से बनाएं, और माइग्रेशन पूर्ण मानने से पहले एक परीक्षण ईमेल की पुष्टि करें।