Wie sollte ein Produktteam Cloudflare Email Routing sicher einführen?

Inbound-Aufgabe und Zuständigkeitsgrenzen festlegen

Halten Sie zuerst die genaue Inbound-Aufgabe schriftlich fest: Welche Domain und welche Local Parts sollen E-Mails annehmen, wem gehört jedes Ziel, soll eine Nachricht weitergeleitet, von Code verarbeitet oder verworfen werden, und wie lange dürfen betriebliche Belege aufbewahrt werden? Cloudflare Email Routing ist eine Routing-Schicht für eingehende E-Mails. Sie legt für sich genommen kein Support-Ticket an, stellt keine Absenderidentität fest, belegt nicht, dass eine weitergeleitete E-Mail einen Menschen erreicht hat, und garantiert keine Platzierung im Postfach am Ziel. Halten Sie diese späteren Anwendungszustände getrennt. Benennen Sie einen betrieblich Verantwortlichen für DNS, Routing-Regeln, Worker-Code, Verifizierung der Zieladressen, Sicherheitsvorfälle und Rollback. Nutzen Sie beim ersten Rollout dedizierte Aliase wie support@ oder invoices@ statt eines Catch-all. Eine enge Route reduziert versehentliches Sammeln, macht Testergebnisse interpretierbar und begrenzt die Auswirkungen eines falschen Ziels oder eines fehlerhaften Worker-Zweigs.

Domain onboarden, ohne DNS als blinden Installationsschritt zu behandeln

Laut der aktuellen Dokumentation von Cloudflare Email Service muss die Domain für Email Routing Cloudflare DNS verwenden. Der Onboarding-Ablauf kann MX-Einträge für das Inbound-Routing sowie SPF- und DKIM-bezogene TXT-Einträge hinzufügen, die das Produkt beschreibt. Prüfen Sie die genau vorgeschlagenen Einträge, bevor Sie sie übernehmen. Inventarisieren Sie vorher bestehende MX-, SPF-, DKIM- und DMARC-Einträge, Postfächer, Weiterleitungsdienste, Verifizierungstokens und Subdomain-Delegierungen. Das Ersetzen von MX-Einträgen ändert, wohin neue eingehende SMTP-Sitzungen gehen. Stimmen Sie daher ein Wartungsfenster ab und bewahren Sie die bisherigen Werte als Rollback-Datensatz auf. Legen Sie unter einem Owner-Namen nicht mehrere SPF-TXT-Einträge an. Fragen Sie nach der Änderung autoritative und öffentliche Resolver ab und testen Sie dann die Zustellung von einem Konto aus, das mit dem Ziel nichts zu tun hat. Schätzungen zur DNS-Propagierung belegen nicht, dass jeder Absender jetzt dieselbe Antwort sieht, und ein grünes Dashboard belegt keine durchgängige Weiterleitung.

Zieladressen verifizieren, bevor Sie aktive Routen anlegen

Cloudflare dokumentiert Zieladressen als Ressourcen auf Kontoebene, die verifiziert sein müssen, bevor Routing-Regeln sie verwenden können. Der Verifizierungsschritt ist eine wichtige Grenze gegen Missbrauch: Er belegt die Kontrolle über das Postfach zu diesem Zeitpunkt, begründet aber keine fortlaufende geschäftliche Autorisierung und keine korrekte Teamzugehörigkeit. Erfassen Sie in Ihrem eigenen System den anfragenden Verantwortlichen, den Zweck, das Verifizierungsdatum und das Datum der nächsten Überprüfung. Bevorzugen Sie ein vom Team kontrolliertes Ziel gegenüber der persönlichen Adresse eines Mitarbeiters. Entfernen Sie Ziele ausgeschiedener Nutzer zügig und prüfen Sie vor dem Löschen, welche Regeln von einer Adresse abhängen, denn laut Cloudflare deaktiviert das Löschen eines Ziels die Routen, die es verwenden. Behandeln Sie Verifizierungs-E-Mails als sicherheitskritisch und lassen Sie sie niemals automatisch anklicken oder in nicht vertrauenswürdige Automatisierung weiterleiten. Verlangen Sie für Produktivänderungen in Ihrem normalen Infrastrukturprozess eine Prüfung durch eine zweite Person, auch wenn das Dashboard selbst einem einzelnen Operator das Speichern der Regel erlaubt.

