हर ग्राहक, ब्रांड या एनवायरनमेंट को अपनी कुंजियाँ, डोमेन और रिपोर्टिंग दें, अपने मेल सर्वर चलाए बिना।
एजेंट-रेडी API और AI सपोर्ट ट्राइएज के साथ SaaS के लिए मल्टी-टेनेंट ईमेल
एक टेनेंट स्पैम भेजता है और सबको प्रभावित करता है
प्रति-वर्कस्पेस सीमाएँ और सप्रेशन एक प्रेषक को बाकियों को नुकसान पहुँचाने से रोकते हैं।
ग्राहक अपना सेंडिंग डोमेन चाहते हैं
डोमेन ऑनबोर्डिंग और सत्यापन के फ़्लो API से चलते हैं।
हर रिलीज़ के साथ ईमेल बदलाव आते हैं
वर्ज़न वाले टेम्पलेट प्रोडक्ट और सपोर्ट को कंटेंट सुरक्षित रूप से अपडेट करने देते हैं।
मल्टी-टेनेंट ईमेल तब काम करता है जब हर ग्राहक अपनी कुंजियों, डोमेन और सीमाओं वाली अलग इकाई हो, और सब कुछ आपका प्रोडक्ट प्रबंधित करे।
SaaS के लिए ईमेल उन संदेशों का समूह है जो कोई सॉफ़्टवेयर प्रोडक्ट अपने यूज़र की ओर से भेजता है: वर्कस्पेस आमंत्रण, उपयोग अलर्ट, डाइजेस्ट, बिलिंग सूचनाएँ और कई प्रोडक्ट में ग्राहक के अपने ब्रांड के तहत भेजा मेल। यह सामान्य ऐप ईमेल से कठिन है क्योंकि कई टेनेंट एक ही सेंडिंग प्लेटफ़ॉर्म साझा करते हैं, इसलिए डिज़ाइन को उनकी सीमाएँ, डोमेन, कुंजियाँ और प्रतिष्ठा अलग रखनी होती हैं और डेवलपर के लिए इंटीग्रेशन सरल भी रखना होता है। अच्छा डिज़ाइन टेनेंट को एक-दूसरे पर असर डालने से रोकता है।
शुरुआती SaaS टीमें सब कुछ एक अकाउंट और एक डोमेन से भेजती हैं। ग्राहक बढ़ने पर समस्याएँ जमा होती हैं: एक टेनेंट की खराब सूची सबकी डिलीवरी बिगाड़ देती है, ग्राहक अपने डोमेन से भेजने को कहते हैं, प्रोडक्ट और सपोर्ट रिलीज़ के बिना टेम्पलेट बदलना चाहते हैं, और कोई नहीं बता पाता कि किसी यूज़र को आमंत्रण क्यों नहीं मिला। टेनेंट नियंत्रण खुद बनाने में इंजीनियरिंग का समय प्रोडक्ट से हट जाता है। इस बीच सपोर्ट के पास कोई जवाब नहीं होता।
MigoMTA पर बना MigoSMTP अलग कुंजियों, सीमाओं और रिपोर्ट वाले वर्कस्पेस, API से डोमेन ऑनबोर्डिंग, वर्ज़न वाले टेम्पलेट और ऐसे webhook देता है जो डिलीवरी की स्थिति आपके प्रोडक्ट में लौटाते हैं। एजेंट-रेडी API और सपोर्ट कोपायलट आपकी टीम को 'यह क्यों नहीं पहुँचा' का जवाब जल्दी देने और असामान्य बाउंस पैटर्न वाले टेनेंट चिह्नित करने में मदद करते हैं। कोई भी निलंबन या कॉन्फ़िगरेशन बदलाव लोग मंज़ूर करते हैं। रिपोर्ट नतीजों को वर्कस्पेस के अनुसार बाँटती हैं।
साथी द्वारा ट्रिगर किए गए आमंत्रण भेजें, डिलीवरी इवेंट आपके ऐप में लौटाकर ताकि आमंत्रित करने वाला देख सके कि संदेश बाउंस हुआ या नहीं और पता सुधार सके।
थ्रेशहोल्ड पार होने पर एडमिन को सूचित करें, प्राथमिकता वाली सेंडिंग से ताकि अलर्ट डाइजेस्ट के पीछे कतार में न फँसें, और अपने ऑडिट ट्रेल के लिए डिलीवरी दर्ज करें। अलर्ट ऑडिट योग्य रहते हैं।
हर वर्कस्पेस और यूज़र के लिए साप्ताहिक सारांश चलाएँ, थ्रॉटल के साथ ताकि बड़े टेनेंट का डाइजेस्ट उसी समय छोटे टेनेंट के लिए ज़रूरी क्षमता न ले ले।
ग्राहकों को ऑनबोर्डिंग फ़्लो से अपना डोमेन सत्यापित करने दें और अपने ब्रांड के तहत भेजने दें, पहले उपयोग से पहले SPF और DKIM जाँच पूरी होने के बाद। असत्यापित डोमेन ब्लॉक रहते हैं।
टेनेंट को अपने सत्यापित डोमेन से भेजने दें, जबकि सीमाओं और सप्रेशन पर नियंत्रण आपके पास रहे।
प्लान सीमा के करीब पहुँचते ही ग्राहकों को चेताएँ और भुगतान की पुष्टि करें, सब कुछ वर्ज़न किए जा सकने वाले टेम्पलेट से।
शुरुआत में एक अकाउंट सरल है। टेनेंट बढ़ने पर अलगाव सबकी रक्षा करता है।
पहले टेनेंट से ही वर्कस्पेस के साथ शुरू करें। बाद में माइग्रेट करना अलग शुरू करने से कहीं कठिन है।
यूज़र का ईमेल दर्ज करें और पूछें कि आमंत्रण क्यों नहीं पहुँचा। कोपायलट संदेश लॉग पढ़कर डिलीवरी के रास्ते का सारांश देता है। स्टाफ़ की मंज़ूरी के बिना वह कुछ दोबारा नहीं भेज सकता या बदल नहीं सकता।
ऐसे वर्कस्पेस पहचानें जिनके बाउंस या शिकायत पैटर्न सामान्य से भटक रहे हों और उन्हें समीक्षा के लिए सामने लाएँ। चेतावनी देनी है, थ्रॉटल करना है या टेनेंट को छोड़ देना है, यह आपकी टीम तय करती है।
MCP-संगत सतह स्वीकृत आंतरिक एजेंट को स्कोप्ड कुंजियों से वर्कस्पेस प्रोविज़न करने या डोमेन स्थिति जाँचने देती है। अधिक प्रभाव वाली कार्रवाइयों के लिए मानवीय अनुमोदन चरण अनिवार्य किया जा सकता है। हर कॉल लॉग होती है।
प्रोडक्ट ईमेल के अनुवादित या नए शब्दों वाले संस्करणों के ड्राफ़्ट बनाएँ ताकि समीक्षा हो सके। प्रोडक्ट ओनर हर संस्करण को संपादित और अनुमोदित करते हैं, उसके बाद ही वह वर्ज़न वाले टेम्पलेट में लाइव होता है।
AI फ़ीचर सहायक और सलाहकार भूमिका में हैं, इसलिए आपकी इंजीनियरिंग और सपोर्ट टीमें सुझावों की समीक्षा करती हैं और टेनेंट, टेम्पलेट व सेंडिंग संबंधी निर्णय अपने हाथ में रखती हैं।
हर ग्राहक के लिए कुंजियाँ, सीमाएँ और रिपोर्ट अलग रखें ताकि एक शोर करने वाला प्रेषक दूसरों को नुकसान न पहुँचाए और आप उपयोग साफ़ देख सकें।
SPF और DKIM पास होने तक ग्राहक के डोमेन के नाम से कभी न भेजें। साझा प्रतिष्ठा की रक्षा के लिए असत्यापित डोमेन API स्तर पर ब्लॉक करें।
प्रोडक्ट ईमेल वर्ज़न वाले टेम्पलेट में रखें ताकि सपोर्ट और प्रोडक्ट कॉपी सुरक्षित रूप से अपडेट कर सकें और बदलाव से समस्या हो तो रोलबैक कर सकें।
कार्रवाई के पास ही webhook से डिलीवर, बाउंस या टला हुआ दिखाएँ, जिससे गुम ईमेल पर सपोर्ट टिकट घटते हैं।
डिफ़ॉल्ट सेंडिंग कैप लागू करें और अनुरोध पर बढ़ाएँ, ताकि समझौता हुआ अकाउंट किसी के ध्यान देने से पहले बड़ा वॉल्यूम न भेज सके।
अपना टेनेंट मॉडल डिज़ाइन कर रहे हैं? हमारी टीम आपके साथ उसकी समीक्षा कर सकती है।
ऐसा ईमेल API इस्तेमाल करें जिसमें हर टेनेंट के लिए अलग वर्कस्पेस या सब-अकाउंट हो, जिसकी अपनी कुंजियाँ, सीमाएँ और रिपोर्टिंग हों। सेंडिंग डोमेन प्रमाणित करें, इवेंट webhook से वापस रूट करें और प्रति-टेनेंट सप्रेशन लागू करें ताकि एक ग्राहक का खराब डेटा दूसरों को प्रभावित न करे।
हाँ, डोमेन ऑनबोर्डिंग फ़्लो के साथ: ग्राहक DNS रिकॉर्ड जोड़ता है, आप SPF और DKIM सत्यापित करते हैं, और उसके बाद ही सेंडिंग चालू करते हैं। API इसे स्वचालित कर सकता है, इसलिए आपका प्रोडक्ट मैन्युअल सपोर्ट के बिना हर ग्राहक को सेटअप में मार्गदर्शन देता है।
टेनेंट को अलग वर्कस्पेस में आइसोलेट करें, सेंडिंग सीमाएँ लगाएँ, बाउंस और शिकायतें अपने आप सप्रेस करें और हर टेनेंट की दरों की निगरानी करें। अगर जोखिम भरे या अधिक वॉल्यूम वाले टेनेंट का व्यवहार दूसरों को प्रभावित करने लगे तो उन्हें उनके अपने IP पूल में ले जाएँ। हर टेनेंट के बढ़ने पर सीमाओं की समीक्षा करें।
टेम्पलेट को एप्लिकेशन कोड से बाहर वर्ज़न, वेरिएबल और समीक्षा चरण के साथ रखें। इससे प्रोडक्ट और सपोर्ट डिप्लॉय के बिना कंटेंट संपादित कर सकते हैं, जबकि इंजीनियर भेजे जाने वाले डेटा पर नियंत्रण रखते हैं और खराब बदलाव रोलबैक कर सकते हैं। हर रिलीज़ टैग करें ताकि बदलाव ट्रेस हो सकें।
webhook इवेंट सब्सक्राइब करें और डिलीवर, बाउंस और टली हुई स्थिति को अपने डेटाबेस में संबंधित रिकॉर्ड के साथ सहेजें। तब आपका इंटरफ़ेस मेलबॉक्स पढ़े बिना स्टेटस बैज या रीसेंड प्रॉम्प्ट दिखा सकता है। इससे बार-बार आने वाले सपोर्ट टिकट भी उल्लेखनीय रूप से घटते हैं।
ज़्यादातर SaaS टीमें एप्लिकेशन सेंड के लिए HTTP API इस्तेमाल करती हैं क्योंकि वह मेटाडेटा, आइडेम्पोटेंसी और बेहतर एरर सपोर्ट करता है। SMTP पुराने सिस्टम, प्लगइन और थर्ड-पार्टी टूल के लिए उपयोगी है। दोनों एक ही वर्कस्पेस में चल सकते हैं। कई टीमें दोनों साथ चलाती हैं, बिना किसी टकराव के।
हाँ, स्कोप्ड कुंजियों वाले MCP-संगत इंटरफ़ेस से। आप तय करते हैं कि एजेंट कौन-सी कार्रवाइयाँ कर सकते हैं, जैसे केवल-पढ़ने वाली स्टेटस जाँच बनाम भेजने के ड्राफ़्ट, और किसी भी संवेदनशील चीज़ के लिए मानवीय अनुमोदन अनिवार्य कर सकते हैं।
कोपायलट किसी यूज़र का संदेश लॉग पढ़कर डिलीवरी का रास्ता सरल भाषा में समझा सकता है, जैसे बाउंस का कारण या डिफ़रल। स्टाफ़ सारांश की समीक्षा करता है और आगे की कार्रवाई तय करता है।
हमें अपने वॉल्यूम और सेटअप के बारे में बताएँ और हम आपको सही कॉन्फ़िगरेशन समझाएँगे।
खाता बनाएँ, अपना डोमेन जोड़ें और पहला ईमेल भेजें।