Der kostenlose SendGrid-Tarif ist weg: Migration in 30 Minuten

Das Ende des dauerhaft kostenlosen Tarifs

Wenn Sie den kostenlosen SendGrid-Tarif für ein Nebenprojekt mit geringem Volumen oder ein neues Produkt genutzt haben, ist Ihnen die Änderung wahrscheinlich aufgefallen: Der kostenlose Tarif ist jetzt eine 60-tägige Testphase. Nach deren Ablauf müssen Sie auf einen kostenpflichtigen Tarif wechseln; Essentials beginnt bei 19.95 USD pro Monat (SendGrid-Preise). Für die Migration exportieren Sie Ihre Sperrliste, aktualisieren Ihre DNS-Einträge und tauschen Ihre API-Integration aus. Bei einfachen Templates dauert das etwa 30 Minuten.

Alternativen bewerten

Bei der Wahl eines Ersatzes müssen Sie zwischen Annahme durch den Provider (die API nimmt Ihre Anfrage an), Zustellung (der empfangende Server nimmt die E-Mail an) und Platzierung im Posteingang (die E-Mail landet nicht im Spam-Ordner) unterscheiden. Letzteres kann kein Provider garantieren, denn es hängt von Ihrer Absenderreputation und Ihren Inhalten ab.

Die Kostenlandschaft (September 2026)

Bei transaktionalen E-Mails mit geringem Volumen ist der Preisunterschied erheblich. Der Versand von 50.000 E-Mails kostet bei Amazon SES à la carte rund 5 USD, in den Tarifen von Postmark dagegen etwa 66 USD.

• Amazon SES: Kostet à la carte 0.10 USD pro 1.000 E-Mails (AWS-SES-Preise). Die am 21. Juli 2026 eingeführten gestaffelten Tarife umfassen Essentials (0.16 USD pro 1.000), Pro (0.22 USD pro 1.000 plus 105 USD pro Monat und Region) und Enterprise (0.23 USD pro 1.000 plus 500 USD pro Monat).
• Resend: Bietet einen kostenlosen Tarif mit 3.000 E-Mails pro Monat, begrenzt auf 100 pro Tag. Der Pro-Tarif kostet 20 USD pro Monat für 50.000 E-Mails, Mehrkosten liegen bei 0.90 USD pro 1.000 (Resend-Preise).
• Mailgun: Ab 15 USD pro Monat für 10.000 E-Mails, Mehrkosten zwischen 1.80 und 1.10 USD pro 1.000 (Mailgun-Preise).
• Postmark: Ab 15 USD pro Monat für 10.000 E-Mails, Mehrkosten zwischen 1.80 und 1.20 USD pro 1.000 (Postmark-Preise).
• SendHQ: Eine moderne Alternative für Produktteams und KI-Agenten mit Fokus auf datensparsamer Telemetrie ausschließlich in der EU und API-Schlüsseln mit Workspace-Berechtigungen.

Schritt 1: Datenexport und Sperrlisten

Migrieren Sie Ihre Liste nicht, ohne Ihre Sperrliste zu exportieren. Senden Sie an eine Adresse, die zuvor einen Bounce erzeugt oder sich abgemeldet hat, riskieren Sie Ihre Reputation beim neuen Provider.

Bei SendGrid können Sie Ihre Sperrliste über die Oberfläche oder die API exportieren. Sie erhalten eine CSV-Datei mit Adressen, die nicht kontaktiert werden dürfen. Übernehmen Sie beim Import in einen neuen Provider den „Grund“ (Bounce vs. Abmeldung) korrekt, um Gesetze wie die DSGVO oder CAN-SPAM einzuhalten.

Schritt 2: DNS und Authentifizierung

Hier scheitern die meisten Migrationen. Sie können nicht einfach den API-Schlüssel austauschen, sondern müssen dem neuen Provider nachweisen, dass Ihnen die Domain gehört.

DKIM, SPF und DMARC