Explizite Regeln anlegen und die Rangfolge verstehen

Eine Routing-Regel verknüpft ein E-Mail-Muster entweder mit einer verifizierten Zieladresse oder mit einem Worker. Cloudflare dokumentiert drei Aktionen: an eine E-Mail-Adresse senden, an einen Worker senden und verwerfen. Legen Sie zuerst die spezifischsten Routen für Local Parts an, nennen Sie deren Verantwortlichen in den Änderungsprotokollen und stellen Sie sicher, dass es pro Muster nur eine beabsichtigte Regel gibt. Die Dokumentation warnt: Nutzen mehrere Regeln dasselbe Muster, verarbeitet nur die zuerst aufgeführte Regel eingehende E-Mails. Verlassen Sie sich nicht auf die sichtbare Reihenfolge als informelle Geschäftsregel, sondern beseitigen Sie die Mehrdeutigkeit. Begründen Sie Verwerfen-Regeln eng, denn Löschen bedeutet absichtliche Nichtzustellung. Aktivieren Sie Catch-all erst, nachdem Sie die Folgen für Datenschutz, Spam-Volumen, Tippfehler und Speicher aufgelistet haben. Ein Catch-all kann Adressen sammeln, die niemand anlegen wollte. Er sollte daher eine eigene Zieladresse oder Worker-Richtlinie, Alerts und einen schnellen Weg zum Deaktivieren haben, statt stillschweigend ein persönliches Postfach zu übernehmen.

Subadressierung bewusst einsetzen

Cloudflare dokumentiert optionale Plus-Adressierung gemäß RFC 5233. Ist sie aktiviert, kann eine E-Mail an eine Adresse wie user+detail@example.com der Basisregel für user@example.com entsprechen, wobei das Detail im Empfänger der Nachricht erhalten bleibt, den ein Worker und die Logs sehen. Das kann Routing-Tags, Test-IDs oder Aliase pro Workflow unterstützen, doch das Detail ist vom Absender kontrollierter Text. Behandeln Sie es nicht als authentifizierte Mandantenidentität, als Autorisierung oder als Geheimnis. Normalisieren und begrenzen Sie es, bevor Sie es als Datenbankschlüssel, Metrikdimension oder Name einer Warteschlange verwenden. Cloudflare dokumentiert außerdem, dass eine explizite Regel für die vollständige Subadresse Vorrang vor der Basisregel hat. Testen Sie sowohl den expliziten als auch den Fallback-Fall, damit eine später hinzugefügte spezifische Regel nicht stillschweigend einen bestehenden Workflow ändert. Vermeiden Sie personenbezogene oder vertrauliche Daten in Plus-Tags, da sie in Headern, Logs, weitergeleiteten Nachrichten, Support-Exporten und Analysen auftauchen können.

Einen Worker nur für echten Verarbeitungsbedarf wählen

