Ein oder mehrere E-Mail-Anbieter für SaaS?

Sollte ein SaaS-Unternehmen für Transaktions- und Marketing-E-Mails einen oder mehrere Anbieter nutzen?

Trifft eine E-Mail zum Zurücksetzen des Passworts verspätet ein, kann ein Kunde ausgesperrt werden. Ein verzögerter Produktnewsletter ist meist weniger dringend, kann aber trotzdem für Verwirrung sorgen oder dazu führen, dass Kunden nicht erreicht werden. Aufgrund dieser unterschiedlichen Folgen ist die E-Mail-Architektur eine praktische Entscheidung und nicht nur eine Frage der Anbieterwahl.

Teams, die sich fragen, ob ein SaaS-Unternehmen für Transaktions- und Marketing-E-Mails einen oder mehrere Anbieter nutzen sollte, sollten vergleichen, wie die jeweiligen Lösungen im normalen Betrieb und bei einem Ausfall funktionieren. Die richtige Wahl hängt davon ab, wie wichtig die Trennung für das Unternehmen ist, wie viel Zeit für die Entwicklung zur Verfügung steht und welche Funktionen die ausgewählten Anbieter tatsächlich unterstützen. Bevor Sie sich festlegen, sollten Sie ein oder mehrere E-Mail-Anbieter für SaaS anhand dieser Anforderungen bewerten.

Entscheidungskriterien festlegen

Vergleichen Sie zunächst sechs Faktoren: betriebliche Komplexität, Kontrolle über die Versand-Reputation, Ausfallisolierung, Berichte, Supportaufwand und den Aufwand für die Pflege der Integrationen. Diese Kriterien zeigen, was die Architektur vom Team verlangt, sobald die Einrichtung abgeschlossen ist.

• Betriebliche Komplexität: Wie viele Konten, Zugangsdaten, Integrationen und Konfigurationsänderungen muss das Team verwalten?
• Kontrolle über die Versand-Reputation: Kann das Team die beiden Versandströme unabhängig voneinander verwalten, und welche Kontrollmöglichkeiten bietet jeder Anbieter?
• Ausfallisolierung: Könnten sich eine Konfigurationsänderung, eine Kontobeschränkung oder ein Dienstausfall auf beide Versandströme auswirken?
• Berichte: Kann das Team Zustellereignisse und Fehler für jeden Versandstrom klar nachvollziehen?
• Supportaufwand: Wie viele Supportkanäle und Anbieterbeziehungen müssen die Entwickler koordinieren?
• Integrationsaufwand: Wie viel Code und Tests sind erforderlich, damit jede Verbindung zuverlässig funktioniert?

Beschränken Sie den Vergleich auf die Infrastruktur. Rechtliche Einstufung und Zielgruppensegmentierung sind separate Fragen. Werden sie in die Entscheidung über den Anbieter einbezogen, kann das verschleiern, ob das Kernsystem überhaupt gut zu verwalten ist.

Ein Anbieter: einfacherer Betrieb, gemeinsame Abhängigkeiten

Ein einzelner Anbieter kann eine Integration, eine Anbieterbeziehung und einen zentralen Ort für die Prüfung von Zustellungsprotokollen bedeuten. Für ein kleines Team kann das den Einrichtungsaufwand verringern: Entwickler müssen möglicherweise nur einen Satz Zugangsdaten und eine dokumentierte Verbindung pflegen statt zwei.

Auch die Fehlersuche im Alltag kann durch gebündelte Tools einfacher werden. Schlägt beispielsweise eine Kontobestätigung fehl, kann das Team zuerst das Dashboard des Anbieters prüfen und anschließend die Anwendungsprotokolle. Welche Berichte, Kontostrukturen und Trennungsmöglichkeiten ein Anbieter bereitstellt, ist unterschiedlich. Prüfen Sie daher die Einzelheiten, bevor Sie sich darauf verlassen.

Der Nachteil ist die gemeinsame Abhängigkeit. Eine Änderung der Kontoeinstellungen, ein Problem mit Zugangsdaten oder ein kontobezogener Vorfall könnte je nach Architektur und Richtlinien des Anbieters sowohl den Versand von Transaktions- als auch von Marketing-E-Mails beeinträchtigen.

Auch ohne vollständigen Ausfall kann eine gemeinsame Einrichtung die Fehlersuche erschweren, wenn die beiden Versandströme nicht klar gekennzeichnet sind. So könnten etwa plötzlich vermehrte fehlgeschlagene Marketing-E-Mails in derselben Berichtsansicht neben Ereignissen zum Zurücksetzen von Passwörtern erscheinen. Separate Zugangsdaten, klar benannte Versandströme und übersichtliche Dashboards können helfen – sofern der Anbieter diese Möglichkeiten unterstützt.

