API-first E-Mail-Versand: welcher Dienst passt, wenn Ihr Produkt aus dem Code heraus sendet

Was Sie bei drei Volumen tatsächlich zahlen

Der Einstiegspreis täuscht, weil jeder Dienst zusätzliche E-Mails anders berechnet. Die Rechnungen unten nutzen die Zahlen der Preisseiten und enthalten weder Steuern noch Zusätze wie eine eigene IP-Adresse.

Daraus ergeben sich drei Lehren. Erstens kosten die meisten Dienste bei 10.000 E-Mails zwischen 15 $ und 20 $, die Entscheidung fällt dann über Handhabung und nicht über den Preis. Zweitens bleibt Resend mit seinem Tarif Pro bis 50.000 bei 20 $ (bei 100.000 zeigt der Schieberegler 35 $) und nennt für 200.000 E-Mails 160 $ im Tarif Scale, während Postmark Basic am Schieberegler 55 $ für 50.000 und 115 $ für 125.000 ausweist; für 200.000 hat Postmark keinen Stopp, den Wert lesen Sie auf der Preisseite ab, statt ihn aus dem Aufpreis von 1,80 $ je 1.000 hochzurechnen. Drittens trennt sich Amazon SES bei höheren Volumen deutlich von allen anderen, bringt aber den Aufwand der Eigenverwaltung mit. Bei Postmark kosten Pro und Platform an jedem gelesenen Stopp mehr als Basic (bei 50.000: 60,50 $ und 66 $, Stand 7. Oktober 2026); sie bringen unter anderem längere Aufbewahrung und ab 300.000 E-Mails die Möglichkeit einer dedizierten IP, die Stufen lesen Sie auf der Preisseite ab. Die Staffeln bei SparkPost und Mandrill lesen Sie dort nach, wenn Sie mit Millionen von E-Mails planen.

Der erste Aufruf bei zwei Diensten

Bei Postmark ist der Versand ein einzelner POST an den Endpunkt /email, authentifiziert über den Header X-Postmark-Server-Token. Jeder Postmark-Server hat laut Dokumentation einen eigenen Token, sodass Sie den Zugriff je Anwendung trennen können. Das Feld MessageStream wählt den Versandstrom; ohne Angabe nimmt Postmark den Standard-Transaktionsstream outbound. Das Beispiel entspricht dem curl-Aufruf der Doku:

curl "https://api.postmarkapp.com/email" \
  -X POST \
  -H "Accept: application/json" \
  -H "Content-Type: application/json" \
  -H "X-Postmark-Server-Token: server token" \
  -d '{
  "From": "sender@example.com",
  "To": "receiver@example.com",
  "Subject": "Postmark test",
  "TextBody": "Hello dear Postmark user.",
  "HtmlBody": "<html><body><strong>Hello</strong> dear Postmark user.</body></html>",
  "MessageStream": "outbound"
}'

Wer viele Nachrichten auf einmal schickt, nutzt den Endpunkt /email/batch, der nach Postmarks Beschreibung bis zu 500 Nachrichten in einem Aufruf annimmt. Bei Resend ist das Gegenstück das SDK-Beispiel der Referenz Send Email, ergänzt um den Idempotency-Key aus der Seite zu den Idempotency Keys:

import { Resend } from 'resend';

const resend = new Resend('re_xxxxxxxxx');

await resend.emails.send(
  {
    from: 'Acme <onboarding@resend.dev>',
    to: ['delivered@resend.dev'],
    subject: 'hello world',
    html: '<p>it works!</p>',
  },
  {
    idempotencyKey: 'welcome-user/123456789',
  },
);

Idempotenz: Wiederholungen ohne Doppelversand

