अपने डोमेन से ईमेल
बॉट आपके ग्राहकों को ईमेल भेज सकता है — आपके अपने डोमेन के पते से, जैसे noreply@example.com। लेकिन संदेश भेजता हमारा सर्वर है। इसीलिए पहली बार भेजने से पहले आपको अपने डोमेन के DNS में एक बार तीन रिकॉर्ड जोड़ने होते हैं। नीचे: यह क्यों ज़रूरी है, ठीक-ठीक क्या जोड़ना है और उसके बाद क्या होता है।
DNS रिकॉर्ड के बिना ईमेल क्यों नहीं पहुँचते
पाने वाले की नज़र से देखिए — Gmail, Outlook या आपके ग्राहक का मेल सर्वर। उन्हें एक संदेश मिलता है जो दावा करता है कि वह आपके डोमेन से है, पर आता है उस सर्वर से जो आपके डोमेन का नहीं है। यह ठीक वैसी ही तस्वीर है जैसी जालसाज़ी की होती है: फ़िशिंग ऐसे ही काम करता है।
पाने वाला दोनों में फ़र्क सिर्फ़ एक तरीके से कर सकता है — खुद डोमेन से पूछकर: «क्या यह भेजने वाला सचमुच आपकी ओर से काम कर रहा है?» इसका उत्तर आप अपने डोमेन के DNS में प्रकाशित करते हैं, क्योंकि DNS ही एकमात्र जगह है जिस पर केवल आपका अधिकार है — और इसीलिए वही जगह है जिस पर पाने वाला भरोसा करता है।
जब तक यह उत्तर नहीं है, एक ज़िम्मेदार मेल सर्वर को संदेश को संदिग्ध मानना ही पड़ता है। अच्छे से अच्छा नतीजा — «स्पैम» फ़ोल्डर; बुरे से बुरा — अस्वीकृति, और पाने वाले को कभी पता ही नहीं चलेगा कि संदेश था।
इसलिए नीचे दिए तीन रिकॉर्ड औपचारिकता या इंटरफ़ेस का कोई टिक-मार्क नहीं हैं। वही आपकी अनुमति हैं।
तीन रिकॉर्ड और हर एक का काम
DKIM — असलियत साबित करने वाला हस्ताक्षर
DKIM हर भेजे जाने वाले संदेश पर लगने वाला क्रिप्टोग्राफ़िक हस्ताक्षर है। प्लेटफ़ॉर्म आपके डोमेन के लिए कुंजियों का एक जोड़ा बनाता है: निजी कुंजी हमारे पास रहकर संदेश पर हस्ताक्षर करती है, सार्वजनिक कुंजी आप DNS में प्रकाशित करते हैं। पाने वाला आपके DNS से सार्वजनिक कुंजी लेकर हस्ताक्षर जाँचता है। मेल खाया — यानी संदेश उसी ने भेजा जिसके पास निजी कुंजी है, और रास्ते में सामग्री बदली नहीं गई।
DKIM के बिना: हस्ताक्षर जाँचने के लिए कुछ नहीं होता। संदेश बिना हस्ताक्षर वाला और अविश्वसनीय लगता है, और कोई दूसरी सेटिंग इसकी भरपाई नहीं करती। तीनों में DKIM सबसे अहम है।
SPF — कौन-से सर्वर आपकी ओर से भेज सकते हैं
SPF दूसरा सवाल हल करता है: इस डोमेन से आने वाले संदेश किन सर्वरों से स्वीकार्य हैं। यह स्रोतों की सूची है — आपकी होस्टिंग के मेल सर्वर, आप जिन भेजने वाली सेवाओं का पहले से उपयोग करते हैं, और बॉट के लिख सकने हेतु हमारे भेजने वाले सर्वर।
SPF के बिना: संदेश उस सर्वर से आता है जिसे आपका डोमेन «नहीं जानता»। फ़िल्टर के लिए यह जालसाज़ी का चिरपरिचित संकेत है, और बाकी सब संदेहों में जुड़ जाता है।
DMARC — जाँच विफल हो तो पाने वाला क्या करे
DKIM और SPF बताते हैं कि «संदेश असली है या नहीं»। DMARC अगला सवाल हल करता है: अगर नहीं है तो क्या करें। यह पाने वाले को आपका निर्देश है — कुछ न करो और सिर्फ़ रिपोर्ट भेजो, स्पैम में डालो, या अस्वीकार करो। साथ ही DMARC वह पता है जहाँ पाने वाले आपके नाम की डाक की सामूहिक रिपोर्टें भेजते हैं, जिनमें दूसरों की जालसाज़ी की कोशिशें भी शामिल हैं।
सबसे नरम नीति — «केवल रिपोर्ट» — से शुरू करें। सख़्ती बाद में बढ़ाएँ, जब यह पक्का हो जाए कि आपके सारे वैध भेजने वाले (लेखा, CRM, न्यूज़लेटर, यह बॉट) जाँच पास कर रहे हैं। बहुत जल्दी चालू की गई सख़्त नीति आपकी अपनी ही डाक काटने लगती है।
DMARC के बिना: हर पाने वाला अपने हिसाब से तय करता है, और आपको कभी पता नहीं चलता कि आपके नाम की डाक का क्या हो रहा है।
कौन-से रिकॉर्ड जोड़ें
पहले डोमेन को कैबिनेट में जोड़ें: Email अनुभाग → «Sending domains» → बटन «Add domain»। डायलॉग में तीन फ़ील्ड हैं: स्वयं डोमेन (जैसे shop.example.com), पते का स्थानीय हिस्सा (@ से पहले वाला भाग, आमतौर पर noreply) और प्रेषक का नाम, जो पाने वाले को पते की जगह दिखता है। सहेजते ही आपकी DNS रिकॉर्ड स्क्रीन पर आ जाती हैं।
तीनों आपके डोमेन के DNS में TXT प्रकार के रिकॉर्ड हैं। वहीं जोड़े जाते हैं जहाँ आप डोमेन प्रबंधित करते हैं: रजिस्ट्रार के पैनल में या DNS प्रदाता के यहाँ।
नीचे के मान उदाहरण के लिए example.com से दिखाए गए हैं — अपना डोमेन रखें। आपके डोमेन के सटीक मान कैबिनेट में डोमेन कार्ड पर दिखते हैं — वहीं से कॉपी करें, ख़ासकर DKIM: उसके मान में आपकी अपनी सार्वजनिक कुंजी होती है, हर डोमेन की अलग, और दस्तावेज़ से उसे लिया नहीं जा सकता।
स्क्रीन पर हर रिकॉर्ड दो अलग फ़ील्ड में बँटा है — «Host» और «Value» — हर एक का अपना «Copy» बटन। इन्हें एक-एक करके अपने DNS प्रदाता के संबंधित फ़ील्ड में कॉपी करें: दोनों हिस्से एक साथ एक टुकड़े में नहीं चिपकते।
| प्रकार | रिकॉर्ड का नाम (host) | मान |
|---|---|---|
| TXT | mybot._domainkey.example.com | v=DKIM1; k=rsa; p= और आगे पैनल से ली गई लंबी कुंजी |
| TXT | example.com (डोमेन की जड़) | v=spf1 include:esp.getmybot.dev ~all |
| TXT | _dmarc.example.com | v=DMARC1; p=none; rua=mailto:dmarc@example.com |
दो जगहें जहाँ लोग सबसे ज़्यादा चूकते हैं:
- कई पैनल नाम में डोमेन खुद जोड़ देते हैं। अगर नाम के फ़ील्ड में पहले से «.example.com» लिखा है, तो पूरा नाम नहीं, सिर्फ़
mybot._domainkeyलिखें — वरना बनेगाmybot._domainkey.example.com.example.com। - DKIM का मान लंबा है और कुंजी के भीतर लाइन ब्रेक या स्पेस नहीं होने चाहिए। उसे बटन से कॉपी करें, माउस से चुनकर नहीं।
अगर डोमेन पर SPF रिकॉर्ड पहले से है
एक डोमेन पर SPF रिकॉर्ड सिर्फ़ एक हो सकता है। अगर आप पहले से होस्टिंग, CRM या किसी और न्यूज़लेटर सेवा से मेल भेजते हैं, तो वह रिकॉर्ड मौजूद है। दूसरा न जोड़ें — मौजूदा में ही एक और include लिख दें, अंत के ~all से पहले:
v=spf1 include:spf.आपकाप्रदाता include:esp.getmybot.dev ~all
एक डोमेन पर दो SPF रिकॉर्ड वही गलती है जो एक भी न होना: जाँच पास नहीं होती, क्योंकि पाने वाला जान ही नहीं पाता कि दोनों में किस पर भरोसा करे।
ध्यान दें: किसी और के रिकॉर्ड के ज़रिये «कवर» होना पर्याप्त नहीं है। भले ही आपका मौजूदा प्रदाता हमें अपने SPF में शामिल करता हो, हमारा include सीधे आपके रिकॉर्ड में होना चाहिए — क्यों, यह नीचे डोमेन सत्यापन वाले हिस्से में है।
SPF में IP पता नहीं, include क्यों
सबसे आम गलती है किसी संदेश के हेडर या किसी फ़ोरम में देखा गया IP पता चिपका देना। ऐसा न करें।
include:esp.getmybot.dev हमारी अपनी, हमारे द्वारा संभाली जाने वाली भेजने वाले सर्वरों की सूची का संकेतक है। आज इस नाम के पीछे एक ही रिले है। कल उनकी संख्या बढ़ सकती है, वे जगह बदल सकते हैं या बदले जा सकते हैं। जब ऐसा होगा, हम सूची अपनी ओर से अपडेट कर देंगे — और आपका रिकॉर्ड बिना किसी छेड़छाड़ के चलता रहेगा। पूरा मतलब यही है: पता एक ही जगह बदलता है, हर ग्राहक के DNS में नहीं।
हाथ से लिखा IP पता उसी क्षण सच नहीं रह जाता। संदेश बिना किसी चेतावनी के SPF में फेल होने लगते हैं — न पैनल में कोई त्रुटि, न कोई सूचना। आपको पता उन ग्राहकों से चलेगा जो कहेंगे कि «कुछ मिला ही नहीं»।
ठीक include:esp.getmybot.dev लिखें और उसमें कुछ न जोड़ें।
डोमेन सत्यापन
डोमेन सत्यापन यानी प्लेटफ़ॉर्म खुद आपके डोमेन का DNS देखता है और पक्का करता है कि तीनों रिकॉर्ड ठीक हैं। तीनों पास हो जाएँ तो डोमेन को सत्यापित का दर्जा मिलता है और भेजने की अनुमति मिल जाती है। जब तक कोई एक भी पास नहीं होता, डोमेन प्रतीक्षा में रहता है।
जाँच «रिकॉर्ड मौजूद है» से कहीं आगे जाती है:
| रिकॉर्ड | असल में क्या जाँचा जाता है |
|---|---|
| DKIM | रिकॉर्ड प्रकाशित है और उसमें आपकी अपनी सार्वजनिक कुंजी है। किसी और का या पुरानी कुंजी वाला DKIM पास नहीं होगा। |
| SPF | रिकॉर्ड मौजूद है और उसमें सीधे include:esp.getmybot.dev है। मिलते-जुलते मान जैसे include:esp.getmybot.dev.दूसरा-डोमेन.example नहीं गिने जाते। |
| DMARC | रिकॉर्ड प्रकाशित है और v=DMARC1 से शुरू होता है। नीति स्वयं (p=, rua=) नहीं जाँची जाती — वह आपका निर्णय है, हमारे लिए अनुमति नहीं। |
DMARC की जाँच ढीली क्यों है: वह पाने वालों को बताता है कि DKIM और SPF के नतीजों का क्या करना है, पर हमें आपके नाम से भेजने का अधिकार नहीं देता। वह अधिकार केवल पहले दो रिकॉर्ड देते हैं, और दोनों की सामग्री पूरी तरह जाँची जाती है।
किसी और का include नहीं गिना जाता
include:esp.getmybot.dev आपके अपने SPF रिकॉर्ड में होना चाहिए। अगर आपके SPF में कोई बाहरी प्रदाता शामिल है और उसका रिकॉर्ड हमें शामिल करता है, तो सत्यापन इसे नहीं मानेगा: प्लेटफ़ॉर्म दूसरों के include की शृंखला नहीं खोलता। कारण सीधा है — इससे «क्या इसी डोमेन ने हमें अनुमति दी» का उत्तर स्पष्ट बना रहता है।
व्यवहार में: भले ही आपको यकीन हो कि आप «प्रदाता के ज़रिये कवर हैं», हमारा include सीधे अपने रिकॉर्ड में जोड़ें। यही बात स्क्रीन पर भी लिखी है, SPF रिकॉर्ड की व्याख्या में: अगर डोमेन के पास पहले से SPF रिकॉर्ड है तो उसी में include:... मान जोड़ें, पूरा रिकॉर्ड न बदलें, क्योंकि डोमेन हमारे अलावा और रास्तों से भी मेल भेज सकता है। यह सूचना वहाँ हमेशा रहती है, असफल जाँच के बाद ही नहीं दिखती।
DNS तुरंत अपडेट नहीं होता। रजिस्ट्रार के यहाँ रिकॉर्ड सहेजने के बाद उन्हें नाम सर्वरों तक फैलना होता है: आमतौर पर मिनट, कभी घंटे, कभी-कभार एक दिन तक। यह आपके प्रदाता और TTL पर निर्भर है। यह सामान्य है और हमारे हाथ में नहीं।
फिर भी निष्क्रिय इंतज़ार की ज़रूरत नहीं। प्लेटफ़ॉर्म प्रतीक्षारत डोमेन खुद हर घंटे जाँचता है, पर डोमेन कार्ड पर «Verify now» बटन है — वही जाँच, तुरंत चलाई गई, नतीजा फ़ौरन स्क्रीन पर। रिकॉर्ड सहेजते ही इसे दबाएँ: कहीं टाइपिंग की गलती हुई तो एक सेकंड में पता चलेगा, एक घंटे में नहीं। जितनी बार चाहें दबा सकते हैं।
डोमेन की स्थिति कार्ड पर दिखती है: «Pending verification», «Verified» या «Not verified»। जब तक डोमेन सत्यापित नहीं है, वहीं चेतावनी भी रहती है — «Sending from this domain is disabled until it is verified.»
परिणाम केवल «असफल» नहीं होता। तीनों रिकॉर्ड की स्क्रीन पर अपनी-अपनी स्थिति होती है — «Passing», «Not passing» या «Not checked yet» — और अपनी-अपनी पंक्ति जो बताती है कि गड़बड़ी क्या है।
SPF के लिए स्क्रीन दो स्थितियों में फ़र्क करती है, और पूरे प्रवाह में यही सबसे अहम फ़र्क है:
- डोमेन पर SPF रिकॉर्ड है ही नहीं। ऊपर की तालिका वाले मान से उसे प्रकाशित करें।
- SPF रिकॉर्ड है, पर उसमें हमारा include नहीं है। include को मौजूदा रिकॉर्ड में जोड़ें: दूसरा न बनाएँ और पूरा न बदलें। वही संदेश शृंखला वाले मामले को भी साफ़ शब्दों में कवर करता है: अगर include हम तक केवल किसी और प्रदाता के SPF रिकॉर्ड के रास्ते पहुँचता है, तो वह नहीं गिना जाता — शृंखलाएँ खोली नहीं जातीं।
दूसरा मामला पूरे प्रवाह का सबसे उलझन भरा क्षण है: रिकॉर्ड पहले से मौजूद है, आपने अभी-अभी खुद उसे पढ़ा भी है, और सत्यापन फिर भी मना कर रहा है। त्रुटि संदेश अब ठीक वही कहता है जो रिकॉर्ड के बगल में हमेशा दिखने वाली सूचना कहती है — जो पहले से है, उसी में हमारा include जोड़ें।
अगर सत्यापन पास न हो:
- पढ़ें कि तीनों में से किस रिकॉर्ड पर «Not passing» है और उसकी व्याख्या क्या कहती है, फिर उसी के अनुसार आगे बढ़ें।
- पक्का करें कि रिकॉर्ड सचमुच प्रकाशित हैं — कई पैनल में अलग से «परिवर्तन लागू करें» दबाना पड़ता है।
- रिकॉर्ड का नाम दोहरे डोमेन के लिए जाँचें (ऊपर देखें)।
- जाँचें कि SPF रिकॉर्ड एक ही है और हमारा include उसी रिकॉर्ड के भीतर है।
- थोड़ा रुककर फिर जाँचें: संभव है बदलाव अभी फैला न हो।
सत्यापन तक भेजना काम नहीं करता — यह जानबूझकर है
जब तक डोमेन सत्यापित नहीं है, संदेश भेजे नहीं जाते। «भेजे जाते हैं और स्पैम में गिरते हैं» नहीं — जाते ही नहीं: कोशिश असत्यापित डोमेन की त्रुटि के साथ ख़त्म होती है, और यह लॉग में दिखता है।
यह जानबूझकर है, कोई ख़राबी नहीं। जिस डोमेन ने अपनी ज़मानत नहीं दी, उससे गई डाक स्पैम की शिकायतों में बदलती है, और शिकायतें उस भेजने वाले ढाँचे की साख बिगाड़ती हैं जो प्लेटफ़ॉर्म के सभी ग्राहकों के लिए साझा है। एक संदेश न भेजना सस्ता है, बजाय इसके कि भेजकर छह महीने ब्लॉकलिस्ट से निकलने में लगें। इसीलिए यहाँ चेतावनी नहीं, रोक है।
यह त्रुटि दिखे तो सपोर्ट को लिखने से पहले DNS रिकॉर्ड जाँचें और सत्यापन दबाएँ। अधिकांश मामलों में कारण रिकॉर्ड के नाम में टाइपिंग की गलती ही होती है।
अनसब्सक्राइब, शिकायतें और डिलीवरी विफलताएँ
तीन नियम, जो पहले से न पता हों तो चौंकाते हैं।
हर विपणन संदेश में एक क्लिक में अनसब्सक्राइब होता है। प्लेटफ़ॉर्म खुद संदेश के फ़ुटर में अनसब्सक्राइब लिंक और वे तकनीकी हेडर जोड़ता है जिनसे मेल क्लाइंट भेजने वाले के पते के पास «सदस्यता छोड़ें» बटन बनाता है। इसे हटाया नहीं जा सकता — न सेटिंग से, न संदेश की सजावट से। अनसब्सक्राइब तुरंत लागू होता है, संदेश खोले बिना और पुष्टि के चरण के बिना। Gmail और बाकी बड़े प्रदाता थोक भेजने वालों से यही माँगते हैं: इसके बिना संदेश पक्का स्पैम में जाता है।
अनसब्सक्राइब अंतिम है और इंटरफ़ेस से पलटा नहीं जा सकता। अनसब्सक्राइब किया पता इस बॉट की डाक फिर नहीं पाता। न «वापस लाएँ» बटन है, न सूची दोबारा आयात करने का चोर रास्ता: व्यक्ति के सिर के ऊपर से अनसब्सक्राइब कभी रद्द नहीं होता। वह ख़ुद ही लौट सकता है — आपके सदस्यता फ़ॉर्म में दोबारा अपना पता देकर।
इससे भी सख़्त मामला है: अगर किसी ने मेल क्लाइंट में «यह स्पैम है» दबाया, तो पता हमेशा के लिए बंद हो जाता है। आपके फ़ॉर्म से नई सदस्यता भी उसे नहीं खोलती — क्योंकि हमें पहले से पता है कि पिछली कोशिश कैसे ख़त्म हुई थी, और ऐसे पतों पर भेजना डोमेन की साख सबसे तेज़ी से नष्ट करता है। कानूनी माँग पर हाथ से बंद किए पते भी ऐसे ही बर्ताव करते हैं।
स्थायी डिलीवरी विफलता पते को हमेशा के लिए बंद कर देती है। अगर पाने वाले का मेल सर्वर जवाब दे कि ऐसा मेलबॉक्स है ही नहीं, तो पता अवितरणीय चिह्नित होकर आगे की भेजाई से हट जाता है। यह अस्थायी स्थिति नहीं है: न होने वाले मेलबॉक्स पर लगातार दस्तक देना स्पैम फ़िल्टरों तक पहुँचने का सबसे छोटा रास्ता है, बाकी सारे पतों समेत।
अस्थायी विफलताएँ (मेलबॉक्स भरा, सर्वर फ़िलहाल अनुपलब्ध) पते को बंद नहीं करतीं — भेजना जारी रहता है।
«ओपन» के आँकड़े कम क्यों दिखते हैं
ईमेल आँकड़ों में ओपन का आँकड़ा होता है, और वह हमेशा असल से कम होता है। यह गिनती की गलती नहीं, बल्कि ओपन मापने के तरीके की बात है।
ओपन तब दर्ज होता है जब मेल क्लाइंट संदेश दिखाते समय सर्वर से एक नन्ही ट्रैकिंग तस्वीर लोड करता है। आधुनिक क्लाइंट डिफ़ॉल्ट रूप से दूरस्थ तस्वीरें लोड नहीं करते; और जो करते हैं (Apple Mail और वैसे ही निजता तंत्र), वे उन्हें सबके लिए पहले ही लोड कर लेते हैं — उनके लिए भी जिन्होंने संदेश कभी खोला नहीं। पहले मामले में ओपन खो जाता है, दूसरे में उस व्यक्ति के नाम चढ़ जाता है जो था ही नहीं। ईमेल ओपन को इससे सटीक गिनने का कोई तरीका नहीं है — न हमारे पास, न किसी और के पास।
इसीलिए इंटरफ़ेस में आँकड़े के पास चेतावनी रहती है: यह निचली सीमा है, सटीक संख्या नहीं। इसका उपयोग संदेशों की आपस में तुलना के लिए करें, जहाँ वही त्रुटि सब पर लागू होती है, पर «कितने लोगों ने संदेश पढ़ा» के जवाब के रूप में नहीं।
अगर भरोसेमंद सहभागिता मीट्रिक चाहिए तो «Link clicks» देखें। लिंक पर क्लिक असली इंसान की असली क्रिया है; उसे कोई पहले से उसके बदले नहीं करता। «Delivered», «Unsubscribes», «Complaints» और «Bounces» भी सटीक गिने जाते हैं: उनकी सूचना मेल सर्वर देते हैं, संदेश के भीतर की तस्वीर नहीं। ये सब उसी Email स्क्रीन के «Sending stats» ब्लॉक में हैं।
आगे क्या
- चैनल — मल्टीचैनल और चैनलों की क्षमताएँ।
- ब्रॉडकास्ट — बड़े पैमाने पर भेजना।
- एनालिटिक्स — आँकड़े कहाँ देखें।