तुमच्या ॲपमधून ईमेल कसे पाठवायचे (आणि ते इनबॉक्समध्ये कसे पोहोचवायचे)

तुमच्या ॲपमधून ईमेल विश्वासार्हपणे पाठवण्यासाठी, स्वतःच्या मेलबॉक्सऐवजी ईमेल पाठवणारा प्रोव्हायडर वापरा, तुमच्या स्वतःच्या डोमेनवरील पत्त्यावरून पाठवा, आणि प्रोव्हायडर देत असलेले DNS रेकॉर्ड जोडा, जेणेकरून SPF, DKIM आणि DMARC तिन्ही पास होतील. ट्रान्झॅक्शनल ईमेल, जसे की पासवर्ड रीसेट, पावत्या आणि पुष्टी, मार्केटिंग ईमेलपासून वेगळे ठेवा, प्रत्येक फक्त ज्यांना तो अपेक्षित आहे त्यांनाच पाठवा, आणि बाउन्स व अनसबस्क्राइब हाताळा. ऑथेंटिकेशन आधी नीट करा; ॲपचे ईमेल स्पॅममध्ये जाण्याचे हे सर्वात सामान्य कारण आहे.

ट्रान्झॅक्शनल विरुद्ध मार्केटिंग ईमेल

हे दोन्ही प्रकारचे ईमेल कोडमध्ये सारखे दिसतात, पण इनबॉक्स प्रोव्हायडर आणि कायदा त्यांना खूप वेगळे मानतात.

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

प्रोव्हायडर निवडणे

तुमच्या ॲपने स्वतःच्या सर्व्हरवरून थेट ईमेल पाठवू नये. ईमेल पाठवणारे प्रोव्हायडर इन्फ्रास्ट्रक्चर, IP प्रतिष्ठा, पुन्हा प्रयत्न आणि बाउन्स प्रक्रिया हाताळतात. सुप्रसिद्ध पर्यायांमध्ये Postmark, Resend, SendGrid, Amazon SES आणि Mailgun यांचा समावेश होतो; प्रत्येकाकडे HTTP API आणि SMTP प्रवेश आहे, आणि किंमती व प्लॅन बदलतात, म्हणून त्यांच्या स्वतःच्या साइटवर तुलना करा.

काय तुलना करायची:

• फोकस. काही प्रोव्हायडर ट्रान्झॅक्शनल ईमेलवर लक्ष केंद्रित करतात; तर काही ट्रान्झॅक्शनल आणि मार्केटिंग दोन्ही एकत्र देतात.
• डेव्हलपर अनुभव. स्पष्ट API, तुमच्या भाषेसाठी अधिकृत लायब्ररी, आणि प्रत्येक संदेश पोहोचला, बाउन्स झाला की स्पॅम म्हणून चिन्हांकित झाला हे दाखवणारे उपयुक्त लॉग.
• वेबहुक बाउन्स, तक्रारी आणि डिलिव्हरीसाठी, जेणेकरून तुमचे ॲप त्यावर प्रतिक्रिया देऊ शकेल.
• टेम्पलेट्स — प्रोव्हायडरकडे साठवलेले, किंवा तुमच्या स्वतःच्या कोडमध्ये. कोडमध्ये ठेवल्यास ते व्हर्जन केलेले आणि चाचणी करण्यायोग्य राहतात.
• प्रदेश आणि डेटा हाताळणी, डेटा कुठे प्रक्रिया होतो याबाबत तुमच्या काही आवश्यकता असल्यास.
• तुमच्या प्रमाणानुसार खर्च, मोफत टियरपेक्षा जास्त वापर झाल्यास काय होते तेही.

यादीवरील न्यूजलेटरसाठी, तुमच्या ॲपमध्येच मोहीम फीचर्स बांधण्यापेक्षा समर्पित न्यूजलेटर किंवा ईमेल मार्केटिंग टूल अनेकदा अधिक योग्य ठरते.

तुमचे सेंडिंग डोमेन सेट करा

तुमच्या स्वतःच्या डोमेनवरून पाठवा — 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: च्या लांब साखळ्या ही मर्यादा ओलांडून अपयश आणू शकतात.
• अनेक प्रोव्हायडर तुम्हाला तयार करायला सांगितलेल्या return-path सबडोमेनवर SPF सेट करतात, त्यामुळे तुम्हाला तुमचा मुख्य SPF रेकॉर्ड अजिबात बदलावा लागत नाही.