Jede Warteschlange wiederholt irgendwann eine Anfrage, und ein Kunde, der zweimal denselben Bestätigungslink erhält, schreibt dem Support. Resend löst das mit einem Schlüssel: Laut Dokumentation prüft der Dienst, ob in den letzten 24 Stunden bereits eine E-Mail mit demselben Schlüssel versendet wurde, und liefert bei einer Wiederholung dieselbe Antwort, ohne erneut zu senden. Der Schlüssel darf bis zu 256 Zeichen lang sein, und Resend empfiehlt ein Muster wie <Ereignis>/<Objekt-ID>, im Beispiel welcome-user/123456789. Er gilt für POST /emails und POST /emails/batch, reist im HTTP-Header Idempotency-Key und wird im SDK als Option idempotencyKey übergeben; bei SMTP gibt es den Header Resend-Idempotency-Key.

In der Postmark-Dokumentation zum Versand habe ich keinen vergleichbaren Mechanismus gefunden. Dort schützen Sie sich, indem Sie vor einer Wiederholung in Ihrer eigenen Datenbank nachsehen, ob zu dem Ereignis bereits eine MessageID gespeichert ist. Dasselbe Prinzip gilt für Webhooks, worauf die Postmark-Doku in ihrem Handler-Beispiel selbst hinweist.

Webhooks: was sich von Dienst zu Dienst ändert

Ein Webhook-Handler für den Betrieb tut drei Dinge: Er prüft die Herkunft der Anfrage, antwortet schnell mit 200 und verarbeitet das Ereignis danach idempotent, weil Wiederholungen Dubletten erzeugen. Beim ersten Punkt gehen die Dienste getrennte Wege.

