Warum dieselben 50.000 E-Mails $5 oder $66 kosten

Die Preislücke erklärt

Der Preisunterschied liegt im Geschäftsmodell begründet: Infrastruktur versus Plattform. Amazon SES verkauft reine Rechenleistung und Bandbreite (Infrastruktur), während Provider wie Postmark oder Mailgun ein verwaltetes Gesamtpaket verkaufen (Plattform) – mit besserer Oberfläche, spezialisiertem Support und kuratierten IP-Pools. Für 50.000 E-Mails kostet SES à la carte rund $5, während die Tarife von Postmark bis zu $66 erreichen können. Sie bezahlen für weniger Betriebsaufwand und für die Qualität der Werkzeuge rund um die API.

Die nackten Zahlen: 50.000 E-Mails

Wenn ich auf die Incident-Queue oder die monatliche Cloud-Rechnung schaue, gehört das Preisgefälle beim E-Mail-Versand zu den auffälligsten Posten. Um es zu verstehen, müssen wir uns die aktuellen Marktpreise mit Stand September 2026 ansehen.

Der Infrastruktur-Ansatz: Amazon SES

Amazon SES ist die Kostenbasis. Laut der Preisseite kostet der Versand à la carte $0.10 pro 1.000 E-Mails.

• Rechnung: (50.000 / 1.000) * $0.10 = $5.00.

AWS hat am 21. Juli 2026 allerdings neue gestaffelte Tarife eingeführt. Im Essentials-Tarif kosten 1.000 E-Mails $0.16. Der Pro-Tarif kostet $0.22 pro 1.000 plus eine monatliche Gebühr von $105 pro Region. Der Enterprise-Tarif kostet $0.23 pro 1.000 plus $500 pro Monat. Für ein kleines Produktteam ist das À-la-carte-Modell am günstigsten, aber die gesamte Konfigurationslast liegt beim Entwickler.

Der Plattform-Ansatz: Postmark und Mailgun

Provider wie Postmark und Mailgun setzen auf die Developer Experience. Laut der Preisseite von Postmark kostet der Basistarif $15 pro Monat für 10.000 E-Mails. Die Mehrkosten liegen zwischen $1.80 und $1.20 pro 1.000 E-Mails.

• Rechnung (Postmark): $15 (erste 10.000) + (40.000 / 1.000 * $1.20) = $15 + $48 = $63. (Je nach konkretem Tarif kann das bis zu $66 erreichen.)

Ähnlich beginnen die Preise von Mailgun bei $15 pro Monat für 10.000 E-Mails, mit Mehrkosten zwischen $1.80 und $1.10 pro 1.000. Diese Provider bieten gehostete Templates und intuitivere Analysen. Das rechtfertigt den Aufpreis für Teams, die keine eigenen Monitoring-Dashboards bauen wollen.

Die moderne Mitte: Resend

Resend zielt auf den modernen Produkt-Stack. Die Preisseite nennt einen kostenlosen Tarif mit 3.000 E-Mails pro Monat (begrenzt auf 100 pro Tag). Der Pro-Tarif kostet $20 pro Monat für 50.000 E-Mails, Mehrkosten liegen bei $0.90 pro 1.000.

• Rechnung (Resend): pauschal $20 für die ersten 50.000.

Annahme, Zustellung und Platzierung: der entscheidende Unterschied

Ein häufiger Fehler, den ich in technischen Dokumentationen sehe: Diese drei Begriffe werden synonym verwendet. Sie bedeuten nicht dasselbe, und keine API kann den letzten Schritt garantieren.

1. Annahme: Das ist die API-Antwort. Wenn Sie einen Payload per POST an einen Endpunkt senden, gibt der Provider 202 Accepted oder 200 OK zurück. Das bedeutet nur, dass der Provider die Anfrage erhalten hat und sie die Basisvalidierung bestanden hat. Es heißt nicht, dass die E-Mail das Haus verlassen hat.
2. Zustellung: Das ist der SMTP-Handshake. Der Provider versucht, die Nachricht an den empfangenden Server des Empfängers zu übergeben. Ein „delivered“-Event bedeutet, dass der empfangende Server gesagt hat: „Ich nehme das an.“
3. Inbox Placement: Das ist das endgültige Ziel. Der empfangende Server (Gmail, Outlook usw.) entscheidet, ob die E-Mail im Posteingang, im Tab „Werbung“ oder im Spam-Ordner landet. Das hängt von den internen Filtern des Empfängers, Ihrer Absenderreputation und Ihren Authentifizierungseinträgen ab.

Um Ihre Zustellchancen zu verbessern, müssen Sie Ihr DNS korrekt konfigurieren. Ich empfehle einen DNS-Checker, um sicherzustellen, dass Ihre Einträge propagiert werden. Folgen Sie einem strikten Leitfaden zu DKIM, SPF und DMARC, um nachzuweisen, dass Sie der sind, der Sie vorgeben zu sein.