DKIM

DKIM (DomainKeys Identified Mail) प्रत्येक संदेशाला क्रिप्टोग्राफिक स्वाक्षरी जोडते. प्रोव्हायडर खाजगी की वापरून स्वाक्षरी करतो; तुम्ही जुळणारी सार्वजनिक की DNS रेकॉर्ड (प्रोव्हायडरनुसार TXT किंवा CNAME) म्हणून प्रकाशित करता. प्राप्तकर्ते स्वाक्षरी तपासतात, की संदेश अधिकृत पाठवणाऱ्याकडून आला आहे आणि मार्गात बदललेला नाही.

प्रोव्हायडरच्या "verify domain" पायरीचा मुख्य भाग 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 आणि स्थिती — की किंवा वैयक्तिक डेटा असलेले संपूर्ण मेसेज बॉडी नोंदवू नका.
5. बाउन्स आणि तक्रारींसाठी वेबहुक हाताळा: हार्ड बाउन्स झालेल्या किंवा तुम्हाला स्पॅम म्हणून चिन्हांकित करणाऱ्या पत्त्यांवर पाठवणे थांबवा.

मूलभूत गोष्टी कव्हर करणारी एक प्रॉम्प्ट:

[PROVIDER] वापरून ट्रान्झॅक्शनल ईमेल पाठवा, सर्व्हर सीक्रेट [ENV_NAME] वापरून, "Acme hello@mail.acme.com" वरून. साइन-अप नंतर स्वागत ईमेल आणि बुकिंग जतन झाल्यावर बुकिंग पुष्टी पाठवा. टेम्पलेट्स कोडमध्ये ठेवा, HTML सोबत साध्या-मजकूर आवृत्तीसह. पाठवणे रांगेत टाका आणि तात्पुरत्या अपयशांवर तीन वेळा पर्यंत पुन्हा प्रयत्न करा. प्रोव्हायडरच्या त्रुटीसह अपयश नोंदवा, पण API की कधीही नाही. एक वेबहुक एंडपॉइंट जोडा जो हार्ड बाउन्स आणि तक्रारींवर पत्त्यांना undeliverable म्हणून चिन्हांकित करतो, आणि भविष्यात ते पत्ते वगळा.

खाते ईमेल — पडताळणी लिंक, मॅजिक लिंक आणि पासवर्ड रीसेट — हे लॉगिनचा भाग आहेत. तुमच्या ॲपमध्ये लॉगिन कसे जोडायचे हे प्रवाह एकत्र कसे बसतात ते सांगते; या लिंक एकदाच वापरता येतील आणि अल्पकाळ वैध ठेवा.

डिलिव्हरेबिलिटीच्या सवयी

ऑथेंटिकेशनमुळे तुमचा मेल विचारात घेतला जातो. वर्तणूक तुम्हाला इनबॉक्समध्ये ठेवते.

• लोकांना अपेक्षित असलेलेच पाठवा. पुष्टी केलेले साइन-अप, मार्केटिंगसाठी स्पष्ट opt-in, विकत घेतलेल्या याद्या नाहीत.
• अनसबस्क्राइब करणे सोपे करा जे काटेकोरपणे ट्रान्झॅक्शनल नाही त्यावर, आणि ते लगेच मान्य करा.
• नवीन डोमेन हळूहळू तापवा. पहिल्याच दिवशी हजारो संदेश पाठवणारे नवीन डोमेन संशयास्पद दिसते. तुमच्या ट्रान्झॅक्शनल मेलपासून सुरुवात करा आणि प्रमाण हळूहळू वाढवा.
• याद्या स्वच्छ ठेवा. हार्ड बाउन्स लगेच काढा, आणि बऱ्याच काळापासून काहीही न उघडलेल्या लोकांना काढण्याचा विचार करा.
• माणसासारखे लिहा. स्पष्ट विषय, ओळखता येईल असे From नाव, साधा-मजकूर भाग, कमी प्रतिमा आणि तुमच्या स्वतःच्या डोमेनवरील लिंक. लिंक शॉर्टनर टाळा.
• निरीक्षण करा. तुमचे डोमेन Google Postmaster Tools मध्ये नोंदवा आणि अधूनमधून DMARC अहवाल वाचा.
• खरा रिप्लाय-टू वापरा जो कोणीतरी वाचतो. उत्तरे हा चांगला संकेत आहे, आणि उपयुक्त अभिप्रायही.

