अपने ऐप से ईमेल कैसे भेजें (और इनबॉक्स तक कैसे पहुँचाएँ)

अपने ऐप से भरोसेमंद तरीके से ईमेल भेजने के लिए, अपने मेलबॉक्स से नहीं बल्कि एक ईमेल भेजने वाला प्रोवाइडर इस्तेमाल करें, अपने ही डोमेन के पते से भेजें, और प्रोवाइडर जो DNS रिकॉर्ड देता है उन्हें जोड़ें ताकि SPF, DKIM और DMARC तीनों पास हों। ट्रांज़ैक्शनल ईमेल, जैसे पासवर्ड रीसेट, रसीद और पुष्टि, को मार्केटिंग ईमेल से अलग रखें, हर ईमेल सिर्फ़ उन्हीं लोगों को भेजें जो उसकी उम्मीद करते हैं, और बाउंस व अनसब्सक्राइब को संभालें। सबसे पहले प्रमाणीकरण सही करें; ऐप के ईमेल स्पैम में जाने का यह सबसे आम कारण है।

ट्रांज़ैक्शनल बनाम मार्केटिंग ईमेल

कोड में ये दोनों एक जैसे दिखते हैं, लेकिन इनबॉक्स प्रोवाइडर और कानून दोनों इन्हें बहुत अलग तरह से देखते हैं।

इन्हें अलग रखें। अगर किसी मार्केटिंग कैंपेन पर स्पैम शिकायतें आती हैं, तो आप नहीं चाहेंगे कि उसी स्ट्रीम से जाने वाले पासवर्ड रीसेट भी इसकी वजह से प्रभावित हों। एक आम तरीका है अलग सबडोमेन रखना, जैसे अकाउंट ईमेल के लिए mail.example.com और न्यूज़लेटर के लिए news.example.com; कुछ प्रोवाइडर इन्हें अपने अंदर भी अलग रखते हैं। उदाहरण के लिए, Postmark सितंबर 2026 तक अपनी ट्रांज़ैक्शनल और ब्रॉडकास्ट "मैसेज स्ट्रीम" को अलग भेजने के इंफ्रास्ट्रक्चर पर चलने के रूप में बताता है।

प्रोवाइडर चुनना

आपके ऐप को अपने सर्वर से खुद ईमेल नहीं भेजना चाहिए। ईमेल भेजने वाले प्रोवाइडर इंफ्रास्ट्रक्चर, IP प्रतिष्ठा, दोबारा कोशिश (retries) और बाउंस प्रोसेसिंग संभालते हैं। जाने-माने विकल्पों में Postmark, Resend, SendGrid, Amazon SES और Mailgun शामिल हैं; इन सबके पास HTTP API और SMTP एक्सेस है। कीमतें और प्लान बदलते रहते हैं, इसलिए इन्हें उनकी अपनी साइट्स पर जाकर तुलना करें।

तुलना में इन बातों को देखें:

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

किसी सूची पर न्यूज़लेटर के लिए, अपने ऐप में कैंपेन फीचर बनाने की तुलना में एक समर्पित न्यूज़लेटर या ईमेल मार्केटिंग टूल अक्सर बेहतर होता है।

अपना भेजने वाला डोमेन सेट करें

अपने ही डोमेन से भेजें, जैसे hello@example.com, न कि Gmail या Outlook के पते से। फ्री मेलबॉक्स का पता किसी थर्ड-पार्टी सर्विस से भेजा जाए तो वह प्रमाणीकरण जाँच में फेल होता है और फ़िल्टर होने की संभावना रहती है।

सिर्फ़ भेजने के लिए एक सबडोमेन पर विचार करें। उदाहरण के लिए, Resend सितंबर 2026 तक भेजने वाली प्रतिष्ठा को अलग रखने के लिए updates.example.com जैसे सबडोमेन से भेजने की सलाह देता है। इससे ईमेल के DNS रिकॉर्ड भी आपकी मुख्य साइट के रिकॉर्ड से अलग रहते हैं।