Auf Zuverlässigkeit ausgelegt entwickeln

Das Senden einer E-Mail ist ein externer Seiteneffekt. In einem verteilten System sind Seiteneffekte gefährlich, weil sie doppelt ausgeführt werden oder unbemerkt scheitern können.

Das Idempotenzproblem

Läuft Ihr Anwendungsserver beim Warten auf die Antwort der E-Mail-API in einen Timeout, wissen Sie nicht, ob die E-Mail gesendet wurde. Versuchen Sie es einfach erneut, erhält der Nutzer zwei E-Mails. Deshalb ist ein Idempotenzschlüssel unverzichtbar.

Ein Idempotenzschlüssel ist eine eindeutige Kennung (meist eine UUID), die im Header mitgesendet wird. Sieht die API denselben Schlüssel zweimal, gibt sie die zwischengespeicherte Antwort der ersten erfolgreichen Anfrage zurück, statt eine zweite E-Mail zu senden.

{ "idempotency_key": "req_8823_abc_123", "from": "notifications@example.com", "to": "user@gmail.com", "subject": "Your Order has Shipped", "body": "Your package is on the way!" }

Umgang mit Versand durch Agenten

Mit dem Aufkommen von KI-Agenten und MCP-Servern sehen wir mehr „Agent-to-Agent“-Kommunikation (A2A). Agenten sollten nie uneingeschränkten Zugriff auf eine Versand-API haben. Gerät ein LLM in eine Schleife, kann es Ihr Kontingent von 50.000 E-Mails in wenigen Minuten verbrauchen und Ihre Absenderreputation zerstören.

Richten Sie einen Freigabe-Workflow für Agenten ein:

1. Entwurfsphase: Der Agent erzeugt die E-Mail und speichert sie in einer Tabelle pending_emails.
2. Human-in-the-Loop: Ein Nutzer oder ein überwachender Agent prüft den Inhalt.
3. Ausführung: Das System ruft die API erst auf, nachdem ein Flag status = 'approved' gesetzt wurde.

Die technische Checkliste für die Migration

Wenn Sie von einem teuren zu einem günstigeren Provider wechseln (oder umgekehrt), tauschen Sie nicht einfach den API-Schlüssel aus. Nutzen Sie diese Checkliste:

• DNS-Audit: Prüfen Sie Ihre SPF-Einträge. Stellen Sie sicher, dass Sie das Limit von 10 Lookups nicht überschreiten.
• Webhook-Zuordnung: Jeder Provider verwendet andere Event-Namen. Ordnen Sie delivered bei Provider A dem Event sent bei Provider B zu.
• Sperrlisten-Abgleich: Exportieren Sie Ihre Bounce- und Beschwerdelisten. Importieren Sie 50.000 Nutzer bei einem neuen Provider und senden an bekannte Bounces, wird Ihr Konto sofort gesperrt.
• Umgang mit Rate-Limits: Implementieren Sie exponentiellen Backoff für Fehler 429 Too Many Requests.

Beispiel für die Fehlerbehandlung

async function sendWithRetry(payload, attempt = 1) { try { const response = await emailApi.send(payload); return response; } catch (error) { if (error.status === 429 && attempt <= 3) { const delay = Math.pow(2, attempt) * 1000; await new Promise(res => setTimeout(res, delay)); return sendWithRetry(payload, attempt + 1); } throw error; } }

Das richtige Werkzeug wählen

Wenn Sie als Einzelentwickler einen Prototyp bauen, genügen die kostenlosen Tarife von Resend oder die À-la-carte-Preise von SES. Verwaltet Ihr Produktteam einen komplexen transaktionalen Ablauf mit hoher Tragweite (etwa Passwort-Zurücksetzungen oder Abrechnungswarnungen), ist die Betriebssicherheit eines Plattform-Providers die $60 Unterschied oft wert.

Wer KI-native Anwendungen baut, braucht mehr als nur eine Leitung. Sie brauchen Agent-Readiness, etwa einen MCP-Server und eine strukturierte Datei llms.txt, damit Ihre Agenten verstehen, wie sie mit Ihrer Kommunikationsschicht interagieren. Hier wird eine spezialisierte API zum Hebel statt zum reinen Kostenfaktor.

Letztlich ist der Preis der API der kleinste Teil der Rechnung. Die eigentlichen Kosten sind die Entwicklerzeit, die in das Debugging eines falsch konfigurierten DNS-Eintrags fließt oder in das Aufräumen nach einer Reputationskrise, weil die Sperrliste nicht gepflegt wurde. Ob Sie den Weg für $5 oder für $66 wählen: Priorisieren Sie die Telemetrie und die Werkzeuge, die Ihre E-Mails am Laufen halten.

Mehr entwicklerorientierte E-Mail-Infrastruktur finden Sie unter https://sendhq.cc.