SMTP oder E-Mail-API: Was sollte Ihre App verwenden?

Früher oder später muss jedes Produkt E-Mails versenden, und die erste Frage lautet, wie Ihr Code mit dem Mailsystem kommuniziert. Es gibt zwei Antworten: direkt SMTP sprechen oder eine E-Mail-API über HTTPS aufrufen.

Beides funktioniert. Die Anforderungen an Ihre Anwendung sind jedoch sehr unterschiedlich, und die richtige Wahl hängt davon ab, wo Ihr Code läuft und wie viel E-Mail-Infrastruktur Sie selbst verantworten möchten.

Worin SMTP gut ist

SMTP (Simple Mail Transfer Protocol) ist das Protokoll, über das Mailserver seit Anfang der 1980er-Jahre E-Mails austauschen. Jeder Postfach-Anbieter unterstützt es, und fast jedes Framework hat einen eingebauten SMTP-Mailer: Nodemailer, Djangos send_mail, Laravel Mail, Rails’ Action Mailer.

Stärken:

• Universell. Jedes E-Mail-Konto und jede Programmiersprache beherrscht es.
• Kein Vendor-Lock-in. Sie wechseln den Anbieter, indem Sie einen Hostnamen und ein Passwort ändern.
• Ihre eigene Domain und Reputation. E-Mails verlassen Sie über einen Server, den Sie kontrollieren oder mieten, von Adressen auf Ihrer Domain.

Wo SMTP in einer App schmerzt

SMTP ist ein gesprächiges, zustandsbehaftetes Protokoll. Um eine Nachricht zu senden, öffnet Ihre App eine TCP-Verbindung, begrüßt den Server, stuft auf TLS hoch, authentifiziert sich und arbeitet dann eine Reihe von Befehlen und Antworten für Absender, Empfänger und Daten ab. Jeder Schritt ist ein Netzwerk-Roundtrip.

In der Praxis führt das zu:

• Langsamen Anfragen. Ein Handshake mit einem weit entfernten Server kann Hunderte Millisekunden dauern, bevor die Nachricht überhaupt beginnt.
• Blockierten Ports. Viele Cloud-Plattformen und Serverless-Laufzeitumgebungen beschränken die ausgehenden Ports 25, 465 und 587, um Spam zu bekämpfen. HTTPS auf Port 443 wird fast nie blockiert.
• Zugangsdaten überall. Jeder Dienst, der E-Mails versendet, braucht das Postfach-Passwort. Wer es rotieren will, muss alle Dienste neu deployen.
• Wenig Transparenz. Wenn etwas fehlschlägt, steht der Fehler in den Logs eines einzelnen Dienstes – falls er überhaupt protokolliert wurde.

Was eine E-Mail-API ändert

Eine E-Mail-API verpackt den Versand in eine einzige HTTPS-Anfrage mit JSON-Body. Ihr Code sendet ein POST und erhält einen Statuscode zurück. Der API-Dienst hält die SMTP-Verbindung und die Zugangsdaten.

Stärken:

• Eine schnelle Anfrage über Port 443, von überall: Container, Serverless-Funktionen, Edge-Laufzeitumgebungen, CI-Jobs.
• Schlüssel statt Passwörter. Jeder Dienst erhält seinen eigenen API-Schlüssel mit eingeschränkten Berechtigungen, und Sie können einen widerrufen oder rotieren, ohne die anderen anzufassen.
• Zentrale Transparenz. API-Aufrufe und Zustellergebnisse werden an einem Ort erfasst.
• Klare HTTP-Fehler. Ein 401 oder 429 ist weit einfacher zu behandeln als ein SMTP-Antwortcode, der in einem Stacktrace vergraben ist.

Der Kompromiss: Bei den meisten E-Mail-APIs gehen E-Mails über deren Server raus. Sie übernehmen also deren Einrichtung der Absenderdomain und deren IP-Reputation, und ein späterer Wechsel bedeutet, alles anderswo erneut zu verifizieren.

Inbixio: eine API vor Ihrem SMTP-Server

Inbixio beruht auf einer einfachen Idee: den wertvollen Teil von SMTP behalten – Ihren eigenen Mailserver und Ihre Absenderidentität – und den Teil ersetzen, der in Anwendungen schmerzt.

1. Sie verbinden Ihren SMTP-Server einmalig im Dashboard: Host, Port, Benutzername und Passwort.
2. Ihre Dienste rufen POST /api/send-email/ mit einem Inbixio-API-Schlüssel auf.
3. Inbixio meldet sich über TLS bei Ihrem SMTP-Server an und stellt die Nachricht von Ihrer Adresse zu.
4. Ihr Dashboard zeigt die Anzahl gesendeter E-Mails, die Rate fehlgeschlagener Zustellungen und die Zustelllatenz sowie ein Log jedes API-Aufrufs.

curl -X POST https://backend.inbixio.com/api/send-email/ \
  -H "X-API-Key: $INBIXIO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"to_email":"user@example.com","subject":"Welcome!","message":"<h1>Hello</h1>"}'

Das bringt Ihnen:

• Ihr SMTP-Passwort ist an einem Ort gespeichert. Ihre Dienste sehen immer nur API-Schlüssel.
• Schlüssel lassen sich an einen bestimmten Server binden, sodass der Abrechnungsdienst von billing@ und der Authentifizierungsdienst von security@ sendet.
• Die Berechtigungen jedes Schlüssels sind explizit festgelegt, und ein Schlüssel kann erneuert oder gelöscht werden, ohne den Mailserver anzufassen.
• Sie behalten Ihre Absenderdomain, Ihren Anbieter und Ihre Reputation. Wechseln Sie den Mail-Anbieter, aktualisieren Sie einen einzigen Servereintrag, und Ihr Code bleibt unverändert.

Im direkten Vergleich

Was sollten Sie also verwenden?

• Verwenden Sie SMTP direkt für eine einzelne kleine App auf einem Server, auf dem ausgehendes SMTP erlaubt ist und Sie die Zugangsdaten gern dort verwalten.
• Verwenden Sie eine E-Mail-API, wenn Sie mehrere Dienste betreiben, auf Plattformen deployen, die SMTP-Ports blockieren, zentrale Logs möchten oder Postfach-Passwörter nicht länger herumreichen wollen.
• Verwenden Sie Inbixio, wenn Sie diese API-Vorteile möchten, Ihre E-Mails aber weiterhin über Ihren eigenen Mailserver und Ihre eigene Domain laufen sollen.

Bereit, es auszuprobieren? Der Fünf-Minuten-Schnellstart bringt Sie von der Registrierung bis zur zugestellten E-Mail.