MX रिकॉर्ड क्या है, और क्या ईमेल भेजने के लिए मुझे इसकी ज़रूरत है?

MX रिकॉर्ड आने वाले मेल के लिए सर्वर बताता है, लेकिन मेल भेजने के लिए यह प्रोटोकॉल की अनिवार्यता नहीं है।

मेल भेजने वाला ऐप्लिकेशन और मेल प्राप्त करने वाला मेलबॉक्स अलग-अलग डोमेन इस्तेमाल कर सकते हैं। जवाबों को रूट करने वाले रिकॉर्ड का भेजने के लिए इस्तेमाल होने वाले हर सबडोमेन पर होना ज़रूरी नहीं है।

भेजने वाला सर्वर MX रिकॉर्ड का उपयोग कैसे करता है?

भेजने वाला सर्वर प्राप्तकर्ता के डोमेन को खोजकर पता लगाता है कि कौन-से सर्वर उस डोमेन का आने वाला मेल स्वीकार करते हैं।

person@example.org के लिए, वह example.org के MX रिकॉर्ड खोजता है। हर रिकॉर्ड एक गंतव्य सर्वर बताता है, जिसका होस्टनेम एक IP पते में बदलता है।

RFC 5321 SMTP के लिए यह खोज प्रक्रिया परिभाषित करता है।

अगर प्राप्तकर्ता का डोमेन मौजूद नहीं है, तो भेजने वाला सर्वर त्रुटि रिपोर्ट करता है। खोज अस्थायी रूप से विफल होने पर, वह संदेश को बाद में फिर से प्रयास करने के लिए कतार में रखता है।

जब किसी डोमेन का कोई MX रिकॉर्ड नहीं होता, तब क्या होता है?

अगर कोई MX रिकॉर्ड मौजूद नहीं है, तो SMTP डोमेन को ही गंतव्य मानता है और उसके एड्रेस रिकॉर्ड आज़माता है।

इस अंतर्निहित MX की प्राथमिकता शून्य होती है। इससे ऊपर रखने के लिए कोई स्पष्ट MX सूची नहीं होती, इसलिए डोमेन का अपना पता उपयोग योग्य होने पर डिलीवरी उसी पर जाती है।

यह विकल्प केवल खाली MX सूची पर लागू होता है। अगर किसी डोमेन के प्रकाशित MX रिकॉर्ड उपयोग योग्य नहीं हैं, तो यह उसे नहीं बचाता।

null MX एक अलग निर्देश है: RFC 7505 एक स्पष्ट रिकॉर्ड परिभाषित करता है, जो बताता है कि डोमेन कोई मेल स्वीकार नहीं करता। रिकॉर्ड न होने पर वैकल्पिक पते का उपयोग हो सकता है। null MX होने पर डिलीवरी अस्वीकार हो जाती है।

MX प्राथमिकता संख्याओं का क्या अर्थ है?

कम प्राथमिकता मान वे गंतव्य बताते हैं जिन्हें भेजने वाले को सबसे पहले आज़माना चाहिए।

10, 20 और 30 मानों में से 10 वाला गंतव्य प्राथमिक होता है। अगर वहाँ डिलीवरी आगे नहीं बढ़ पाती, तो बाकी गंतव्य विकल्प का काम करते हैं। इसके बजाय हर गंतव्य को एक ही मान देने पर समान प्राथमिकता वाले विकल्पों के बीच मेल बाँटा जा सकता है।

RFC 5321 के तहत, भेजने वाले सर्वरों को समान प्राथमिकता वाले गंतव्यों का क्रम यादृच्छिक रखना होता है, जब तक किसी एक को चुनने का स्पष्ट कारण न हो। समान प्राथमिकता से ट्रैफ़िक का ठीक-ठीक बराबर बँटवारा तय नहीं होता।

अपने MX रिकॉर्ड को ऐसे होस्टनेम पर पॉइंट करें जिसका पता आप प्रकाशित करते हैं, ताकि भेजने वाले उससे कनेक्ट कर सकें। IPv4 पते के लिए A रिकॉर्ड और IPv6 के लिए AAAA रिकॉर्ड इस्तेमाल करें। गंतव्य के रूप में CNAME उपनाम इस्तेमाल न करें। उपनाम होने पर DNS अपने MX उत्तर के साथ पता शामिल नहीं कर पाता। इससे लुकअप बढ़ जाते हैं, जैसा कि RFC 2181 बताता है।

SMTP क्लाइंट को वैकल्पिक गंतव्यों पर प्रयास करने का समर्थन देना होता है। स्पेसिफ़िकेशन सुझाता है कि उपलब्ध होने पर कम से कम दो पतों पर प्रयास किया जाए। तब पहले पते पर विफलता से डिलीवरी के प्रयास खत्म नहीं होते।

क्या भेजने के लिए आपको MX रिकॉर्ड चाहिए?

सिर्फ़ संदेश भेजने के लिए SMTP आपके डोमेन पर स्पष्ट MX रिकॉर्ड की माँग नहीं करता।

