आउटगोइंग ऐप्लिकेशन और इनकमिंग मेलबॉक्स अलग-अलग डोमेन का उपयोग कर सकते हैं। रिप्लाई को रूट करने वाले रिकॉर्ड को भेजने के लिए इस्तेमाल किए जाने वाले हर सबडोमेन पर होना ज़रूरी नहीं है।
भेजने वाला सर्वर MX रिकॉर्ड का उपयोग कैसे करता है?
भेजने वाला सर्वर प्राप्तकर्ता के डोमेन को लुकअप करता है ताकि उन सर्वर का पता चले जो उसकी इनकमिंग मेल स्वीकार करते हैं।
person@example.org के लिए, यह example.org के MX रिकॉर्ड लुकअप करता है। हर रिकॉर्ड एक गंतव्य सर्वर का नाम बताता है जिसका hostname एक IP एड्रेस में रिज़ॉल्व होता है।
RFC 5321 SMTP के लिए यह लुकअप प्रक्रिया परिभाषित करता है।
जब प्राप्तकर्ता का डोमेन मौजूद नहीं होता, तो भेजने वाला सर्वर त्रुटि रिपोर्ट करता है। अस्थायी लुकअप विफलता के बाद, यह संदेश को बाद के प्रयास के लिए क्यू में रखता है।
जब किसी डोमेन में कोई MX रिकॉर्ड न हो तो क्या होता है?
अगर कोई MX रिकॉर्ड मौजूद नहीं है, तो SMTP डोमेन को ही गंतव्य मानता है और उसके एड्रेस रिकॉर्ड आज़माता है।
इस implicit MX की preference शून्य होती है। इसे पीछे छोड़ने के लिए कोई explicit MX सूची नहीं होती, इसलिए जब उपयोग योग्य हो तब डिलीवरी डोमेन के अपने एड्रेस पर आगे बढ़ती है।
यह फ़ॉलबैक खाली MX सूची पर लागू होता है। यह उस डोमेन को नहीं बचाता जिसके प्रकाशित MX रिकॉर्ड अनुपयोगी हैं।
Null MX एक अलग निर्देश है: RFC 7505 एक explicit रिकॉर्ड परिभाषित करता है जो घोषणा करता है कि डोमेन कोई मेल स्वीकार नहीं करता। अनुपस्थित रिकॉर्ड फ़ॉलबैक की अनुमति देता है। Null MX डिलीवरी को अस्वीकार करता है।
MX preference नंबर का क्या मतलब है?
कम preference वैल्यू उन गंतव्यों की पहचान करती हैं जिन्हें भेजने वाले को पहले आज़माना चाहिए।
10, 20 और 30 वैल्यू के साथ, 10 वाला गंतव्य प्राथमिक होता है। बाकी विकल्प तब काम आते हैं जब वहाँ डिलीवरी आगे न बढ़ सके। सभी गंतव्यों को एक ही वैल्यू देने से समान-preference विकल्पों में वितरण संभव होता है।
RFC 5321 के अनुसार, भेजने वाले सर्वर को समान-preference वाले गंतव्यों को रैंडमाइज़ करना चाहिए, जब तक कि किसी एक को प्राथमिकता देने का स्पष्ट कारण न हो। समान preference ट्रैफ़िक के सटीक विभाजन का वादा नहीं करती।
अपने MX रिकॉर्ड को ऐसे hostname पर पॉइंट करें जिसका एड्रेस आपने प्रकाशित किया हो ताकि भेजने वाले कनेक्ट कर सकें। उसके IPv4 एड्रेस के लिए A रिकॉर्ड या IPv6 के लिए AAAA रिकॉर्ड का उपयोग करें। गंतव्य के रूप में CNAME alias का उपयोग न करें। alias, DNS को MX उत्तर के साथ एड्रेस शामिल करने से रोकता है। इससे अतिरिक्त लुकअप होते हैं, जैसा कि RFC 2181 बताता है।
SMTP क्लाइंट को वैकल्पिक गंतव्य आज़माने का समर्थन करना चाहिए। विनिर्देश उपलब्ध होने पर कम से कम दो एड्रेस आज़माने की सिफ़ारिश करता है। पहले पर विफलता होने पर डिलीवरी प्रयास समाप्त होने ज़रूरी नहीं।
क्या भेजने के लिए MX रिकॉर्ड ज़रूरी है?
SMTP आपके डोमेन पर संदेश भेजने भर के लिए explicit MX रिकॉर्ड की आवश्यकता नहीं रखता।
डिलीवरी लुकअप प्राप्तकर्ता के डोमेन का उपयोग करता है। आपके भेजने वाले डोमेन को अभी भी वैध DNS और रिसीवर की आवश्यकताओं के अनुसार उचित ऑथेंटिकेशन चाहिए। रिसीवर भेजने वाले डोमेन पर अपनी जाँच लागू कर सकता है।
MX रिकॉर्ड का न होना इसलिए इसका मतलब नहीं है कि अगम्य भेजने वाला डोमेन हर रिसीवर को स्वीकार्य होगा।
डिलीवरी विफलताएँ कहाँ जाती हैं?
डिलीवरी विफलताएँ envelope sender को जाती हैं, यानी वह पता जो 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 का return-path रिकॉर्ड डिलीवरी-विफलता सूचनाओं को उन इनबाउंड MX रिकॉर्ड से अलग हैंडल करता है। रिसीविंग गाइड डोमेन सेटअप की व्याख्या करती है। बाउंस-डोमेन गाइड विफलता हैंडलिंग की व्याख्या करती है।
संक्षेप में
MX रिकॉर्ड इनकमिंग मेल को रूट करते हैं।
भेजने वाला सर्वर गंतव्य खोजने के लिए प्राप्तकर्ता के डोमेन को लुकअप करता है।
MX रिकॉर्ड न होने पर एड्रेस रिकॉर्ड पर फ़ॉलबैक हो सकता है।
जब कोई MX रिकॉर्ड मौजूद नहीं होता, तो भेजने वाला सर्वर डोमेन के एड्रेस रिकॉर्ड का उपयोग कर सकता है।
कम preference वैल्यू पहले आज़माई जाती हैं।
समान-preference वाले गंतव्यों को रैंडमाइज़ किया जाता है जब किसी एक को प्राथमिकता देने का कोई कारण न हो।
भेजने और प्राप्त करने के लिए अलग-अलग निर्णय चाहिए।
आउटगोइंग मेल के लिए अभी भी डिलीवरी विफलताओं, रिप्लाई और ऑपरेशनल संपर्क पतों की उचित हैंडलिंग ज़रूरी है।