امنح كل عميل أو علامة أو بيئة مفاتيحه ونطاقاته وتقاريره الخاصة، دون تشغيل خوادم بريد بنفسك.
بريد متعدد المستأجرين لتطبيقات SaaS مع API جاهزة للوكلاء وفرز الدعم بالذكاء الاصطناعي
مستأجر واحد يرسل بريدًا مزعجًا فيؤثر في الجميع
تمنع الحدود والحظر لكل مساحة عمل مرسلًا واحدًا من الإضرار بالبقية.
يريد العملاء نطاق إرسال خاصًا بهم
تعمل تدفقات تهيئة النطاقات والتحقق منها عبر API.
تغييرات البريد تصدر مع كل إصدار
تتيح القوالب ذات الإصدارات للمنتج والدعم تحديث المحتوى بأمان.
ينجح البريد متعدد المستأجرين عندما يكون كل عميل وحدة مستقلة بمفاتيحه ونطاقه وحدوده، وكلها يديرها منتجك.
بريد SaaS هو مجموعة الرسائل التي يرسلها منتج برمجي نيابةً عن مستخدميه: دعوات مساحات العمل، وتنبيهات الاستخدام، والملخصات، وإشعارات الفوترة، وفي منتجات كثيرة رسائل تُرسل بعلامة العميل نفسه. وهو أصعب من بريد التطبيقات العادي لأن مستأجرين كثرًا يتشاركون منصة إرسال واحدة، فيجب أن يفصل التصميم بين حدودهم ونطاقاتهم ومفاتيحهم وسمعتهم مع إبقاء التكامل بسيطًا للمطورين. والتصميم الجيد يمنع المستأجرين من التأثير في بعضهم.
ترسل فرق SaaS الناشئة كل شيء من حساب واحد ونطاق واحد. ومع قدوم العملاء تتراكم المشكلات: قائمة سيئة لمستأجر واحد تضر بالتسليم للجميع، ويطلب العملاء الإرسال من نطاقهم، ويريد المنتج والدعم تعديل القوالب دون إصدار جديد، ولا أحد يستطيع الإجابة عن سبب عدم استلام مستخدم معين لدعوة. وبناء ضوابط المستأجرين داخليًا يسحب وقت الهندسة من المنتج نفسه. وفي الأثناء لا يملك الدعم جوابًا.
يوفّر MigoSMTP، المبني على MigoMTA، مساحات عمل بمفاتيح وحدود وتقارير منفصلة، وتهيئة النطاقات عبر API، وقوالب بإصدارات، وwebhooks تعيد حالة التسليم إلى منتجك. وتساعد واجهة API الجاهزة للوكلاء ومساعد الدعم فريقك على الإجابة عن سؤال لماذا لم تصل الرسالة بسرعة أكبر، ورصد المستأجرين ذوي أنماط الارتداد غير المعتادة. ويعتمد الأشخاص أي إيقاف أو تغيير في الإعدادات. وتفصّل التقارير النتائج لكل مساحة عمل.
أرسل الدعوات التي يطلقها أحد الزملاء، مع إعادة أحداث التسليم إلى تطبيقك ليرى المُدعي هل ارتدّت الرسالة ويصحح العنوان.
أبلغ المسؤولين عند تجاوز عتبة ما، مستخدمًا الإرسال ذا الأولوية حتى لا تنتظر التنبيهات خلف الملخصات، وسجّل التسليم في مسار التدقيق. وتبقى التنبيهات قابلة للتدقيق.
شغّل الملخصات الأسبوعية لكل مساحة عمل ومستخدم، مع تحديد الوتيرة حتى لا يستهلك ملخص مستأجر كبير سعة تحتاجها المستأجرون الأصغر في اللحظة نفسها.
دع العملاء يوثّقون نطاقهم عبر تدفق تهيئة ويرسلون بعلامتهم، مع إكمال فحوصات SPF وDKIM قبل أول استخدام. وتبقى النطاقات غير الموثّقة محظورة.
دع المستأجرين يرسلون من نطاقهم الموثّق بينما تحتفظ أنت بالتحكم في الحدود والحظر.
حذّر العملاء عند اقترابهم من حدود الخطة وأكّد المدفوعات، كلها من قوالب يمكنك إدارة إصداراتها.
في البداية يكفي حساب واحد. ومع نمو المستأجرين يحمي الفصل الجميع.
ابدأ بمساحات العمل منذ المستأجر الأول. فالترحيل لاحقًا أصعب بكثير من البدء بالفصل.
أدخل بريد مستخدم واسأل لماذا لم تصل دعوة. يقرأ المساعد سجل الرسائل ويلخّص مسار التسليم. ولا يمكنه إعادة الإرسال أو تعديل أي شيء دون موافقة الموظفين.
رصد مساحات العمل التي ينحرف نمط الارتداد أو الشكاوى فيها عن المعتاد وإظهارها للمراجعة. ويقرر فريقك هل يحذّر المستأجر أو يقيّده أو يتركه.
تتيح واجهة متوافقة مع MCP للوكلاء الداخليين المعتمدين إنشاء مساحات العمل أو التحقق من حالة النطاق باستخدام مفاتيح محدودة النطاق. ويمكن اشتراط خطوة موافقة بشرية للإجراءات عالية الأثر. ويُسجَّل كل استدعاء.
صياغة نسخ مترجمة أو معاد صياغتها من رسائل المنتج للمراجعة. ويحرر مالكو المنتج كل نسخة ويعتمدونها قبل نشرها في قالب ذي إصدارات.
ميزات الذكاء الاصطناعي مساعِدة واستشارية، ولذلك تراجع فرق الهندسة والدعم لديك الاقتراحات وتحتفظ بالتحكم في قرارات المستأجرين والقوالب والإرسال.
افصل المفاتيح والحدود والتقارير لكل عميل حتى لا يضر مرسل مزعج واحد بالآخرين، وليتضح لك الاستخدام.
لا ترسل أبدًا باسم نطاق عميل قبل اجتياز SPF وDKIM. وامنع النطاقات غير الموثّقة عند API لحماية السمعة المشتركة.
احتفظ برسائل المنتج في قوالب ذات إصدارات ليتمكن الدعم والمنتج من تحديث النص بأمان والتراجع إذا تسبب تغيير في مشكلات.
استخدم webhooks لعرض حالة التسليم أو الارتداد أو التأجيل بجانب الإجراء، مما يقلّل طلبات الدعم عن البريد المفقود.
طبّق سقوف إرسال افتراضية وارفعها عند الطلب، حتى لا يستطيع حساب مخترق إرسال حجم كبير قبل أن يلاحظ أحد.
تصمّم نموذج المستأجرين لديك؟ يسعد فريقنا بمراجعته معك.
استخدم API للبريد مع مساحة عمل أو حساب فرعي لكل مستأجر، لكل منها مفاتيحه وحدوده وتقاريره. ووثّق نطاقات الإرسال، ووجّه الأحداث عبر webhooks، وطبّق الحظر لكل مستأجر حتى لا تؤثر بيانات عميل سيئة في غيره.
نعم، عبر تدفق تهيئة النطاق: يضيف العميل سجلات DNS، وتتحقق أنت من SPF وDKIM، ثم تفعّل الإرسال. ويمكن لـ API أتمتة ذلك، فيرشد منتجك كل عميل خلال الإعداد دون دعم يدوي.
اعزل المستأجرين بمساحات عمل منفصلة، وطبّق حدود الإرسال، واحظر الارتدادات والشكاوى تلقائيًا، وراقب معدلات كل مستأجر. وانقل المستأجرين عالي الخطورة أو الحجم إلى مجموعة IP خاصة بهم إذا بدأ سلوكهم يؤثر في غيرهم. وراجع الحدود مع نمو كل مستأجر.
خزّن القوالب خارج كود التطبيق مع الإصدارات والمتغيرات وخطوة مراجعة. فيتمكن المنتج والدعم من تحرير المحتوى دون نشر، ويحتفظ المهندسون بالتحكم في البيانات الممرَّرة ويمكنهم التراجع عن تغيير سيئ. ضع وسمًا لكل إصدار لتكون التغييرات قابلة للتتبع.
اشترك في أحداث webhook وخزّن حالات التسليم والارتداد والتأجيل مقابل السجل المرتبط في قاعدة بياناتك. فتعرض واجهتك شارة حالة أو دعوة لإعادة الإرسال دون قراءة أي صندوق بريد. ويقلّل هذا أيضًا تذاكر الدعم المتكررة بشكل ملحوظ.
يستخدم معظم فرق SaaS واجهة HTTP API لإرسال التطبيق لأنها تدعم البيانات الوصفية وidempotency وأخطاء أغنى. ويفيد SMTP مع الأنظمة القديمة والإضافات وأدوات الأطراف الثالثة. ويمكن تشغيل الاثنين في مساحة العمل نفسها. وتشغّلهما فرق كثيرة معًا دون تعارض.
نعم، عبر واجهة متوافقة مع MCP باستخدام مفاتيح محدودة النطاق. وأنت تقرر الإجراءات المسموحة للوكلاء، كفحص الحالة للقراءة فقط مقابل صياغة الرسائل، ويمكنك اشتراط موافقة بشرية لكل ما هو حساس.
يمكن للمساعد قراءة سجل الرسائل لمستخدم وشرح مسار التسليم بلغة واضحة، مثل سبب الارتداد أو التأجيل. ويراجع الموظفون الملخص ويقررون أي متابعة.
أخبرنا بحجم إرسالك وإعداداتك وسنرشدك إلى التهيئة المناسبة.
أنشئ حساباً، وأضف نطاقك، وأرسل أول رسالة بريد إلكتروني.