अपने एप्लिकेशन, CMS या डिवाइस को MigoSMTP की ओर पॉइंट करें और बिल्कुल वैसे ही भेजते रहें जैसे आज भेजते हैं, प्रमाणीकरण, TLS और सीमाएँ हम सँभालते हैं।
AI कोपायलट हर बाउंस और डिफ़रल सरल भाषा में समझाता है।
SMTP पर भेज सकने वाले हर फ़्रेमवर्क, CMS, प्लगइन, स्क्रिप्ट या डिवाइस के साथ काम करता है। STARTTLS से कनेक्ट करें; बिना एन्क्रिप्शन वाले कनेक्शन स्वीकार नहीं किए जाते।
हर एप्लिकेशन, एनवायरनमेंट या क्लाइंट के लिए अलग क्रेडेंशियल बनाएँ, ताकि बाकी को छुए बिना किसी एक को रोटेट या बंद कर सकें।
हर अकाउंट पर वॉल्यूम सीमित करें, ताकि कोई बेकाबू जॉब या लीक हुआ पासवर्ड आपका कोटा या आपकी प्रतिष्ठा खत्म न कर सके।
अकाउंट को केवल आपके भरोसेमंद सर्वर पतों तक सीमित करें, ताकि चुराए गए क्रेडेंशियल कहीं और बेकार रहें।
हार्ड बाउंस और शिकायतें आपके लिए सप्रेस हो जाती हैं, और अस्थायी विफलताएँ विफल गिने जाने से पहले रीट्राई की जाती हैं।
कोई भी संदेश ढूँढें और उसके SMTP रिस्पॉन्स, रीट्राई और अंतिम स्थिति देखें, ताकि सपोर्ट बता सके कि ईमेल कहाँ गया।
हमारे दिए SPF और DKIM रिकॉर्ड प्रकाशित करें और DMARC नीति जोड़ें। हर रिकॉर्ड सत्यापित होने पर हरा हो जाता है।
यूज़रनेम और स्कोप्ड की बनाएँ, फिर उस ऐप के लिए सेंडिंग सीमा और वैकल्पिक IP एलाउलिस्ट सेट करें।
अपने ऐप या प्लगइन में होस्ट, पोर्ट और क्रेडेंशियल बदलें, टेस्ट संदेश भेजें और मैसेज लॉग में नतीजे की पुष्टि करें।
चरणों के बीच स्विच करके देखें कि हर पड़ाव पर आपके हाथ में क्या है। यह सिर्फ़ उदाहरण इंटरफ़ेस है। दिखाए गए सभी आँकड़े और पते नमूना डेटा हैं।
हर SMTP अकाउंट अलग है, इसलिए आप किसी एक ऐप, एनवायरनमेंट या क्लाइंट की पहुँच को बाकी कुछ छुए बिना रोटेट, सीमित या बंद कर सकते हैं।
SMTP रिले एक मेल सर्वर है जो मानक SMTP प्रोटोकॉल पर आपके एप्लिकेशन से संदेश स्वीकार करता है और आपकी ओर से उन्हें प्राप्तकर्ताओं के मेलबॉक्स प्रोवाइडर तक पहुँचाता है। आपका ऐप प्रमाणित होता है, संदेश सौंपता है और आगे बढ़ जाता है। MigoSMTP यह रिले MigoMTA पर चलाता है, इसलिए क्यूइंग, रीट्राई, ऑथेंटिकेशन साइनिंग और प्रोवाइडर-विशिष्ट थ्रॉटलिंग हम संभालते हैं, आपको अपना मेल सर्वर चलाना और ट्यून करना नहीं पड़ता। आपका मौजूदा कोड और लाइब्रेरी वैसी ही रहती हैं, बस होस्ट, पोर्ट और क्रेडेंशियल बदलने होते हैं।
SMTP बोल सकने वाला कुछ भी इस रिले का उपयोग कर सकता है: वेब फ्रेमवर्क, CMS प्लगइन, टिकटिंग और बिलिंग टूल, स्क्रिप्ट, प्रिंटर और स्कैनर। हर ऐप, एनवायरनमेंट या क्लाइंट को अपना SMTP अकाउंट मिलता है, जिसके क्रेडेंशियल, सेंडिंग लिमिट और वैकल्पिक IP allowlist अलग होते हैं, इसलिए बाकी को छुए बिना आप किसी एक को रोटेट या बंद कर सकते हैं। हर कनेक्शन पर TLS अनिवार्य है। हर अकाउंट की सीमा किसी गड़बड़ ऐप को आपका पूरा कोटा खत्म करने से रोकती है, और उपयोग रिपोर्ट बताती हैं कि किस अकाउंट ने क्या भेजा।
रिले डिलीवरेबिलिटी के लिए मायने रखता है, क्योंकि मेलबॉक्स प्रोवाइडर कंटेंट जितना ही भेजने वाले इन्फ्रास्ट्रक्चर को भी परखते हैं। मैनेज्ड रिले आपके डोमेन की DKIM की से मेल पर हस्ताक्षर करता है, एक जैसा ऑथेंटिकेशन लागू करता है, प्रोवाइडर के डिफर करने पर गति घटाता है, अस्थायी विफलताओं को दोबारा आज़माता है और बाउंस या शिकायत करने वाले पते सप्रेस कर देता है। कुछ गड़बड़ होने पर मैसेज लॉग में कच्चे SMTP रिस्पॉन्स दिखते हैं और हमारा AI असिस्टेंट उन्हें सरल भाषा में समझाता है, ताकि आपकी टीम और सपोर्ट डेस्क देख सकें कि क्या हुआ और क्या बदलना है।
अविश्वसनीय सर्वर मेल की जगह WordPress के लिए SMTP रिले लगाएँ। अपने SMTP प्लगइन में होस्ट और क्रेडेंशियल डालें, और ऑर्डर कन्फर्मेशन व पासवर्ड रीसेट स्पैम में जाना बंद हो जाते हैं।
एजेंसियाँ हर क्लाइंट साइट के लिए अलग SMTP अकाउंट बना सकती हैं, हर एक की अपनी सीमाओं के साथ, ताकि किसी एक साइट का कॉम्प्रोमाइज़ हुआ प्लगइन साझा कोटा खत्म न कर सके और किसी दूसरे क्लाइंट को नुकसान न पहुँचा सके।
Laravel, Django, Rails, Node और CodeIgniter ऐप में SMTP सेटिंग पहले से होती है। मेल कॉन्फ़िगरेशन को रिले की ओर मोड़ें और अपने मौजूदा मेलर, टेम्पलेट और क्यू जस के तस रखें।
प्रिंटर, स्कैनर और पुराने लाइन-ऑफ-बिज़नेस सॉफ़्टवेयर अक्सर सिर्फ़ SMTP सपोर्ट करते हैं। रिले उन्हें बिना फ़र्मवेयर बदले और बिना री-राइट के प्रमाणित, एन्क्रिप्टेड सेंडिंग देता है।
अपना ईमेल खुद भेजने वाले टिकटिंग, CRM और इनवॉइसिंग सॉफ़्टवेयर जोड़ें, ताकि ग्राहकों को जवाब और रसीदें साझा सर्वर की जगह आपके प्रमाणित डोमेन से जाएँ।
स्टेजिंग और प्रोडक्शन के लिए अलग सीमाओं और allowlist वाले अलग अकाउंट रखें, ताकि टेस्ट ट्रैफ़िक कभी लाइव प्रतिष्ठा या ग्राहक डेटा से न मिले और दोनों का ऑडिट आसान रहे।
दोनों एक ही इन्फ्रास्ट्रक्चर से डिलीवर करते हैं। जिस सॉफ़्टवेयर को जोड़ रहे हैं, उसके हिसाब से चुनें।
आप दोनों इस्तेमाल कर सकते हैं। कई टीमें पुराने टूल के लिए SMTP रखती हैं और नई सेवाओं के लिए API चलाती हैं, एक ही वर्कस्पेस और एक ही रिपोर्ट के तहत।
AI कोपायलट कच्चे SMTP रिस्पॉन्स और लॉग पढ़ता है, फिर सरल भाषा में बताता है कि संदेश क्यों डिफर या बाउंस हुआ और सुधार सुझाता है। कार्रवाई करनी है या नहीं, यह आप तय करते हैं।
मॉडल हर अकाउंट का सामान्य सेंडिंग पैटर्न सीखते हैं और अचानक उछाल या गिरावट को फ़्लैग करते हैं, जैसे अनियंत्रित लूप या कॉम्प्रोमाइज़ हुआ क्रेडेंशियल। अकाउंट को रोकना है या सिर्फ़ सूचना पाना है, यह आप चुनते हैं।
रिस्क स्कोरिंग असामान्य व्यवहार या नए सोर्स IP वाले अकाउंट को उजागर करती है और पासवर्ड रोटेट करने या allowlist कसने की सलाह देती है। आपकी मंज़ूरी तक कुछ नहीं बदलता।
अपने पुराने प्रोवाइडर की सेटिंग पेस्ट करें, और असिस्टेंट स्विच के लिए ज़रूरी होस्ट, ऑथेंटिकेशन और DNS बदलावों का ड्राफ़्ट बनाता है। किसी भी ट्रैफ़िक के जाने से पहले एक व्यक्ति चेकलिस्ट की समीक्षा करता है।
AI फ़ीचर सहायक हैं: वे समझाते और सुझाव देते हैं, और अकाउंट, सीमाओं या रूटिंग में कोई भी बदलाव आपकी टीम मंज़ूर करती है।
अलग क्रेडेंशियल से आप बाकी को बाधित किए बिना किसी एक एप्लिकेशन को रोटेट, सीमित या बंद कर सकते हैं, और उपयोग रिपोर्ट में श्रेय तय करना आसान हो जाता है।
असली ट्रैफ़िक भेजने से पहले SPF, DKIM और DMARC पॉलिसी प्रकाशित करें। बिना ऑथेंटिकेशन वाला मेल शुरुआत में स्पैम में जाने का सबसे आम कारण है।
उचित सीमा लूप और लीक हुए क्रेडेंशियल से होने वाला नुकसान सीमित रखती है। अपनी असली वॉल्यूम के पास से शुरू करें और बढ़ने पर सोच-समझकर बढ़ाएँ।
अगर आपका ऐप तय IP से भेजता है, तो अकाउंट को उन्हीं तक सीमित करें। तब चुराया हुआ पासवर्ड कहीं और से बेकार रहता है।
यूज़रनेम और की को एनवायरनमेंट वेरिएबल या सीक्रेट मैनेजर में रखें, कभी रिपॉज़िटरी या फ्रंट-एंड बंडल में नहीं, और उन्हें तय समय पर रोटेट करें।
एक टेस्ट संदेश भेजें, फिर मैसेज लॉग और हेडर पढ़ें। लाइव ट्रैफ़िक ले जाने से पहले TLS, From पता, DKIM और अंतिम स्टेटस की पुष्टि करें।
किसी सेटिंग को लेकर अनिश्चित हैं? कटओवर से पहले हमारी टीम आपके सेटअप की समीक्षा कर सकती है।
SMTP रिले आपके एप्लिकेशन से ईमेल स्वीकार करता है और उसे प्राप्तकर्ता के मेल सर्वर तक आगे भेजता है। आपका ऐप TLS पर क्रेडेंशियल से प्रमाणित होकर संदेश सौंपता है। फिर रिले क्यूइंग, रीट्राई, साइनिंग और प्रोवाइडर थ्रॉटलिंग संभालता है, इसलिए आपको अपना मेल सर्वर नहीं चलाना पड़ता।
अपना सेंडिंग डोमेन वेरिफ़ाई करें, डैशबोर्ड में SMTP अकाउंट बनाएँ और अपने ऐप या प्लगइन में होस्ट, पोर्ट और क्रेडेंशियल डालें। एक टेस्ट संदेश भेजें और लॉग जाँचें। WordPress के लिए यही सेटिंग अपने SMTP प्लगइन में जोड़ें।
SMTP मानक प्रोटोकॉल से मौजूदा सॉफ़्टवेयर को बिना कोड बदले भेजने देता है। ईमेल API एक REST इंटरफ़ेस है जो नए कोड के लिए उपयुक्त है और टेम्पलेट, idempotency और समृद्ध रिस्पॉन्स देता है। दोनों एक ही इन्फ्रास्ट्रक्चर से डिलीवर करते हैं, इसलिए जहाँ जो ठीक बैठे, वहाँ उसे इस्तेमाल करें।
हाँ। अपने प्लान की अनुमति जितने चाहें अकाउंट बनाएँ, हर एक के अपने क्रेडेंशियल, सेंडिंग लिमिट और वैकल्पिक IP allowlist के साथ। इससे ऐप, एनवायरनमेंट और क्लाइंट अलग रहते हैं और आप बाकी को प्रभावित किए बिना किसी एक को बंद कर सकते हैं।
बाउंस और शिकायतें आपके मैसेज लॉग में दर्ज होती हैं। हार्ड बाउंस और शिकायतें आपकी सप्रेशन लिस्ट में जुड़ जाती हैं ताकि आप उन्हें भेजना बंद कर दें, और अस्थायी विफलताओं को विफल मानने से पहले रीट्राई किया जाता है।
हाँ, और हम असली ट्रैफ़िक भेजने से पहले ऐसा करने की सलाह देते हैं। इनबॉक्स तक पहुँचने के लिए डोमेन प्रमाणित करना सबसे अहम कदम है। डैशबोर्ड बताता है कि कौन-से रिकॉर्ड प्रकाशित करने हैं और हर एक के वेरिफ़ाई होने पर उसे चिह्नित करता है।
आम तौर पर हाँ, अगर डिवाइस ऑथेंटिकेशन और TLS सपोर्ट करता है। उसके लिए कम सेंडिंग लिमिट और IP allowlist वाला अलग अकाउंट बनाएँ। अगर डिवाइस TLS इस्तेमाल नहीं कर सकता, तो उसे जोड़ने से पहले विकल्पों के बारे में हमसे बात करें।
नहीं। असिस्टेंट बाउंस समझाता है, असामान्य वॉल्यूम फ़्लैग करता है और सुधार सुझाता है, लेकिन क्रेडेंशियल, सीमाओं या रूटिंग में कोई भी बदलाव आपकी टीम मंज़ूर करती है। आप उसका तर्क संबंधित लॉग के साथ देख सकते हैं।
खाता बनाएँ, अपना डोमेन जोड़ें और पहला ईमेल भेजें।