Die Einschränkungen des Cloudflare-E-Mail-Routings, die im Tutorial nicht erwähnt werden

Das Tutorial „No Cloudflare Email Routing“ erklärt zunächst, was der Dienst nicht kann. Sie zeigen die Konfiguration in fünf Schritten an, bestätigen, dass die E-Mail ihr Ziel erreicht hat, und schließen. Ausgelassen werden die Fälle, in denen die Weiterleitung beginnt, legitime Nachrichten abzulehnen, Catch-All zu einem Spam-Tap wird oder Worker Client-E-Mails verwirft, weil eine Codezeile eine Ausnahme ausgelöst hat. Diese Fälle existieren, sie sind vorhersehbar und es lohnt sich, sie zu kennen, bevor der Dienst für etwas Kritisches in Betrieb genommen wird.

Der Versand per Domain existiert hier nicht

Der wichtigste und am häufigsten missverstandene Punkt: E-Mail-Routing empfängt E-Mails. Nur. Es gibt keine Möglichkeit, über diesen Dienst eine Nachricht von voce@seudominio.com zu senden. Wenn Sie eine Weiterleitung einrichten und Ihnen jemand eine E-Mail an contato@seudominio.com sendet, erhalten Sie diese in Gmail. Wenn Sie in Gmail antworten, ist der Absender, den der Empfänger sieht, Ihre Gmail-Adresse – nicht Ihr Domain-Alias.

Um E-Mails über Ihre eigene Domain zu versenden, benötigen Sie einen separaten Dienst: Resend, SendGrid, Mailgun, Amazon SES, Postmark, Brevo. Für jeden davon sind eigene DNS-Einträge erforderlich – SPF und DKIM, die für den ausgewählten Anbieter spezifisch sind. Cloudflare konfiguriert SPF-Einträge automatisch für eingehende Daten, hat jedoch nichts mit den Datensätzen zu tun, die ein ausgehender Anbieter benötigt. Wer die beiden Flüsse in derselben DNS-Konfiguration mischt, erhält Authentifizierung-Fehler in beide Richtungen.

Das Zustellbarkeitsproblem bei Weiterleitung und DMARC

Wenn Cloudflare eine E-Mail weiterleitet, leitet es die Nachricht von seinen eigenen Servern weiter – nicht von den ursprünglichen Servern des Absenders. Dies führt zu Spannungen mit DMARC, die bestimmte, aber wichtige Fälle betreffen.

Wenn der ursprüngliche Absender über eine DMARC-Richtlinie mit p=reject verfügt – was bei Banken, großen Unternehmen und E-Mail-Anbietern wie Gmail und Outlook üblich ist – und die E-Mail über Cloudflare weitergeleitet wird, erhält der endgültige Zielserver eine Nachricht, deren Header From: die Domäne des ursprünglichen Absenders anzeigt, deren sendende IP jedoch zu Cloudflare gehört. Die DMARC-Ausrichtung schlägt fehl, weil SPF die sendende IP (Cloudflare) mit der Domäne auf From: (der Bank, dem Unternehmen) vergleicht und sie nicht abgeglichen werden.

Cloudflare verwendet bei der Weiterleitung ARC (Authenticated Received Chain), wodurch die Authentifizierungsinformationen des ursprünglichen Hops erhalten bleiben. Dies verbessert die Situation für Anbieter, die ARC verstehen und respektieren – Microsoft, Google eingeschlossen. Aber es ist nicht universell. Einige Unternehmens-E-Mail-Server mit strengeren Richtlinien lehnen weitergeleitete E-Mails auch mit ARC immer noch ab. Das praktische Ergebnis: Sie verpassen möglicherweise legitime E-Mails, die von strengen p=reject-Domänen gesendet werden, und Cloudflare hat keine Kontrolle über die Empfangsrichtlinien des Zielservers.

Für dieses Problem gibt es im Rahmen des E-Mail-Routings keine vollständige Lösung. Wer eine garantierte Zustellung an alle möglichen Absender benötigt, braucht eine Lösung mit eigenem Posteingang – Google Workspace, Fastmail, Microsoft 365.

Catch-all und der damit verbundene Spam

Die Aktivierung von Catch-All *@seudominio.com ist nützlich: Jede Adresse, die Sie in Formularen, Newslettern und Veranstaltungen angeben, landet im selben Posteingang, ohne dass im Voraus Aliase erstellt werden müssen. Das Problem besteht darin, dass Spammer Domänen scannen und versuchen, E-Mails an zufällige Adressen zuzustellen. Wenn Catch-All aktiv ist, landet jeder Versuch in Ihrem Posteingang.

Eine Domain mit einer gewissen Präsenz im Web kann täglich Hunderte von E-Mails an Adressen erhalten, die es nie gegeben hat – info@, admin@, noreply@, sales@, zufällige Variationen. Alle kommen. Gmail verfügt über Spamfilter, aber die Lautstärke verursacht Lärm.

Die Abhilfe beim E-Mail-Routing selbst besteht darin, das Catch-All an einen E-Mail-Worker und nicht direkt an eine Zieladresse weiterzuleiten. Der Worker kann prüfen, ob die Zieladresse einer der von Ihnen definierten legitimen Aliase ist, alles ablehnen, was nicht übereinstimmt, und nur den Rest weiterleiten. Sie behalten die umfassende Flexibilität, ohne den ganzen Müll zu akzeptieren.

Der Arbeiter, der E-Mails in der Produktion verwirft

E-Mail-Worker haben ein Verhalten, das Entwickler überrascht: Wenn der Worker eine nicht abgefangene Ausnahme auslöst, wird die Nachricht mit einem 5xx-Fehler abgelehnt. Es gibt keinen erneuten Versuch, keine Warteschlange, keinen toten Brief. Die E-Mail verschwindet.

Stellen Sie sich einen Mitarbeiter vor, der einen POST an eine externe API sendet, um ein Support-Ticket zu erstellen. Die externe API ist ausgefallen. Der Worker gibt einen Netzwerkfehler aus. Die E-Mail des Kunden mit der Bitte um Support wird abgelehnt – und das erfahren Sie erst, wenn der Kunde es erneut versucht und sich beschwert.

Das richtige Muster besteht darin, die gesamte Verarbeitungslogik in einen Try/Catch zu packen und in Catch message.forward() aufzurufen, um eine manuelle Sortieradresse zu erhalten. Die E-Mail geht nicht verloren und Sie können den Fehler bearbeiten, nachdem der externe Dienst zurückgekehrt ist. Ohne diesen Fallback führt jeder vorübergehende Fehler in einer Worker-Abhängigkeit zu einem E-Mail-Verlust.

Was ändert sich, wenn man über die Basisfälle hinausgeht?

Die einfache Weiterleitung einiger Aliase an Gmail- oder Fastmail-Adressen funktioniert zuverlässig und ohne Überraschungen. Beim Hinzufügen von Abhängigkeiten treten Probleme auf: Worker mit externen Aufrufen, die fehlschlagen können, Catch-All ohne Filterung, Szenarien mit Absendern, die DMARC eingeschränkt haben. In diesen Fällen ist der Service immer noch nützlich, erfordert jedoch, dass Sie die Fehleroberflächen verstehen und entsprechende Abhilfemaßnahmen entwickeln.