Was ist der Unterschied, in einem Satz?
SMTP ist das offene Protokoll, mit dem Ihre Software Mails an einen Server übergibt; eine E-Mail-API ist eine anbieterspezifische HTTPS-Schnittstelle, die dieselbe Aufgabe mit strukturierten Payloads und Event-Rückmeldungen erledigt. Ob Sie im Posteingang landen, entscheidet nicht das Übermittlungsprotokoll, sondern Authentifizierung und Domain-Reputation – und SPF, DKIM und DMARC gelten für beide Wege gleichermaßen. Entscheiden Sie also nach Integrationskriterien: Portabilität, Fehlerbehandlung, Tooling. Für alles, was passiert, nachdem Ihr Anbieter die Nachricht angenommen hat, ist E-Mail-Zustellbarkeit für Startups der passende Leitfaden.
Wie funktioniert der Versand über SMTP?
Ihre Anwendung baut eine Verbindung zum Server Ihres Anbieters auf, dem SMTP-Relay – für die Übermittlung typischerweise Port 587 mit Authentifizierung, wie in RFC 6409 festgelegt – und übergibt die fertige Nachricht. Das Transportprotokoll selbst ist RFC 5321, in seiner aktuellen Form 2008 standardisiert und schon viel länger im Einsatz. Deshalb spricht es alles: Jedes Framework, CMS, Forum, Monitoring-Tool oder jahrzehntealte Skript kann so versenden, mit nichts als Host, Port und Zugangsdaten. Das ist der unauffällige Vorteil von SMTP – eine Migration ist ein Austausch der Zugangsdaten, also heißt ein Wechsel der E-Mail-Plattform nie, den Versandcode neu zu schreiben. Außerdem passt SMTP von Natur aus zu selbst gehosteten Stacks, in denen SMTP-Unterstützung standardmäßig enthalten ist.
Wie funktioniert der Versand über eine E-Mail-API?
Ihr Code ruft den HTTPS-Endpunkt des Anbieters mit einer JSON-Payload auf – Empfänger, Inhalt oder ein Verweis auf eine Vorlage, Tags, Metadaten, oft ein Idempotenzschlüssel gegen doppelte Versände. Die Antwort kommt synchron: Erfolg mit einer Message-ID oder ein Fehler, den Ihr Code abfangen und erneut versuchen kann. Die Dokumentation von Postmark macht den Kontrast deutlich – die REST-API meldet Erfolg oder Fehler sofort, während der SMTP-Endpunkt alle Nachrichten annimmt und Fehler als Bounces protokolliert, die weiterhin über die Bounce-Webhooks abrufbar sind. Nach der Annahme melden Webhooks Bounces, Beschwerden und Öffnungen an Ihre App zurück – erst das macht automatisches Sperren möglich. SDKs der Anbieter packen all das in wenige Zeilen; im Gegenzug ist die Integration an diesen Anbieter gebunden.
SMTP vs. API: der direkte Vergleich
Die ganze Entscheidung lässt sich auf einen Tausch verdichten: SMTP bringt Portabilität, die API bringt Rückmeldungen und Tooling. So sieht das Punkt für Punkt aus.
| SMTP | E-Mail-API | |
|---|---|---|
| Was es ist | Offenes Protokoll (RFC 5321) – überall gleich | Anbieterspezifische Produktschnittstelle über HTTPS |
| Integrationsaufwand | Nahezu null, wenn die Software SMTP schon spricht: Host, Port, Zugangsdaten | Code gegen den Endpunkt oder das SDK des Anbieters |
| Portabilität | Hoch – ein Anbieterwechsel ist ein Austausch der Zugangsdaten | Gering – jeder Anbieter hat ein anderes Format; ein Wechsel heißt, die Integration neu zu schreiben |
| Fehlerverhalten | Bei der Übermittlung angenommen; manche Fehler zeigen sich erst später als asynchrone Bounces | Synchrone Fehlermeldungen, die Sie abfangen und erneut versuchen können, plus asynchrone Events |
| Event-Rückmeldungen | Nichts im Protokoll – Bounce-Webhooks des Anbieters decken auch per SMTP übermittelte Mails ab, aber Sie binden sie separat an | Webhooks melden Bounces, Beschwerden und Öffnungen an Ihre App |
| Vorlagen und Analysen | Nichts im Protokoll – Sie versenden eine fertige Nachricht | Verweise auf Vorlagen, Tags und Metadaten pro Nachricht |
| Eignung für Self-Hosting | Naheliegend – selbst gehostete Software spricht SMTP von Haus aus | Eine weitere anbieterspezifische Abhängigkeit in Ihrem Stack |
Wann ist SMTP die richtige Wahl?
- Software, die es schon spricht – ein CMS, Forum, Helpdesk oder eine Legacy-App versendet über Ihren Anbieter, mit nichts als neuen Zugangsdaten.
- Maximale Portabilität – wenn Sie den Anbieter wechseln können wollen, ohne Code anzufassen, ist SMTP die neutrale Schnittstelle.
- Selbst gehostete Stacks – SMTP-Unterstützung steckt in praktisch allem, was Sie auf Ihrer eigenen Infrastruktur betreiben würden, kein SDK nötig.
- Betriebsmails mit geringem Volumen – Cron-Warnungen und interne Benachrichtigungen rechtfertigen selten eine eigene API-Integration.
Wann ist die API die richtige Wahl?
Beim Produktversand in größerem Umfang. Wenn E-Mail fest in Ihre Anwendung eingebunden ist – Onboarding, Belege, Lifecycle-Abläufe –, rechtfertigen synchrone Fehlermeldungen, Vorlagenverweise und Event-Webhooks ihren Integrationsaufwand, und eine Sperrliste kann sich in dem Moment selbst aktualisieren, in dem eine Adresse einen Bounce oder eine Beschwerde auslöst. Was Ihnen die API nicht verschafft, ist Reputation: Die hängt an Ihrer Versanddomain, nicht an Ihrem Übermittlungsweg. Domain-Warmup und Authentifizierung gelten also genauso, egal wie Sie übermitteln.
Warum unterstützt fromHello beides?
Weil die Wahl eine Integrations- und keine Zustellbarkeitsfrage ist, bringt fromHello Adapter für beides mit: HTTP-APIs (Resend, Postmark, SendGrid), jeden SMTP-Server und Microsoft-365-Postfächer. Sie legen einen Standard pro Workspace fest und können eine Vorlage an einen eigenen Anbieter binden. In der fromHello Cloud, derzeit im Early Access, ist der E-Mail-Versand ab dem Tarif Team eingerichtet; bei Core oder beim Self-Hosting bringen Sie den Anbieter selbst mit. Limits liegen in jedem Fall beim Anbieter – Resend etwa dokumentiert für den SMTP-Endpunkt dasselbe Rate-Limit wie für die API. Und Sperrliste und Einwilligung setzt die Plattform unabhängig vom Übermittlungsweg durch: Eine gesperrte Adresse bleibt gesperrt, ob die Nachricht über HTTPS oder Port 587 versendet wird.