प्रोवाइडर आपको DNS रिकॉर्ड देगा जिन्हें आप वहाँ जोड़ेंगे जहाँ आपके डोमेन का DNS मैनेज होता है। अगर DNS आपके लिए नया है, तो डोमेन और DNS कैसे काम करते हैं पहले रिकॉर्ड्स को समझाता है।

SPF

SPF (Sender Policy Framework) एक TXT रिकॉर्ड है जिसमें लिखा होता है कि आपके डोमेन की ओर से कौन से सर्वर ईमेल भेज सकते हैं। प्राप्त करने वाला सिस्टम जाँचता है कि भेजने वाला सर्वर इस सूची में है या नहीं।

• किसी डोमेन पर सिर्फ़ एक SPF रिकॉर्ड होना चाहिए। प्रोवाइडर जोड़ें तो उसे मौजूदा रिकॉर्ड में मिलाएँ, दूसरा रिकॉर्ड न जोड़ें।
• SPF का मूल्यांकन करते समय अधिकतम 10 DNS लुकअप की अनुमति है; include: एंट्रीज़ की लंबी चेन इस सीमा को पार कर सकती है और फेल होने का कारण बन सकती है।
• कई प्रोवाइडर SPF उस return-path सबडोमेन पर सेट करते हैं जो वे आपसे बनवाते हैं, इसलिए हो सकता है आपको अपने मुख्य SPF रिकॉर्ड को छूना ही न पड़े।

DKIM

DKIM (DomainKeys Identified Mail) हर संदेश में एक क्रिप्टोग्राफ़िक सिग्नेचर जोड़ता है। प्रोवाइडर एक प्राइवेट की से साइन करता है; आप मैचिंग पब्लिक की को DNS रिकॉर्ड के रूप में प्रकाशित करते हैं (प्रोवाइडर के अनुसार TXT या CNAME)। प्राप्त करने वाले सिस्टम सिग्नेचर की जाँच करके पक्का करते हैं कि संदेश किसी अधिकृत भेजने वाले से आया और रास्ते में बदला नहीं गया।

आपके प्रोवाइडर का "डोमेन सत्यापित करें" वाला स्टेप मुख्य रूप से DKIM के बारे में ही है। इसे छोड़ें नहीं।

DMARC

DMARC बाकी दोनों को आपस में जोड़ता है। यह _dmarc.yourdomain.com पर एक TXT रिकॉर्ड है, जो प्राप्त करने वाले सिस्टम को बताता है:

• अलाइनमेंट: दिखने वाले From पते का डोमेन उस डोमेन से मेल खाना चाहिए जो SPF या DKIM में पास हुआ।
• नीति: जो संदेश फेल हों उनके साथ क्या करना है: p=none (केवल रिपोर्ट करें), p=quarantine (संदिग्ध मानें, अक्सर स्पैम) या p=reject।
• रिपोर्ट: एग्रीगेट रिपोर्ट कहाँ भेजनी हैं (rua=), ताकि आप देख सकें कि आपके डोमेन की ओर से कौन भेज रहा है।

एक समझदार रास्ता है कि p=none और रिपोर्टिंग पते से शुरू करें, पक्का करें कि आपका असली मेल पास हो रहा है, फिर quarantine और आखिर में reject पर जाएँ। सख्त नीति से दूसरों के लिए आपके डोमेन की स्पूफिंग भी बहुत मुश्किल हो जाती है।

Gmail क्या माँगता है

सितंबर 2026 तक, Google के सेंडर दिशानिर्देश कहते हैं:

• सभी भेजने वाले जो निजी Gmail अकाउंट पर भेजते हैं, उन्हें SPF या DKIM, भेजने वाले सर्वरों के लिए मान्य forward और reverse DNS, TLS, और Postmaster Tools में 0.3% से कम स्पैम दर चाहिए।
• बल्क भेजने वाले (Gmail पर रोज़ 5,000 से ज़्यादा संदेश) को SPF और DKIM, एक DMARC रिकॉर्ड (p=none नीति मान्य है), From-डोमेन अलाइनमेंट, और मार्केटिंग व सब्सक्राइब किए गए संदेशों पर वन-क्लिक अनसब्सक्राइब के साथ एक दिखने वाला अनसब्सक्राइब लिंक चाहिए।