कोणालाही स्पॅम न करता चाचणी

• तुमच्या प्रोव्हायडरकडे टेस्ट मोड किंवा सँडबॉक्स असल्यास तो वापरा, किंवा तुमच्या मालकीच्या पत्त्यांवर पाठवा.
• डेव्हलपमेंटमध्ये, खऱ्या युझर्सऐवजी कॅच-ऑल टेस्ट इनबॉक्स वर पाठवा; खऱ्या दिसणाऱ्या पत्त्यांनी भरलेला सीड केलेला डेटाबेस हा चुकून अनोळखी लोकांना ईमेल करण्याचा सोपा मार्ग आहे.
• प्रत्येक टेम्पलेट काही क्लायंटमध्ये तपासा — वेबवरील Gmail, फोनचे मेल ॲप, Outlook — आणि डार्क मोडमध्येही.
• चाचणी ईमेलचे मेसेज हेडर पहा: त्यात SPF, DKIM आणि DMARC पास झाले की नाही दिसते.

कायद्याच्या मूलभूत गोष्टी

नियम देशानुसार वेगळे असतात. साधारणपणे, मार्केटिंग ईमेलला अनेक ठिकाणी संमती लागते, पाठवणाऱ्याची ओळख द्यावी लागते आणि काम करणारे अनसबस्क्राइब द्यावे लागते; ट्रान्झॅक्शनल ईमेलला वेगळे वागवले जाते, पण त्याद्वारे मार्केटिंग चोरट्या मार्गाने पाठवू नये. जर तुम्ही वेटलिस्ट पेज वरून पत्ते गोळा करत असाल, तर काय, कधी आणि कसे पाठवाल आणि साठवाल ते प्रत्येक व्यक्तीच्या साइन-अपसह स्पष्ट सांगा. शंका असल्यास, तुमच्या युझर्सच्या ठिकाणचे नियम तपासा.

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

• सेंडिंग प्रोव्हायडर निवडला; API की सर्व्हर सीक्रेट म्हणून साठवली
• तुमच्या स्वतःच्या डोमेन किंवा सबडोमेनवरून पाठवणे, मोफत मेलबॉक्सवरून नाही
• SPF, DKIM आणि DMARC रेकॉर्ड जोडले आणि पास होत आहेत
• ट्रान्झॅक्शनल आणि मार्केटिंग मेल वेगळे ठेवले
• पाठवणे रांगेत टाकले आणि पुन्हा प्रयत्न केले; निकाल नोंदवले
• बाउन्स आणि तक्रार वेबहुक हाताळले
• ट्रान्झॅक्शनल नसलेल्या मेलवर अनसबस्क्राइब, लगेच मान्य
• टेम्पलेट्स अनेक क्लायंटमध्ये तपासले; चाचणी मेल कधीही खऱ्या युझर्सपर्यंत जात नाही

Mythex ॲपमधून ईमेल पाठवणे

Mythex तुम्ही बनवलेल्या ॲप्ससाठी अंगभूत ईमेल पाठवण्याची सेवा देत नाही, त्यामुळे तुम्ही Resend, SendGrid किंवा Postmark सारखा प्रोव्हायडर आणता. त्याची API की प्रोजेक्ट सीक्रेट म्हणून साठवा — एजंट चॅटमधील सीक्रेट्स कार्डद्वारे ती मागू शकतो — आणि तुम्हाला हवे असलेले ईमेल साध्या शब्दांत मागा. डॉक्समध्ये तुमच्या ॲपमधून ईमेल पाठवा येथे स्टार्टर प्रॉम्प्ट आहे. जर तुम्ही Pro वर Mythex मार्फत डोमेन विकत घेतला असेल, तर डोमेनच्या DNS सेटिंग्जमध्ये प्रोव्हायडरचे TXT आणि CNAME रेकॉर्ड जोडू शकता; पहा कस्टम डोमेन.

प्रश्न