डिलीवरी लुकअप प्राप्तकर्ता के डोमेन का इस्तेमाल करता है। फिर भी आपके भेजने वाले डोमेन को मान्य DNS और प्राप्तकर्ता की आवश्यकताओं के अनुरूप ऑथेंटिकेशन चाहिए। प्राप्तकर्ता भेजने वाले डोमेन पर अपनी जाँचें लागू कर सकता है।

इसलिए MX रिकॉर्ड न होने का मतलब यह नहीं है कि पहुँच से बाहर भेजने वाला डोमेन हर प्राप्तकर्ता को स्वीकार्य है।

डिलीवरी विफलताएँ कहाँ जाती हैं?

डिलीवरी विफलताएँ एनवेलप सेंडर पर जाती हैं, यानी वह पता जो SMTP डिलीवरी के दौरान विफलता सूचनाओं के लिए दिया जाता है।

जवाब कहाँ जाते हैं?

जवाब आम तौर पर Reply-To पर जाते हैं, अगर वह मौजूद हो; नहीं तो दिखने वाले From पते पर।

किसी भेजने वाले सबडोमेन पर कंपनी के सभी मेलबॉक्स होना ज़रूरी नहीं है। उदाहरण के लिए, news.example.com से मेल भेजा जा सकता है, जबकि जवाब example.com पर किसी चालू पते पर जाते हैं। रूटिंग का यह चुनाव संदेश के पतों में साफ़ तौर पर दर्ज करें।

परिचालन रिपोर्ट कहाँ जाती हैं?

postmaster@ और abuse@ जैसे परिचालन पते दूसरे ऑपरेटरों को डिलीवरी या दुरुपयोग से जुड़ी समस्याएँ रिपोर्ट करने का तरीका देते हैं।

RFC 5321 के अनुसार, मेल रिले या डिलीवर करने वाले SMTP सर्वर को अपने सेवा वाले डोमेन के लिए postmaster@ स्वीकार करना होगा। इससे मेल सेवा की समस्याओं के लिए एक संपर्क मिलता है।

RFC 2142 के अनुसार, जहाँ संबंधित काम मौजूद हो, वहाँ संगठनों को भूमिका वाले मेलबॉक्स उपलब्ध कराने होंगे। उदाहरण के लिए, किसी इंटरनेट सेवा प्रदाता को अपने संगठन के डोमेन पर abuse@ उपलब्ध कराना होगा। इससे शिकायतें ज़िम्मेदार टीम तक पहुँचती हैं।

Bird से आप ईमेल कैसे प्राप्त करते हैं?

आप किसी डोमेन के लिए प्राप्त करना चालू करते हैं और Bird द्वारा लौटाए गए MX रिकॉर्ड प्रकाशित करते हैं।

API का inbound.enabled फ़ील्ड प्राप्त करना चालू करने के लिए true या बंद करने के लिए false स्वीकार करता है। केवल रिकॉर्ड प्रकाशित करने से यह सुविधा चालू नहीं होती।

सत्यापन के बाद, उस डोमेन पर भेजा गया मेल इनबाउंड संदेश बन जाता है। प्राप्त करने के लिए एक अलग सबडोमेन इस्तेमाल करें, क्योंकि अपनी कंपनी के डोमेन के MX रिकॉर्ड बदलने से उसका मौजूदा मेल किसी और जगह पहुँचने लगता है।

Bird का रिटर्न-पाथ रिकॉर्ड डिलीवरी विफलता की सूचनाओं को उन इनबाउंड MX रिकॉर्ड से अलग संभालता है। प्राप्त करने की गाइड डोमेन सेटअप बताती है। बाउंस-डोमेन गाइड विफलताओं को संभालना बताती है।

संक्षेप में

  1. MX रिकॉर्ड आने वाले मेल को रूट करते हैं।

    भेजने वाला सर्वर गंतव्य खोजने के लिए प्राप्तकर्ता का डोमेन लुकअप करता है।

  2. MX रिकॉर्ड न होने पर पते के रिकॉर्ड इस्तेमाल हो सकते हैं।

    जब कोई MX रिकॉर्ड मौजूद नहीं होता, तो भेजने वाला सर्वर डोमेन के पते वाले रिकॉर्ड इस्तेमाल कर सकता है।

  3. कम प्राथमिकता मान वाले गंतव्य पहले आज़माए जाते हैं।

    जब किसी एक को चुनने का कारण न हो, तो बराबर प्राथमिकता वाले गंतव्य यादृच्छिक क्रम में आज़माए जाते हैं।

  4. भेजने और प्राप्त करने के लिए अलग-अलग निर्णय लेने होते हैं।

    बाहर जाने वाले मेल के लिए भी डिलीवरी विफलताओं, जवाबों और परिचालन संपर्क पतों को सही तरह से संभालना ज़रूरी है।

उसी नेटवर्क पर बनाएँ।

एक टेस्ट API key आपको तुरंत मिल जाती है। भुगतान विधि जोड़ने और सेंडर सत्यापित करने पर प्रोडक्शन अनलॉक होता है।

आपका अगला आइडिया। जुड़ने के लिए तैयार।