Resend oder Postmark: Welche Limits und Webhooks passen zu Ihrer Anwendung?

Die Preise richtig lesen

Der Abstand wirkt groß, hat aber eine Kehrseite. Auf der Resend-Seite hat der Free-Tarif eine Tagesgrenze von 100 E-Mails; die Nutzungsdoku ergänzt, dass die Tageskontingente nur für den Free-Tarif gelten und sich um Mitternacht UTC zurücksetzen. Ein Shop mit 3.000 Mails im Monat, die sich auf einen Schlussverkauf konzentrieren, stößt deshalb an die Tagesgrenze, obwohl die Monatssumme stimmt. Dazu kommt: Sowohl gesendete als auch empfangene E-Mails zählen zum Kontingent.

Bei Postmark steigen die Preise mit den Tarifen, nicht nur mit dem Volumen. Basic kostet 15 $ bei 10.000 E-Mails und enthält 5 Absenderdomains und 45 Tage Aufbewahrung. Pro (16,50 $ bei 10.000) ergänzt den Posteingang, bis zu 10 Domains und einstellbare Aufbewahrung bis 365 Tage; Platform (18 $) hat unbegrenzt viele Domains. Zusätze laufen separat: eine dedizierte IP kostet ab 50 $ im Monat je IP, für Versender ab 300.000 E-Mails im Monat auf Pro oder höher; die Überwachung von DMARC beginnt bei 14 $ im Monat je Domain; eine längere Aktivitätsaufbewahrung bei 5 $ im Monat. Bei Resend kosten weitere Domains 20 $ im Monat für 100 zusätzliche, und die dedizierte IP 30 $ im Monat für Kunden über 3.000 E-Mails am Tag im Scale-Tarif.

Ein Rechenbeispiel für ein Jahr bei 50.000 E-Mails im Monat: Resend Pro kostet 12 × 20 $ = 240 $, Postmark Basic 12 × 55 $ = 660 $. Die Differenz von 420 $ im Jahr muss man dem gegenüberstellen, was der teurere Dienst mitbringt: 45 statt 30 Tage Aufbewahrung, getrennte Ströme und im Pro-Tarif (60,50 $ bei 50.000) den Posteingang.

Limits, die Ihre Architektur bestimmen

Aus den API-Dokumentationen lassen sich die folgenden Werte ablesen. Sie sind kein Qualitätsurteil, aber sie entscheiden, wie Sie Warteschlangen, Anhänge und Wiederholungen bauen.

Der erste Versand im Code

Bei Resend übergeben Sie den Idempotency-Key als Option des SDK-Aufrufs; die Doku empfiehlt Schlüssel nach dem Muster Ereignistyp und Objekt-ID. Wiederholt Ihr Worker nach einem Timeout denselben Aufruf, liefert Resend innerhalb von 24 Stunden dieselbe Antwort, ohne die E-Mail ein zweites Mal zu verschicken. Das Beispiel folgt der Node.js-Anleitung und der Seite zu den Idempotency Keys:

import { Resend } from 'resend';

const resend = new Resend(process.env.RESEND_API_KEY);

const { data, error } = await resend.emails.send(
  {
    from: 'Acme <onboarding@resend.dev>',
    to: ['delivered@resend.dev'],
    subject: 'Ihre Bestellung 4812',
    html: '<p>Vielen Dank für Ihre Bestellung.</p>',
  },
  { idempotencyKey: 'bestellbestaetigung/4812' },
);

Bei Postmark gehört zu jedem Server ein eigenes Token, und die Absenderadresse muss als Absender-Signatur bestätigt sein, sonst antwortet die API mit HTTP 422. Zum Ausprobieren akzeptiert Postmark das Token POSTMARK_API_TEST: Die Anfrage wird geprüft, aber nichts zugestellt. Der Aufruf mit dem offiziellen SDK nach der Dokumentation zum Senden:

import { ServerClient } from "postmark";

const postmark = new ServerClient(process.env.POSTMARK_SERVER_TOKEN!);

const result = await postmark.sendEmail({
  From: "versand@acme.example",
  To: "kunde@example.com",
  Subject: "Ihre Bestellung 4812",
  TextBody: "Vielen Dank für Ihre Bestellung.",
  HtmlBody: "<html><body><strong>Vielen Dank</strong> für Ihre Bestellung.</body></html>",
  MessageStream: "outbound",
});

console.log({ messageId: result.MessageID });

Fehlt MessageStream, nutzt Postmark laut Dokumentation den Strom outbound, den Standardstrom für Transaktionsmails. Broadcast-Nachrichten lassen sich über denselben Parameter in einen eigenen Strom lenken, damit Newsletter und Passwort-Resets getrennt laufen.

Webhooks: signiert gegen abgesichert