Nutzen Sie die direkte Weiterleitung, wenn es nur darum geht, eine Adresse an ein verifiziertes Postfach zu leiten. Leiten Sie an einen Worker, wenn Sie kontrollierte Verzweigungen, Prüfung von Nachrichten, Speicherung, Ablehnung, Antworten oder mehrere Weiterleitungen brauchen. Der E-Mail-Handler von Cloudflare stellt Envelope-Absender und -Empfänger, Header, einen rohen MIME-Stream, dessen Größe sowie Methoden zum Weiterleiten, Antworten oder Ablehnen bereit. Halten Sie den Handler klein: Prüfen Sie zuerst die Empfängerrichtlinie, setzen Sie Grenzen für Nachrichten und Parsing durch, führen Sie externe Aufrufe nach Möglichkeit über zeitlich begrenzte Warteschlangen aus und definieren Sie das Ergebnis für jeden Fehler. Header, Betreffzeilen, Anzeigenamen, Anhänge, Links und MIME-Grenzen werden vom Angreifer kontrolliert. Protokollieren Sie standardmäßig weder rohe Nachrichtentexte noch vollständige Adressen. Müssen Inhalte gespeichert werden, verschlüsseln Sie sie, beschränken Sie den Zugriff nach Mandant und Job, legen Sie die Löschung fest und scannen Sie Anhänge außerhalb des synchronen Routing-Pfads. Eine Parsing-Exception darf nicht in eine unbeabsichtigte Weiterleitung oder Antwort münden.

Einen expliziten Entscheidungspfad umsetzen

Ein sicherer Handler sollte eine freigegebene Aktion berechnen, bevor er Nebenwirkungen auslöst. Ordnen Sie zum Beispiel den exakten Envelope-Empfänger einem konfigurierten Workflow zu, lehnen Sie unbekannte Empfänger ab, stellen Sie einen begrenzten Metadatensatz in eine Warteschlange und leiten Sie dann nur an eine verifizierte Zieladresse weiter, die aus der Konfiguration gewählt wird. Übernehmen Sie niemals ein Ziel aus einem Header, dem Betreff, einem Plus-Tag oder dem Nachrichtentext. Bei der Weiterleitung an mehrere Ziele muss ein Worker laut der Limits-Dokumentation von Cloudflare forward einmal pro verifizierter Zieladresse aufrufen. Entscheiden Sie, ob ein Teilerfolg akzeptabel ist, und erfassen Sie jeden Versuch einzeln. Verwenden Sie in Logs eine stabile interne Korrelations-ID statt Empfängerinhalten. Darf der Handler antworten, halten Sie sich an die aktuellen Antwortbeschränkungen von Cloudflare und bauen Sie einen Schleifenschutz ein. Eine Antwort ist keine Bestätigung durch ein menschliches Team. Ist eine dauerhafte Erfassung in der Anwendung nötig, speichern Sie das Ticket oder Event, bevor Sie eine automatische Antwort senden, und gleichen Sie unklare Fehler ab, statt zu versprechen, dass die Arbeit angelegt wurde.

Weiterleitungen und Antworten als Ergebnisse mit begrenzter Aussagekraft behandeln

Ein erfolgreicher Aufruf einer Worker-Methode belegt die Plattformoperation, nicht das endgültige Ergebnis für den Nutzer. SMTP definiert die Übertragung zwischen Systemen; späteres Filtern, Weiterleiten, Quarantäne, Postfachregeln und das Lesen durch Menschen liegen außerhalb dieses Hops. Modellieren Sie Zustände wie „von Cloudflare empfangen“, „Worker aufgerufen“, „Aktion versucht“, „Zielserver hat angenommen“, „verzögert oder fehlgeschlagen“ und „Anwendungsdatensatz angelegt“ getrennt. Bezeichnen Sie nicht alle als zugestellt. Führen Sie strukturierte, datensparsame Logs mit Regelidentität, Worker-Revision, Aktion, Zeitstempel, Korrelations-ID und grobem Ergebnis; speichern Sie vollständige Adressen oder Inhalte nur dort, wo ein dokumentierter betrieblicher Bedarf es rechtfertigt. Richten Sie Alerts ein für fehlgeschlagene Aufrufe, Ablehnungen wegen Größe, ungewöhnliches Catch-all-Volumen, wiederkehrende Absendermuster, Fehler am Ziel und plötzliche Traffic-Änderungen. Senden Sie laufend kontrollierte Testnachrichten als Stichprobe, verwenden Sie aber niemals echte Kundeninhalte als Fixture für die Observability.