Ein Anbieter bedeutet nicht, dass alles über einen einheitlichen Versandprozess läuft. Wenn die entsprechenden Kontrollmöglichkeiten vorhanden sind, kann ein Team weiterhin getrennte Vorlagen, API-Zugangsdaten, Überwachungsregeln und interne Verantwortliche festlegen. Entscheidend ist, ob der Anbieter die für das Team erforderliche Trennung ermöglicht.

Mehrere Anbieter: bessere Isolierung, mehr Aufwand

Mit mehreren Anbietern lassen sich die Versandsysteme trennen und jedem Versandstrom ein eigenes Konto, eigene Zugangsdaten, Dashboards und Betriebsverantwortliche zuweisen. Bei einem Dienstausfall eines Anbieters könnte der andere weiterhin verfügbar sein. Das sollte jedoch getestet und nicht als garantiert angenommen werden: Die Anwendung, DNS-Einstellungen oder gemeinsam genutzte Infrastruktur können weiterhin Abhängigkeiten schaffen.

Die zusätzliche Trennung bedeutet auch mehr Arbeit. Entwickler müssen zwei Systeme integrieren und testen, zwei Gruppen von Ereignissen überwachen, Zugangsdaten aktuell halten und dokumentieren, wie die einzelnen Versandströme gepflegt werden. Auch die Finanz- oder Betriebsabteilung hat möglicherweise mit zwei Abrechnungsbeziehungen und zwei Supportprozessen zu tun.

Manche Teams entscheiden sich für getrennte Anbieter, um die Versand-Reputation besser kontrollieren zu können. Das kann dabei helfen, bestimmte Risiken zu isolieren, aber ein zweiter Anbieter verbessert die Zustellbarkeit nicht automatisch. Die Ergebnisse hängen von den Funktionen der Anbieter, der Konfiguration, den Versandpraktiken und dem Umgang des Unternehmens mit den Nachrichten ab. Prüfen Sie daher, ob der erwartete Vorteil tatsächlich eintritt.

Auch bei der Reaktion auf Vorfälle muss klar sein, wer verantwortlich ist. Schlägt eine Transaktions-E-Mail fehl, muss der diensthabende Entwickler wissen, welches System zu prüfen ist und welcher Ausweichweg sicher ist. Sind die Zuständigkeiten zwischen Produkt- und Marketingteam aufgeteilt, kann ein kurzes Betriebshandbuch verhindern, dass eine Supportanfrage beim Anbieter unbeantwortet bleibt, während Kunden warten.

Teams, die Zustellungsereignisse über Rückrufe untersuchen, sollten prüfen, welche Informationen die Anbieter melden und wie diese Ereignisse in die Anwendung gelangen. Der Leitfaden von YourTrend zu E-Mail-Webhooks für Transaktions-E-Mails kann als Grundlage für diese Prüfung dienen. Die Unterstützung und Einschränkungen der jeweiligen Anbieter müssen dennoch direkt bestätigt werden.

Architekturen direkt vergleichen

Die Tabelle ist ein Ausgangspunkt, keine Anbieter-Bewertung. Wenn Sie E-Mail-Anbieter für SaaS vergleichen, fragen Sie vor der Entscheidung für eine der beiden Architekturen beim Anbieter nach, welche Kontoeinstellungen, Berichtsdetails, Exportmöglichkeiten und Verfahren für den Umgang mit Vorfällen im jeweiligen Tarif konkret verfügbar sind.

Den Vergleich auf ein schlankes SaaS-Team anwenden

Ein schlankes Team verfügt nur über begrenzte Entwicklungs- und Bereitschaftskapazitäten. Für ein solches Team bedeutet ein weiterer Anbieter mehr als eine zusätzliche Rechnung: Es gibt mehr Zugangsdaten zu schützen, Integrationen zu pflegen und ein weiteres Dashboard, mit dem sich Entwickler bei einem Vorfall auskennen müssen.

Gleichzeitig kann ein Ausfall bei einem gemeinsamen Anbieter größere Folgen haben, wenn Transaktions- und Marketing-E-Mails vom selben Konto oder Dienst abhängen. Stellen Sie sich ein konkretes Szenario vor: Kunden können keine E-Mails zum Zurücksetzen ihres Passworts erhalten, während das Anbieterkonto überprüft wird. Gibt es einen getesteten Ausweichweg oder müsste das Team auf den Anbieter warten?

Notieren Sie die Antwort, bevor Sie sich entscheiden. Wenn niemand im Team eine zweite Integration pflegen kann, können getrennte Anbieter das Betriebsrisiko erhöhen, statt es zu senken. Würde ein gemeinsamer Ausfall eine wichtige Kundenaktion verhindern und kann das Unternehmen ein alternatives System betreiben, kann sich die zusätzliche Trennung lohnen.