Hier liegt der klarste Sicherheitsunterschied. Resend vergibt pro Endpunkt ein Signing Secret; die Doku verlangt, den rohen Request-Body zu verwenden, weil schon ein erneutes Serialisieren die Signatur zerstört, und zeigt die Prüfung mit resend.webhooks.verify sowie alternativ mit der Svix-Bibliothek. Der folgende Ausschnitt gibt die Form der Doku wieder:

export async function POST(req: NextRequest) {
  try {
    const payload = await req.text(); // roher Body, nicht als JSON geparst
    const result = resend.webhooks.verify({
      payload,
      headers: {
        id: req.headers['svix-id'],
        timestamp: req.headers['svix-timestamp'],
        signature: req.headers['svix-signature'],
      },
      webhookSecret: process.env.RESEND_WEBHOOK_SECRET,
    });
    // result enthält den geprüften Inhalt
  } catch {
    return new NextResponse('Invalid webhook', { status: 400 });
  }
}

Postmark hält fest, dass es HMAC-Signaturen nicht unterstützt, und empfiehlt Basic Auth in der URL, HTTPS und eine Firewall-Freigabe der Postmark-IP-Bereiche. Die Nutzlast sollten Sie zusätzlich auf erwartete Felder prüfen; die Beispielfunktion der Doku speichert außerdem jede MessageID und gibt bei Wiederholung "duplicate" zurück.

// Webhook-URL mit Basic Auth, wie in der Postmark-Doku beschrieben
https://<benutzer>:<passwort>@example.de/postmark-webhook

// Handler: Postmark signiert nicht, also Form prüfen und Dubletten abfangen
if (!event.RecordType || !event.MessageID) {
  throw new Error("Unexpected webhook payload");
}
const schonVerarbeitet = await db.webhookEvents.findOne({ messageId: event.MessageID });
if (schonVerarbeitet) return { status: "duplicate", messageId: event.MessageID };

Für ein Team mit Sicherheits-Checkliste, die signierte Webhooks fordert, ist das ein Ausschlusskriterium auf der einen oder anderen Seite. Wer ohnehin hinter einem API-Gateway mit IP-Filter arbeitet, kommt mit Postmarks Modell gut zurecht.

Vorlagen, React Email und Ströme

Resends Node.js-SDK nimmt laut der Next.js-Anleitung einen react-Parameter entgegen, dem Sie eine Komponente übergeben. React Email ist dabei nicht an Resend gebunden; die Dokumentation von React Email beschreibt auch Postmark, SendGrid, Mailgun und weitere Dienste, und bei Postmark rendern Sie die Komponente zuerst zu HTML. Alternativ nutzt Postmark gespeicherte Vorlagen: sendEmailWithTemplate mit TemplateAlias und TemplateModel. Wie sich beide Wege auf die Wahl des Template-Werkzeugs auswirken, steht im Vergleich MJML und React Email.

Zum Thema Ströme: Postmark ordnet jede Nachricht einem Strom zu (ohne Angabe dem Standardstrom outbound) und trennt Transaktions- und Broadcast-Verkehr. Resend trennt in seiner Preisseite die Reiter für Transaktions- und Marketing-E-Mails und rechnet Marketing nach Kontakten ab (zum Beispiel 40 $ bei 5.000 Kontakten laut dem Marketing-Reiter); wer beides über einen Anbieter betreibt, sollte die zwei Rechnungen getrennt betrachten.

Wann welcher Dienst

Resend passt, wenn…

• Ihre Jobs wiederholt werden können und Sie keine eigene Tabelle der versendeten Ereignisse pflegen möchten.
• Webhooks signiert ankommen sollen, damit die Prüfung im Handler wenige Zeilen braucht.
• Ihr Volumen zwischen 3.000 und 100.000 E-Mails liegt und der monatliche Preis für Sie den Ausschlag gibt.

Postmark passt, wenn…

• Transaktions- und Broadcast-Verkehr strikt getrennt laufen sollen und Sie 45 Tage Aufbewahrung ab dem Basic-Tarif schätzen.
• Sie den Posteingang als Teil des Dienstes nutzen und den Pro-Tarif ohnehin brauchen.
• Ihre Infrastruktur Basic Auth und IP-Listen ohnehin durchsetzt.

Wechsel in beide Richtungen

Beginnen Sie mit den DNS-Einträgen für die neue Absenderdomain und lassen Sie den alten Dienst parallel laufen, damit sich die Reputation aufbauen kann. Danach übertragen Sie die Vorlagen: Resend nimmt Variablen im Objekt variables, Postmark ein TemplateModel. Erst dann stellen Sie die Webhooks um, also Signaturprüfung bei Resend oder Basic Auth und IP-Regeln bei Postmark, und importieren Sperrlisten, bevor die erste Produktionsmail rausgeht. Wer zusätzlich SendGrid erwägt, findet den Dritten im Bunde im Vergleich Postmark gegen SendGrid; Loops als Lifecycle-Plattform behandelt Loops gegen Resend.