Geben Sie jedem Kunden, jeder Marke oder Umgebung eigene Keys, Domains und Berichte, ohne eigene Mailserver zu betreiben.
Mandantenfähige E-Mail für SaaS mit Agent-fähiger API und KI-Support-Triage
Ein Mandant versendet Spam und betrifft alle
Limits und Suppression je Workspace verhindern, dass ein einzelner Absender den Rest beeinträchtigt.
Kunden wollen ihre eigene Versanddomain
Domain-Onboarding und Verifizierung laufen über die API.
E-Mail-Änderungen erscheinen mit jedem Release
Versionierte Templates lassen Produkt und Support Inhalte sicher aktualisieren.
Mandantenfähige E-Mail funktioniert, wenn jeder Kunde eine eigene Einheit mit eigenen Keys, eigener Domain und eigenen Limits ist, alles von Ihrem Produkt verwaltet.
E-Mail für SaaS umfasst die Nachrichten, die ein Softwareprodukt im Namen seiner eigenen Nutzer versendet: Workspace-Einladungen, Nutzungsalarme, Digests, Abrechnungshinweise und, in vielen Produkten, Mails unter der Marke des Kunden. Sie ist anspruchsvoller als gewöhnliche App-E-Mail, weil viele Mandanten eine Versandplattform teilen. Das Design muss daher deren Limits, Domains, Keys und Reputation trennen und die Integration für Entwickler dennoch einfach halten. Gutes Design verhindert, dass sich Mandanten gegenseitig beeinflussen.
Frühe SaaS-Teams senden alles von einem Konto und einer Domain. Mit den ersten Kunden häufen sich die Probleme: Die schlechte Liste eines Mandanten schadet der Zustellung aller, Kunden möchten von ihrer eigenen Domain senden, Produkt und Support wollen Templates ohne Release bearbeiten, und niemand kann beantworten, warum ein Nutzer eine Einladung nicht erhalten hat. Mandantenkontrollen selbst zu bauen, kostet Entwicklungszeit, die dem Produkt fehlt. Der Support steht derweil ohne Antwort da.
MigoSMTP, entwickelt auf MigoMTA, bietet Workspaces mit getrennten Keys, Limits und Berichten, Domain-Onboarding über die API, versionierte Templates und Webhooks, die den Zustellstatus in Ihr Produkt zurückspielen. Eine Agent-fähige API und ein Support-Copilot helfen Ihrem Team, die Frage „Warum ist das nicht angekommen?“ schneller zu beantworten und Mandanten mit ungewöhnlichen Bounce-Mustern zu markieren. Menschen genehmigen jede Sperrung und jede Konfigurationsänderung. Berichte schlüsseln die Ergebnisse je Workspace auf.
Senden Sie Einladungen, die ein Teamkollege auslöst, und geben Sie Zustell-Events an Ihre App zurück, damit der Einladende sieht, ob die Nachricht gebounct ist, und die Adresse korrigieren kann.
Benachrichtigen Sie Admins, wenn ein Schwellenwert überschritten wird, mit Prioritätsversand, damit Alarme nicht hinter Digests in der Queue hängen, und halten Sie die Zustellung für Ihren Audit-Trail fest. Alarme bleiben prüfbar.
Senden Sie wöchentliche Übersichten je Workspace und Nutzer, gedrosselt, damit der Digest eines großen Mandanten keine Kapazität verbraucht, die kleinere Mandanten im selben Moment brauchen.
Lassen Sie Kunden ihre eigene Domain über einen Onboarding-Ablauf verifizieren und unter ihrer Marke senden, mit SPF- und DKIM-Prüfungen vor der ersten Nutzung. Nicht verifizierte Domains bleiben gesperrt.
Lassen Sie Mandanten von ihrer eigenen verifizierten Domain senden, während Sie die Kontrolle über Limits und Suppression behalten.
Warnen Sie Kunden, wenn sie Plan-Limits erreichen, und bestätigen Sie Zahlungen, alles aus Templates, die Sie versionieren können.
Anfangs ist ein Konto einfach. Wachsen die Mandanten, schützt Trennung alle.
Starten Sie ab dem ersten Mandanten mit Workspaces. Eine spätere Migration ist weit schwieriger als ein getrennter Start.
Geben Sie die E-Mail-Adresse eines Nutzers ein und fragen Sie, warum eine Einladung nicht ankam. Der Copilot liest das Nachrichten-Log und fasst den Zustellweg zusammen. Ohne Freigabe durch Mitarbeitende kann er nichts erneut senden oder ändern.
Erkennen Sie Workspaces, deren Bounce- oder Beschwerdemuster vom Normalen abweichen, und legen Sie sie zur Prüfung vor. Ihr Team entscheidet, ob der Mandant verwarnt, gedrosselt oder in Ruhe gelassen wird.
Eine MCP-kompatible Schnittstelle lässt freigegebene interne Agents mit eingeschränkten Keys Workspaces bereitstellen oder den Domainstatus prüfen. Aktionen mit großer Wirkung können einen menschlichen Freigabeschritt verlangen. Jeder Aufruf wird protokolliert.
Entwerfen Sie übersetzte oder umformulierte Versionen von Produkt-E-Mails zur Prüfung. Produktverantwortliche bearbeiten und genehmigen jede Version, bevor sie in einem versionierten Template live geht.
KI-Funktionen sind unterstützend und beratend: Ihre Engineering- und Support-Teams prüfen Vorschläge und behalten die Kontrolle über Entscheidungen zu Mandanten, Templates und Versand.
Trennen Sie Keys, Limits und Berichte je Kunde, damit ein lauter Absender andere nicht schädigt und Sie die Nutzung klar sehen.
Senden Sie nie als Kundendomain, bevor SPF und DKIM bestehen. Blockieren Sie nicht verifizierte Domains in der API, um die gemeinsame Reputation zu schützen.
Halten Sie Produkt-E-Mails in versionierten Templates, damit Support und Produkt Texte sicher aktualisieren und bei Problemen zurückrollen können.
Zeigen Sie per Webhooks zugestellt, gebounct oder zurückgestellt direkt neben der Aktion an, was Support-Tickets zu fehlenden E-Mails senkt.
Wenden Sie Standard-Versandlimits an und erhöhen Sie sie auf Anfrage, damit ein kompromittiertes Konto kein großes Volumen senden kann, bevor es jemand bemerkt.
Sie entwerfen Ihr Mandantenmodell? Unser Team prüft es gern mit Ihnen.
Nutzen Sie eine E-Mail-API mit einem Workspace oder Unterkonto je Mandant, jeweils mit eigenen Keys, Limits und Berichten. Authentifizieren Sie Versanddomains, leiten Sie Events über Webhooks zurück und wenden Sie Suppression je Mandant an, damit fehlerhafte Daten eines Kunden andere nicht betreffen.
Ja, mit einem Domain-Onboarding-Ablauf: Der Kunde ergänzt DNS-Einträge, Sie verifizieren SPF und DKIM, und erst dann aktivieren Sie den Versand. Die API kann das automatisieren, sodass Ihr Produkt jeden Kunden ohne manuellen Support durch die Einrichtung führt.
Isolieren Sie Mandanten mit getrennten Workspaces, wenden Sie Versandlimits an, unterdrücken Sie Bounces und Beschwerden automatisch und überwachen Sie die Raten jedes Mandanten. Verlagern Sie Mandanten mit hohem Risiko oder Volumen in einen eigenen IP-Pool, wenn ihr Verhalten andere zu beeinträchtigen beginnt. Prüfen Sie Limits, während jeder Mandant wächst.
Speichern Sie Templates außerhalb des Anwendungscodes mit Versionen, Variablen und einem Prüfschritt. So können Produkt und Support Inhalte ohne Deployment bearbeiten, während Engineers die Kontrolle über die übergebenen Daten behalten und eine fehlerhafte Änderung zurückrollen können. Taggen Sie jedes Release, damit Änderungen nachvollziehbar sind.
Abonnieren Sie Webhook-Events und speichern Sie die Status zugestellt, gebounct und zurückgestellt am zugehörigen Datensatz in Ihrer Datenbank. Ihre Oberfläche kann dann ein Status-Badge oder eine Aufforderung zum erneuten Senden anzeigen, ohne je ein Postfach zu lesen. Das senkt auch wiederkehrende Support-Tickets spürbar.
Die meisten SaaS-Teams nutzen für Anwendungsversand die HTTP-API, da sie Metadaten, Idempotenz und aussagekräftigere Fehler unterstützt. SMTP eignet sich für Altsysteme, Plugins und Drittanbieter-Tools. Beides kann im selben Workspace laufen. Viele Teams betreiben beides gleichzeitig ohne Konflikte.
Ja, über eine MCP-kompatible Schnittstelle mit eingeschränkten Keys. Sie entscheiden, welche Aktionen Agents ausführen dürfen, etwa schreibgeschützte Statusabfragen gegenüber dem Entwerfen von Sendungen, und können für Sensibles eine menschliche Freigabe verlangen.
Ein Copilot kann das Nachrichten-Log eines Nutzers lesen und den Zustellweg in verständlicher Sprache erklären, etwa einen Bounce-Grund oder eine Zurückstellung. Mitarbeitende prüfen die Zusammenfassung und entscheiden über Folgemaßnahmen.
Schildern Sie uns Ihr Volumen und Ihr Setup, dann führen wir Sie durch die passende Konfiguration.
Konto erstellen, Domain hinzufügen und die erste E-Mail senden.