Gehen Sie nicht davon aus, dass ein bestimmtes Versandvolumen oder die aktuelle Wachstumsphase die Entscheidung vorgibt. Die tatsächliche Supportkapazität des Teams, die Vertragsbedingungen der Anbieter und die Toleranz des Unternehmens gegenüber Unterbrechungen sind wichtiger als eine allgemeine Faustregel zur Unternehmensgröße.

Migration und Ausfallszenarien planen

Gehen Sie diese Fragen mit jedem Anbieter durch, bevor Sie sich festlegen. Fordern Sie nach Möglichkeit Dokumentation an oder führen Sie einen praktischen Test durch. Nehmen Sie nicht an, dass eine Funktion vorhanden ist, nur weil ein anderer Anbieter sie anbietet.

• Vorlagen: Kann das Team Vorlagen in einem brauchbaren Format exportieren, und welche Bestandteile müssten neu erstellt werden? Prüfen Sie, ob Layouts, dynamische Felder und Einstellungen übernommen werden.
• Sperrlisten: Können Einträge in Sperrlisten exportiert und importiert werden, und welche Formateinschränkungen oder Grenzen gelten? Klären Sie den Ablauf vor einer Migration.
• Umleitung bei Ausfällen: Kann die Anwendung bei einem Ausfall auf andere Anbieter umschalten, und welche Nachrichten können sicher anderweitig versendet werden? Testen Sie den Ausweichweg, ohne Kundennachrichten doppelt zu senden.
• Protokolle und Ereignisse: Wie lange werden Zustellungsdaten aufbewahrt, und kann das Team sie für spätere Untersuchungen exportieren? Aufbewahrungs- und Exportmöglichkeiten unterscheiden sich je nach Anbieter.
• Anbieterwechsel: Welche Zugangsdaten, Anwendungseinstellungen und DNS-Einträge müssen geändert werden? Legen Sie vor einem Notfall fest, wer für jeden Schritt verantwortlich ist.
• Kontinuität der Nachrichten: Wie verhindert das Team beim Systemwechsel, dass Ereignisse verloren gehen oder doppelt verarbeitet werden? Testen Sie Wiederholungsversuche und den Umgang mit Duplikaten in einer kontrollierten Umgebung.

Führen Sie mit einem Entwickler und einer für die Kundenkommunikation verantwortlichen Person eine Planspielübung durch. Geben Sie ihnen ein Szenario, etwa dass ein Anbieter Anfragen ablehnt, und lassen Sie sie anhand des Betriebshandbuchs den Weg von der Erkennung bis zur Wiederherstellung durchspielen. Können sie innerhalb weniger Minuten weder das richtige Dashboard noch die zuständige Person ausfindig machen, muss der Migrationsplan genauer ausgearbeitet werden.

Prüfen Sie auch, wie die Ereignisse der Anbieter in die bestehende Überwachung eingebunden sind. Ein Dashboard mit Nachrichtenaktivitäten reicht nicht aus, wenn niemand benachrichtigt wird, sobald die Zustellung von E-Mails zum Zurücksetzen von Passwörtern fehlschlägt. Vergleichen Sie die erfassten Ereignisse, die Alarmierungsoptionen und die Aufbewahrungsfristen, bevor Sie eine der Architekturen als ausreichend überwachbar einstufen.

Fazit: Wählen Sie die einfachste Lösung, die den Anforderungen an die Isolierung gerecht wird

Beginnen Sie mit einem Anbieter, wenn ein einfacher Betrieb Priorität hat und die Kontrollmöglichkeiten des Anbieters den Anforderungen des Unternehmens entsprechen. Kennzeichnen Sie die beiden Versandströme klar, dokumentieren Sie Zugangsdaten und Zuständigkeiten und testen Sie, was passiert, wenn der gemeinsame Anbieter nicht verfügbar ist.

Entscheiden Sie sich für getrennte Anbieter, wenn getestete Anforderungen die zusätzlichen Integrations- und Supportaufgaben rechtfertigen – etwa wenn das Team unabhängige Betriebsverantwortung benötigt oder es einen dokumentierten Grund gibt, Ausfälle zu isolieren. Bestätigen Sie zuerst, welche Kontrollmöglichkeiten die jeweiligen Anbieter bieten.

Transaktions- und Marketing-E-Mails trennen allein garantiert weder eine bessere Zustellbarkeit noch mehr Ausfallsicherheit. Das Team braucht weiterhin getestete Umleitungswege, klare Alarmierungen und ein Migrationsverfahren, das für jeden Schritt eine verantwortliche Person benennt.