सर्वर की ओर के हिस्से आपका प्रोवाइडर संभालता है। DNS रिकॉर्ड और अनसब्सक्राइब प्रबंधन आपकी ज़िम्मेदारी है। भले ही आप रोज़ 5,000 के आसपास भी न हों, बल्क नियमों का पालन करना सुरक्षित रहने का सबसे सरल तरीका है।

ऐप में भेजने की व्यवस्था बनाएँ

डोमेन सत्यापित होने के बाद:

1. API की को सर्वर-साइड सीक्रेट के रूप में सहेजें, कभी भी फ्रंट-एंड कोड में नहीं। देखें एनवायरनमेंट वेरिएबल और सीक्रेट्स क्या हैं।
2. सर्वर से भेजें, उस कार्रवाई के सफल होने के बाद जो ईमेल को ट्रिगर करती है।
3. यूज़र को ईमेल का इंतज़ार न कराएँ। सबसे सरल ऐप से आगे के किसी भी ऐप के लिए, भेजने को क्यू में डालें और अस्थायी विफलताओं पर दोबारा कोशिश करें, ताकि प्रोवाइडर की धीमी प्रतिक्रिया साइन-अप को धीमा न करे।
4. परिणाम लॉग करें — प्रोवाइडर का संदेश ID और स्थिति — लेकिन API की को कभी नहीं, और निजी डेटा वाले पूरे संदेश के बॉडी को भी लॉग न करें।
5. बाउंस और शिकायतों के लिए webhooks हैंडल करें: जिन पतों पर हार्ड बाउंस हो या जो आपको स्पैम के रूप में चिह्नित करें, उन्हें भेजना बंद करें।

बुनियादी बातों को कवर करने वाला एक प्रॉम्प्ट:

[PROVIDER] के साथ सर्वर सीक्रेट [ENV_NAME] का उपयोग करके ट्रांज़ैक्शनल ईमेल भेजें, "Acme hello@mail.acme.com" के नाम से। साइन-अप के बाद स्वागत ईमेल और बुकिंग सेव होने के बाद बुकिंग की पुष्टि भेजें। टेम्पलेट कोड में रखें, HTML के साथ सादे-टेक्स्ट वर्ज़न भी रखें। भेजने को क्यू में डालें और अस्थायी विफलताओं पर तीन बार तक दोबारा कोशिश करें। विफलताओं को प्रोवाइडर की त्रुटि के साथ लॉग करें, लेकिन API की कभी नहीं। एक webhook endpoint जोड़ें जो हार्ड बाउंस और शिकायतों पर पतों को अनडिलिवरेबल चिह्नित करे, और आगे उन पतों को छोड़ दे।

अकाउंट के ईमेल, जैसे वेरिफिकेशन लिंक, मैजिक लिंक और पासवर्ड रीसेट, लॉगिन का हिस्सा हैं। अपने ऐप में लॉगिन कैसे जोड़ें बताता है कि ये फ्लो कैसे जुड़ते हैं; ये लिंक एक बार इस्तेमाल होने वाले और कम समय के लिए वैध रखें।

डिलिवरेबिलिटी की आदतें

प्रमाणीकरण आपको विचार में आने का मौका देता है। व्यवहार आपको इनबॉक्स में बनाए रखता है।