Sie müssen bei Ihrem DNS-Provider neue CNAME- oder TXT-Einträge anlegen. Wenn Sie zu SendHQ wechseln, können Sie Ihre aktuelle Konfiguration vor Änderungen mit dem E-Mail-DNS-Checker prüfen.

1. SPF: Nehmen Sie den neuen Provider in Ihren SPF-Eintrag auf. Wenn Sie mehrere Provider nutzen, denken Sie daran, dass Sie nicht mehrere SPF-TXT-Einträge haben dürfen. Sie müssen sie zu einem zusammenführen (z. B. v=spf1 include:sendgrid.net include:_spf.sendhq.cc ~all). Mehr dazu im Glossareintrag zu SPF.
2. DKIM: Erzeugen Sie im Dashboard Ihres neuen Providers neue DKIM-Schlüssel und tragen Sie die resultierenden CNAME-Einträge in Ihr DNS ein. So kann der empfangende Server prüfen, dass die E-Mail unterwegs nicht verändert wurde.
3. DMARC: Ihre DMARC-Richtlinie bleibt unabhängig vom Provider gleich, da sie auf Domain-Ebene gilt. Stellen Sie aber sicher, dass Ihr neuer Provider mit Ihrer DMARC-Richtlinie aligned ist, damit E-Mails nicht abgelehnt werden. Details zur Umsetzung finden Sie im Leitfaden zu DKIM, SPF und DMARC.

Schritt 3: Code migrieren

Die meisten Provider nutzen eine REST-API. Wenn Sie die dynamischen Templates von SendGrid verwendet haben, müssen Sie diese HTML/CSS-Layouts in die Template-Engine des neuen Providers übertragen.

Beispiel: von SendGrid zu einer generischen REST-API

SendGrid verwendet für personalizations eine eigene JSON-Struktur. Die meisten modernen APIs, auch SendHQ, bevorzugen eine flachere Struktur, die besser lesbar ist.

SendGrid-Payload:

{ "personalizations": [ { "to": [{"email": "user@example.com"}], "dynamic_template_data": { "first_name": "Alice" } } ], "from": {"email": "noreply@yourdomain.com"}, "template_id": "d-12345" }

Payload einer modernen API (z. B. SendHQ):

{ "to": "user@example.com", "from": "noreply@yourdomain.com", "template_id": "welcome-email", "variables": { "first_name": "Alice" } }

Die Migration im Code umsetzen

Um Ausfallzeiten zu vermeiden, implementieren Sie einen Wrapper oder das Strategy-Pattern. So können Sie per Umgebungsvariable zwischen Providern umschalten.

