Rechner · Tooling
Email-API-Rechner: Resend vs Postmark vs SendGrid vs SES
AWS SES ist 10× günstiger — und 10× mehr Setup-Aufwand. Resend für Devs, Postmark für Deliverability. Ehrlich gerechnet.
Bei 50k Emails / Monat sparst du
497 €
pro Jahr — Wechsel von Postmark zu AWS SES
Use-Case
10× günstiger, 10× mehr Aufwand
Old-School, Marketing+Trans
Dev-Liebling, React-Email nativ
EU-Hosted, Volumen-fair
Devs-First, Inbound-stark
Deliverability-King, Transactional-Only
Monatlich · 50k Emails
€ pro Monat
Transactional vs Marketing — warum du beides separat brauchst
Die wichtigste Architektur-Entscheidung bei Email ist nicht der Provider, sondern die Trennung der Streams. Transactional-Mails (Password-Reset, Receipt, Login-Code) müssen sofort und mit höchster Deliverability beim User ankommen. Marketing-Mails (Newsletter, Promos, Re-Engagement) sind weniger zeitkritisch und haben naturgemäß höhere Bounce-, Unsubscribe- und Spam-Complaint-Raten.
Wenn du beide Streams über dieselbe Sending-Domain und denselben API-Key verschickst, passiert Folgendes: dein Marketing-Newsletter erzeugt diesen Monat 0,8 % Spam-Complaints (normal, Newsletter haben immer Quote). Die Reputation deiner Domain bei Google und Microsoft sinkt um zwei Punkte. Drei Wochen später kommen 5 % deiner Password-Reset-Mails nicht mehr an, weil sie im Spam landen. Du verlierst Conversion ohne zu wissen warum.
Best Practice in 2026:
- Sub-Domain-Trennung: mail.app.com für Transactional, news.app.com für Marketing. SPF und DKIM separat aufsetzen.
- Provider-Trennung: Postmark oder Resend für Transactional, Loops oder Mailchimp für Marketing. Bei Mengen unter 50k/Monat ist die zusätzliche Komplexität minimal.
- Stream-Konzept: Postmark hat das nativ — du definierst „Transactional Stream" und „Broadcast Stream" mit getrennten Reputationen aber gleicher API.
SES ist 10× günstiger — und 10× mehr Aufwand
Bei 100.000 Mails pro Monat zahlt AWS SES exakt 10 USD. Resend zahlt 35 USD. Mailgun zahlt 80 USD. SendGrid zahlt 89,95 USD. Auf den ersten Blick: warum nutzt nicht jeder SES? Antwort: weil der gesparte 70 USD/ Monat dich 5-10 Stunden Engineering kosten — und das jeden Monat aufs Neue.
Was du bei SES selbst aufbauen musst, was bei Resend out-of-the-box läuft:
- Templates und Variable-Substitution. SES SDK kann das technisch, aber kein UI, keine Versionierung, kein Preview.
- Bounce- und Complaint-Handling. SES sendet diese Events über SNS-Topic, du musst Lambda aufsetzen, in eine DB schreiben, Suppression-Liste pflegen, Webhooks in dein User-System feuern.
- Sandbox-Production-Migration. SES startet im Sandbox-Mode (200 Mails/Tag, nur verifizierte Empfänger). Du schreibst Support-Ticket, wartest 1-2 Tage, eventuell mehrere Iterationen mit AWS bevor Production-Access freigeschaltet wird.
- Deliverability-Monitoring. SES gibt dir Reputation- Metrics in CloudWatch, aber kein eingebautes „Inbox-Placement-Test" wie Postmark.
- Domain-Verification. SPF, DKIM, DMARC selbst konfigurieren — Postmark und Resend zeigen dir die DNS-Records mit Copy-Button.
Faustregel: unter 250.000 Mails pro Monat ist Resend oder Postmark wirtschaftlicher (ECP — Engineering Cost vs Price). Über 1.000.000 Mails wird SES klar günstiger und der Aufwand amortisiert sich. Dazwischen ist es Geschmackssache.
Resend für Dev-Teams — was sie richtig machen
Resend ist 2022 in den Markt eingestiegen mit einer einfachen Beobachtung: SendGrid-API ist seit 2010 unverändert und fühlt sich wie 2010 an. Resend hat eine moderne REST-API mit konsistenten Errors, gut typisierten SDKs (TS, Python, Go, Ruby, Rust) und — wichtigster Hebel — React-Email als First-Class-Citizen.
React-Email ist ein OSS-Projekt von Resend, das Email-Templates als React-Components schreiben lässt. Statt mit verschachtelten HTML- Tabellen kämpfen schreibst du:
<Html>
<Section>
<Heading>Hi, {firstName}</Heading>
<Button href={link}>Confirm</Button>
</Section>
</Html>React-Email rendert das in Cross-Mail-Client-kompatibles HTML (Tabellen inklusive — die hässliche Arbeit wird abstrahiert). Resend integriert das Tool nativ: in der API kannst du direkt React-Komponenten als Body angeben, statt HTML-Strings. Für Dev-Teams, die ohnehin in React arbeiten, ist das ein massiver Geschwindigkeits-Boost.
Was Resend NICHT hat (Stand Mai 2026): Inbound-Routing, Email- Validation-Suite (Mailgun ist hier stärker), und Marketing-Features wie Audience-Management. Für reine Transactional-Workloads ist Resend erste Wahl. Für Mixed-Use brauchst du noch einen Partner.
Deliverability-Scores im Vergleich
Deliverability ist die unsichtbare Metric, die alle Email-Provider beeinflusst, aber kaum einer transparent meldet. Das hier sind die ehrlichen Beobachtungen aus dem deutschsprachigen Markt (Mai 2026):
- Postmark: 99,5 %+ Inbox-Placement bei sauber konfigurierten Domains. Streams-Pattern + dedizierte IPs für Transactional sind der Grund.
- Resend: ~98 % Inbox-Placement, mit gelegentlichen Hick-Ups bei Outlook 365 (langjähriges Microsoft-vs-Newcomer-Thema). Trend gut, schnell besser.
- AWS SES: 95-98 % je nach eigener Domain-Reputation. Bei sauberer Konfig sehr gut, bei Fehlkonfig schlecht.
- SendGrid: Sehr abhängig vom Plan. Free/Essentials mit shared IPs: 92-95 %. Pro+ mit dediziertem IP: 98 %+. Hat historischen Ballast durch alte Spam-Versender im Shared-Pool.
- Mailgun: 96-98 % bei Foundation+. Stabil, aber ohne den „Premium-Touch" von Postmark.
- Mailchimp: 97 % für Marketing, was für die Kategorie gut ist (Marketing-Mails werden grundsätzlich strikter gefiltert).
Wichtigster Take-away: Deliverability hängt zu 70 % von DEINER Konfiguration ab (SPF, DKIM, DMARC, Warming, Content-Quality), nicht vom Provider. Postmark ist marginal besser, weil sie strenger kuratieren, aber die meisten Probleme sind eigene Hausaufgaben.
Häufige Fragen
Resend, Postmark oder SendGrid — was ist der wirkliche Unterschied?
Resend ist der Dev-Liebling 2025: React-Email nativ, schöne API, super DX. Postmark ist Deliverability-Sieger: Streams-Pattern, Spam-Sieg, aber teurer. SendGrid ist der Old-School-Standard mit gemischtem Reputation (geteilte IPs in Cheap-Tiers leiden, dedizierte IPs ab Pro). Bei kleinen Volumes nimm Resend. Bei {'<1 %'}-Bounce-Anspruch nimm Postmark. SendGrid nur bei Bestandsverträgen oder wenn Twilio-Integration gewünscht ist.
AWS SES ist 10× günstiger — wieso nicht immer?
Drei Gründe. Erstens: SES hat Sandbox-Mode by default mit 200 Mails/Tag — du musst ein Support-Ticket für Production-Access stellen, das 1-2 Tage dauert. Zweitens: SES hat keine eingebauten Templates, Suppression-List-UI oder Bounce/Complaint-Webhooks aus der Box — alles selbst bauen (oder SES + Resend kombinieren). Drittens: Deliverability bei SES ist solide, aber du musst SPF/DKIM/DMARC und Reputation-Management selbst betreuen. Für 100k+ Mails/Monat lohnt sich der Aufwand, darunter selten.
Transactional vs Marketing — warum getrennt?
Transactional-Mails (Login, Receipt, Password-Reset) müssen sofort ankommen mit hoher Deliverability. Marketing-Mails (Newsletter, Promos) sind weniger zeitkritisch und haben höhere Bounce-/Spam-Raten. Wenn du beides über denselben Stream verschickst, ziehst du den Marketing-Spam-Score über deine Transactional-Reputation — und Login-Mails landen plötzlich im Junk-Ordner. Best Practice: zwei separate Sending-Domains, zwei separate API-Keys, oder direkt zwei Provider (Resend für Trans, Mailchimp für Marketing).
Warum gibt Resend so viel weg im Free-Tier?
Resend setzt auf Dev-Adoption — wenn du als Side-Project mit 3.000 Mails/Monat anfängst und die API liebst, hast du Resend in deinem nächsten Job als Default. Sehr ähnlich wie Cloudflare oder Vercel-Strategie. Das Geld kommt später, wenn Apps skalieren — und dann zahlen Teams gerne, weil sie das Tool kennen und brauchen.
Wie ehrlich sind Deliverability-Versprechen?
Sehr unterschiedlich. Postmark veröffentlicht öffentliche Deliverability-Reports und garantiert Inbox-Placement bei seriöser Konfiguration — sie sind der Goldstandard. Resend ist neu, aber zeigt gute Zahlen in den ersten Audits. SendGrid hat in Cheap-Tiers messbare Probleme mit Yahoo/Outlook-Inboxing. AWS SES ist solide, aber stark abhängig von der eigenen Domain-Reputation. Für mission-critical Mails immer mit Mail-Tester.com oder GlockApps gegenchecken.
Inbound-Routing — wer braucht das wirklich?
Wenn deine App User-Mails empfängt (zB Reply-to-Tickets, Forward-Aliase, Email-Parsing für Workflows), brauchst du Inbound. SendGrid und Mailgun haben das seit 10+ Jahren. Postmark hat es als Streams-Feature. Resend nicht (bisher). AWS SES kann's via Lambda-Trigger. Für reine Outgoing-Apps ist Inbound irrelevant.
Verwandte Rechner
Weiter rechnen
Newsletter
Jeden Freitag ein neuer Rechner oder Vergleich
Konkrete Zahl, keine 1.500-Wörter-Texte.
Mit der Anmeldung willigst du ein, von AInfach Data (Daten- & KI-Beratungsagentur) Werbe-E-Mails und Preisupdates zu erhalten. Bestätigung per Double-Opt-in, Abmeldung jederzeit mit 1 Klick.
Auch alle Rechner ansehen.