• Resend signiert die Anfragen und bietet in den SDKs eine Prüffunktion. Laut Dokumentation ist der Payload der rohe String-Body der Anfrage; parsen Sie das JSON und serialisieren es neu, passt die Signatur nicht mehr.
• Postmark unterstützt laut Webhook-Übersicht keine HMAC-Signaturen. Empfohlen werden HTTP Basic Auth in der Webhook-URL (https://benutzer:passwort@example.com/webhook) und eine Freigabeliste für die IP-Bereiche von Postmark. Beim Anlegen testet Postmark Ihren Endpunkt je Ereignistyp und erwartet ein 200.
• Mailgun signiert jede Anfrage mit dem kontoweiten Webhook-Signing-Key und liefert token, timestamp und signature mit, wie die Seite Securing Webhooks beschreibt. Der Schlüssel ist weder Ihr API-Key noch der Sending-Key der Domain.
• SendGrid kennt den signierten Event-Webhook: Der Dienst erzeugt ein Schlüsselpaar, signiert mit dem privaten Schlüssel und schickt die Signatur im Header X-Twilio-Email-Event-Webhook-Signature; Sie prüfen mit dem öffentlichen Schlüssel (Dokumentation).
• Amazon SES liefert Ereignisse nicht direkt aus. Es kann nach Angaben der AWS-Dokumentation über eine Benachrichtigungs-E-Mail, über ein SNS-Thema oder über Event Publishing melden. Das sind mehr Bausteine, passt aber, wenn Ihre Pipeline ohnehin in AWS läuft.

Testen, ohne echte Postfächer zu belasten

Resend dokumentiert Adressen unter resend.dev, etwa delivered@resend.dev, mit Varianten für Bounce, Spam-Markierung und unterdrückte Adressen; über ein Label nach dem Pluszeichen (delivered+signup@resend.dev) trennen Sie Testläufe. Die Seite zu Testmails rät ausdrücklich davon ab, an erfundene Adressen zu senden oder einen eigenen Fake-SMTP-Server zu betreiben, weil das den Domainruf beschädigen kann. Der Sandbox-Modus bei Postmark liefert Testnachrichten nicht an echte Empfänger aus, rechnet sie aber laut Dokumentation auf Ihr monatliches Sendevolumen an. Mailtrap bietet einen Email Sandbox, der als Fake-SMTP-Server alle Testmails abfängt; die SDKs schalten laut Dokumentation über ein sandbox-Flag und eine Inbox-ID zwischen Test und Live um. Mailtrap listet für den Versand 0 $ für 4.000 E-Mails im Monat (150 pro Tag), 15 $ für 10.000 und 85 $ für 100.000; Sandbox und Marketing werden separat bepreist.

EU-Region und Datenablage

Wer personenbezogene Daten aus der EU versendet, fragt nach dem Speicherort. Zwei Anbieter beschreiben das in ihrer Dokumentation klar. Mailgun erlaubt, neue Sendedomains in einer EU-Umgebung anzulegen (Basis-URL api.eu.mailgun.net); laut API-Übersicht verlassen Nachrichtendaten die Region nicht, in der sie verarbeitet werden, während Kontodaten, API-Schlüssel und Domainnamen global liegen. Bei Resend wählen Sie beim Hinzufügen einer Domain die Region, etwa eu-west-1 in Irland. Die Seite zur Regionswahl hält aber fest, dass die Wahl nur bestimmt, von wo versendet wird: Metadaten, Logs und API-Einträge liegen unabhängig davon in den USA. Für Amazon SES, SendGrid und Postmark habe ich dazu keine Aussage gelesen und mache deshalb keine; fragen Sie Ihre Datenschutzbeauftragte nach den Auftragsverarbeitungsverträgen der Anbieter.

Welcher Dienst für welche Lage

Next.js- oder React-Produkt mit Vorlagen im Repository

Resend. Die Vorlage ist eine typisierte Komponente, der Versand ein Aufruf, beides wandert im selben Pull Request durch die Prüfung. Wie sich Komponenten-Frameworks gegeneinander schlagen, zeigt der Vergleich MJML gegen React Email.

Kritische Systemmails: Zugang, Belege, Warnungen

Postmark, mit dem Vorbehalt des hohen Aufpreises über 10.000 E-Mails. Die Trennung in Message Streams hilft besonders, wenn zusätzlich Newsletter laufen; wie Sie beides sauber auseinanderhalten, steht im Artikel Transaktionale und Marketing-E-Mails.

Hohes Volumen und AWS-Erfahrung im Team

Amazon SES. Sie übernehmen Bounce-Verarbeitung und Beschwerden selbst, der Support kommt von AWS und nicht von einem Produktteam, dafür kostet eine Viertelmillion E-Mails 40 $. Mehr zu großen Mengen auf der Seite E-Mail für hohes Volumen.

Mehr API-Fläche als nur Senden

Mailgun oder SendGrid. Mailgun listet auf der Preisseite unter anderem Inbound-Routing und E-Mail-Validierung, SendGrid hat daneben Marketing Campaigns mit einem Gratisplan bis 2.000 Kontakte. Gegenüberstellungen: SendGrid gegen Mailgun und Postmark gegen SendGrid.

Wechsel von SMTP auf die API, ohne alles umzuschreiben

1. Kapseln Sie den Anbieter hinter einer eigenen Funktion. Wenn der Wechsel nur eine Datei berührt, bindet Sie die Entscheidung von heute nicht.
2. Verifizieren Sie Ihre echte Domain in der ersten Woche. Ein Dienst, der mit der Testdomain funktioniert, kann an Ihren DNS-Einträgen scheitern.
3. Speichern Sie die Nachrichten-ID aus der Antwort beim Datensatz des Nutzers. Fragt der Support nach einer bestimmten Mail, brauchen Sie sie.
4. Lösen Sie einen Bounce und eine Beschwerde absichtlich aus und prüfen Sie, dass Ihre Anwendung die Ereignisse empfängt und die Adresse künftig überspringt.
5. Lassen Sie alte und neue Strecke eine Weile parallel laufen und stellen Sie Nachrichtenart für Nachrichtenart um, beginnend mit der, die am wenigsten Schaden anrichten kann. Weitere Optionen für Entwickler bietet die Seite E-Mail-Tools für Entwickler.