interface EmailProvider { send(payload: EmailPayload): Promise<void>; } class SendGridProvider implements EmailProvider { async send(payload: EmailPayload) { // SendGrid specific implementation } } class SendHQProvider implements EmailProvider { async send(payload: EmailPayload) { // SendHQ specific implementation } } const provider = process.env.EMAIL_PROVIDER === 'sendhq' ? new SendHQProvider() : new SendGridProvider();

Schritt 4: KI-Agenten und Idempotenz

Wenn KI-Agenten bei Ihnen E-Mails auslösen, besteht ein besonderes Risiko: Der Agent kann nach einem Timeout in eine Schleife geraten oder eine Anfrage mehrfach wiederholen, sodass der Nutzer zehn identische E-Mails erhält.

Das Senden einer E-Mail ist ein externer Seiteneffekt. Sie müssen Idempotenz implementieren. Ein Idempotenzschlüssel ist eine eindeutige Kennung im Header, die der API sagt: „Wenn du diesen Schlüssel schon gesehen hast, sende die E-Mail nicht erneut, sondern gib einfach die ursprüngliche Erfolgsantwort zurück.“

Agentenfähige Implementierung:

{ "headers": { "Idempotency-Key": "order_123_welcome_email" }, "body": { "to": "customer@example.com", "template_id": "order-confirmation" } }

Implementieren Sie außerdem für riskante Agentenaktionen (etwa das Senden einer Passwort-Zurücksetzung oder einer Abrechnungswarnung) einen Freigabeschritt mit Human-in-the-Loop oder ein striktes Rate-Limit pro Nutzer-ID, damit Halluzinationen von Agenten Ihre Kunden nicht mit Spam überhäufen.

Schritt 5: Testen und Validieren

Gehen Sie diese Checkliste durch, bevor Sie die Umgebungsvariable auf den neuen Provider umstellen:

• DNS-Propagierung: Prüfen Sie mit einem Tool wie dig oder einem webbasierten Checker, ob Ihre neuen DKIM- und SPF-Einträge aktiv sind.
• Webhook-Prüfung: Wenn Sie auf Zustell-Events (delivered, opened, clicked) angewiesen sind, aktualisieren Sie Ihre Webhook-Endpunkte. Das Event-Format von SendGrid unterscheidet sich von anderen. Stellen Sie sicher, dass Ihr Endpunkt das neue JSON-Schema verarbeiten kann, ohne abzustürzen.
• Fehlerbehandlung: Testen Sie, wie Ihre Anwendung mit Provider-spezifischen Fehlern umgeht. Ein 429 (Too Many Requests) sollte zum Beispiel eine Backoff-Strategie auslösen, während ein 400 (Bad Request) meist auf eine fehlerhafte E-Mail-Adresse hinweist, die in Ihrer Datenbank als Bounce markiert werden sollte.

Typische Fehlerfälle zum Testen

1. Ungültiges E-Mail-Format: Stellen Sie sicher, dass die API einen klaren Fehler zurückgibt und Ihr Code nicht endlos wiederholt.
2. Rate-Limiting: Simulieren Sie einen Schwall von E-Mails, um zu sehen, ob Ihre Warteschlange mit den Limits des Providers zurechtkommt.
3. Große Anhänge: Prüfen Sie die maximale Payload-Größe des neuen Providers. Manche begrenzen auf 10MB, andere auf 25MB.

Checkliste für die Migration im Überblick

• Sperrliste exportieren: CSV-Export aus SendGrid.
• DNS-Einträge einrichten: SPF-, DKIM- und DMARC-Alignment.
• Templates migrieren: HTML/CSS in das neue Format konvertieren.
• API-Logik aktualisieren: Provider-Wrapper implementieren.
• Idempotenz hinzufügen: Unverzichtbar für KI-Agent-Trigger.
• Webhooks testen: Event-Zustellung und Parsing prüfen.
• Traffic umschalten: ENV-Variable aktualisieren und Logs überwachen.

Abschließende Gedanken zur Zustellbarkeit

Ein Provider-Wechsel ist ein guter Anlass, Ihre Versandgewohnheiten zu überprüfen. Denken Sie daran: Die Annahme durch den Provider ist nur die erste Hürde. Die Zustellung hängt davon ab, dass der empfangende ISP (Gmail, Outlook usw.) die Verbindung annimmt. Die Platzierung im Posteingang ist die letzte Hürde; sie hängt von der langfristigen Reputation Ihrer Domain und den Interaktionsraten Ihrer Empfänger ab.

Widerstehen Sie der Versuchung, diese APIs für unerwünschte Massen-E-Mails zu nutzen. Das ist nicht nur oft illegal, sondern führt auch unabhängig vom gewählten Provider zur Sperrung Ihres Kontos. Beschränken Sie sich auf transaktionale Kommunikation und E-Mails mit Einwilligung, um einen gesunden Sender Score zu behalten.

Teams, die KI-native Anwendungen bauen, sollten auf Provider mit Agent-Readiness-Funktionen wie MCP-Servern und llms.txt-Dateien achten, damit die Integration reibungslos gelingt. SendHQ ist genau für diesen Workflow gebaut und stellt die Infrastruktur bereit, die moderne Produktteams brauchen.

Mehr zum Aufbau zuverlässiger E-Mail-Systeme erfahren Sie unter https://sendhq.cc.