Aktuelle Plattformlimits und Fehlerbilder beachten

Cloudflare dokumentiert derzeit Limits für Email Routing, darunter 200 Routing-Regeln pro Domain, 200 Zieladressen pro Konto, eine Größenbeschränkung von 25 MiB für eingehende Nachrichten sowie die üblichen CPU- und Speicherlimits von Workers für Nachrichten, die an einen Worker geleitet werden. Behandeln Sie diese Werte als aktuelle Provider-Dokumentation, nicht als dauerhafte Konstanten. Lesen Sie bei der Planung die aktuelle Limits-Seite und lösen Sie Alerts aus, lange bevor ein Limit erreicht wird. Große MIME-Nachrichten können Speicher oder CPU erschöpfen, auch unterhalb der rohen Größengrenze der Plattform, wenn sie unvorsichtig dekodiert werden. Streamen oder verwerfen Sie unnötige Inhalte, begrenzen Sie die Zahl der Anhänge und verlagern Sie aufwendiges Parsing in begrenzte asynchrone Verarbeitung. Laut der Routing-Dokumentation von Cloudflare kann das Umbenennen eines Workers seine Routing-Bindung brechen. Nehmen Sie die Prüfung der Routen daher in die Deployment-Verifizierung auf. Fehlgeschlagene Aufrufe sollten in den Workers-Logs sichtbar sein, doch Logs allein ermöglichen kein erneutes Abspielen. Legen Sie fest, ob ein Absender per SMTP erneut zustellen soll, ob ein Operator einen Anwendungsjob sicher erneut ausführen kann und wie doppelte nachgelagerte Datensätze verhindert werden.

Rollout und Rollback als eine Änderung testen

Legen Sie zuerst eine Staging-Route oder eine Route mit geringem Risiko an. Senden Sie kontrollierte Nachrichten von einem anderen Konto als der verifizierten Zieladresse und decken Sie dabei Plain Text, Multipart-Inhalte, erwartete Anhänge, Plus-Adressierung, unbekannte Local Parts und bewusst fehlerhafte Eingaben innerhalb sicherer Grenzen ab. Prüfen Sie DNS-Antworten, Dashboard-Konfiguration, Worker-Revision, Weiterleitungsergebnis, nachgelagerten Datensatz und Datenschutzverhalten. Testen Sie dann die Negativpfade: nicht verifizierte Zieladresse, deaktivierte Regel, Worker-Exception, übergroße Nachricht, wiederholte Zustellung und eine Regel, die sonst im Catch-all landen würde. Halten Sie für jede Stufe die erwarteten Belege fest. Üben Sie vor der Ausweitung des Traffics, die Regel zu deaktivieren, bei Bedarf die früheren MX-Einträge wiederherzustellen, den Worker zu lösen und verzögerte oder abgelehnte E-Mails zu kommunizieren. Rollen Sie zurück bei ungeklärtem Routing-Verlust, mandantenübergreifender Offenlegung, Abfluss von Inhalten, unerwarteten Antworten, unbegrenzter Speicherung oder anhaltenden Worker-Fehlern. Bewahren Sie Konfigurations-Snapshots und Testergebnisse auf, ohne Nachrichteninhalte länger als nötig zu speichern.

So passt SendHQ

SendHQ unterstützt eingehende E-Mails. Dieser Leitfaden behandelt Cloudflare Email Routing; folgen Sie für Einrichtung und Limits der Dokumentation jedes Dienstes.

Häufig gestellte Fragen

Quellen

• E-Mails routen — Cloudflare
• Regeln und Adressen für Email Routing — Cloudflare
• Workers API für geroutete E-Mails — Cloudflare
• Limits von Cloudflare Email Service — Cloudflare
• RFC 5321: Simple Mail Transfer Protocol — RFC-Editor
• RFC 5233: Sieve Email Filtering: Subaddress Extension — RFC-Editor