• वही भेजें जिसकी लोगों को उम्मीद हो। पुष्टि किए गए साइन-अप, मार्केटिंग के लिए साफ़ सहमति, खरीदी हुई सूचियाँ नहीं।
• सख्ती से ट्रांज़ैक्शनल न होने वाली हर चीज़ पर अनसब्सक्राइब आसान बनाएँ, और उसे तुरंत लागू करें।
• नए डोमेन को धीरे-धीरे गर्म करें। एक नया डोमेन पहले ही दिन हज़ारों संदेश भेजे तो संदिग्ध लगता है। अपने ट्रांज़ैक्शनल मेल से शुरू करें और मात्रा धीरे-धीरे बढ़ाएँ।
• सूचियाँ साफ रखें। हार्ड बाउंस तुरंत हटाएँ, और उन लोगों को भी हटाने पर विचार करें जिन्होंने लंबे समय से कुछ नहीं खोला।
• इंसान की तरह लिखें। साफ़ सब्जेक्ट, पहचाना जाने वाला From नाम, एक सादा-टेक्स्ट हिस्सा, कम इमेज, और अपने डोमेन के लिंक। लिंक शॉर्टनर से बचें।
• निगरानी रखें। अपने डोमेन को Google Postmaster Tools में रजिस्टर करें और समय-समय पर DMARC रिपोर्ट पढ़ें।
• एक असली reply-to पता रखें जिसे कोई पढ़ता हो। जवाब अच्छा संकेत होते हैं, और उपयोगी फीडबैक भी।

किसी को स्पैम किए बिना टेस्ट करना

• जहाँ हो वहाँ अपने प्रोवाइडर का टेस्ट मोड या सैंडबॉक्स इस्तेमाल करें, या ऐसे पतों पर भेजें जो आपके अपने हों।
• डेवलपमेंट में असली यूज़र्स की बजाय एक कैच-ऑल टेस्ट इनबॉक्स पर भेजें; असली दिखने वाले पतों से भरा seed किया हुआ डेटाबेस गलती से अजनबियों को ईमेल भेजने का आसान तरीका है।
• हर टेम्पलेट को कुछ क्लाइंट्स में जाँचें: वेब पर Gmail, फोन का मेल ऐप, Outlook, और डार्क मोड में भी।
• टेस्ट ईमेल के मेसेज हेडर देखें: उनसे पता चलता है कि SPF, DKIM और DMARC पास हुए या नहीं।

कानूनी बुनियादी बातें

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

ईमेल चेकलिस्ट

• भेजने वाला प्रोवाइडर चुना गया; API की सर्वर सीक्रेट के रूप में सहेजी गई
• अपने डोमेन या सबडोमेन से भेजा जा रहा है, फ्री मेलबॉक्स से नहीं
• SPF, DKIM और DMARC रिकॉर्ड जोड़े गए और पास हो रहे हैं
• ट्रांज़ैक्शनल और मार्केटिंग मेल अलग किए गए
• भेजने को क्यू में डाला और दोबारा कोशिश की जाती है; परिणाम लॉग होते हैं
• बाउंस और शिकायत के webhooks हैंडल होते हैं
• सख्ती से ट्रांज़ैक्शनल न होने वाले मेल पर अनसब्सक्राइब है, और तुरंत लागू होता है
• टेम्पलेट कई क्लाइंट्स में टेस्ट किए गए; टेस्ट मेल कभी असली यूज़र्स तक नहीं पहुँचता

Mythex ऐप से ईमेल भेजना

Mythex आपके बनाए ऐप्स के लिए कोई अंतर्निहित ईमेल भेजने की सर्विस शामिल नहीं करता, इसलिए आप Resend, SendGrid या Postmark जैसा प्रोवाइडर लाते हैं। उसकी API की को प्रोजेक्ट सीक्रेट के रूप में सहेजें — एजेंट चैट में सीक्रेट्स कार्ड के ज़रिए इसे माँग सकता है — और जो ईमेल चाहिए उन्हें सादे शब्दों में माँगें। डॉक्स में ऐप से ईमेल भेजना में एक स्टार्टर प्रॉम्प्ट है। अगर आपने Pro पर Mythex के ज़रिए डोमेन खरीदा है, तो डोमेन की DNS सेटिंग्स में प्रोवाइडर के TXT और CNAME रिकॉर्ड जोड़ सकते हैं; देखें कस्टम डोमेन।

सवाल