Hoe implementeert een productteam Cloudflare-e-mailroutering veilig?

Bepaal de taak voor inkomende mail en de verantwoordelijkheidsgrens

Begin met het precies vastleggen van de taak voor inkomende mail: welk domein en welke local parts mail moeten accepteren, wie eigenaar is van elke bestemming, of een bericht moet worden doorgestuurd, door code verwerkt of verwijderd, en hoe lang operationeel bewijs bewaard mag worden. Cloudflare Email Routing is een routeringslaag voor inkomende mail. Het maakt op zichzelf geen supportticket aan, stelt de identiteit van de afzender niet vast, bewijst niet dat doorgestuurde mail een mens heeft bereikt en garandeert geen plaatsing in de mailbox op de bestemming. Houd die latere applicatiestatussen gescheiden. Wijs een operationele eigenaar aan voor DNS, routeringsregels, Worker-code, verificatie van bestemmingen, beveiligingsincidenten en rollback. Gebruik bij de eerste uitrol aparte aliassen zoals support@ of invoices@ in plaats van een catch-all. Een smalle route vermindert onbedoeld verzamelen, maakt testuitkomsten interpreteerbaar en beperkt de impact van een verkeerde bestemming of Worker-tak.

Sluit het domein aan zonder DNS als blinde installatiestap te behandelen

Volgens de huidige documentatie van Cloudflare Email Service moet het domein Cloudflare DNS gebruiken voor Email Routing. Het aansluitproces kan MX-records voor inkomende routering toevoegen, plus SPF- en DKIM-gerelateerde TXT-records die het product beschrijft. Beoordeel de exact voorgestelde records voordat je ze toepast. Inventariseer eerst bestaande MX, SPF, DKIM, DMARC, mailboxen, doorstuurdiensten, verificatietokens en subdomeindelegaties. Het vervangen van MX-records verandert waar nieuwe inkomende SMTP-sessies terechtkomen, dus plan een onderhoudsvenster en bewaar de vorige waarden als rollbackrecord. Maak geen meerdere SPF-TXT-records aan voor één eigenaarnaam. Vraag na de wijziging gezaghebbende en publieke resolvers op en test daarna de bezorging vanaf een account dat niets met de bestemming te maken heeft. Schattingen van DNS-propagatie bewijzen niet dat elke afzender nu hetzelfde antwoord ziet, en een groen dashboard bewijst geen end-to-end doorsturen.

Verifieer bestemmingen voordat je actieve routes aanmaakt

Cloudflare documenteert bestemmingsadressen als resources op accountniveau die geverifieerd moeten zijn voordat routeringsregels ze kunnen gebruiken. De verificatiestap is een belangrijke grens tegen misbruik: hij toont aan dat je op dat moment de mailbox beheert, maar legt geen doorlopende zakelijke autorisatie of juist teamlidmaatschap vast. Registreer in je eigen systeem de aanvragende eigenaar, het doel, de verificatiedatum en de reviewdatum. Kies liever een bestemming die door een team wordt beheerd dan het persoonlijke adres van een medewerker. Verwijder bestemmingen van vertrokken gebruikers snel en controleer vóór het verwijderen welke regels van een adres afhangen, want volgens Cloudflare schakelt het verwijderen van een bestemming de routes uit die haar gebruiken. Behandel verificatiemails als beveiligingsgevoelig en laat ze nooit automatisch aanklikken of doorsturen naar onbetrouwbare automatisering. Vereis voor productiewijzigingen een review door een tweede persoon in je normale infrastructuurproces, ook als het dashboard zelf één operator toestaat de regel op te slaan.

Maak expliciete regels en begrijp de voorrang

Een routeringsregel koppelt een e-mailpatroon aan een geverifieerde bestemming of aan een Worker. Cloudflare documenteert drie acties: naar een e-mailadres sturen, naar een Worker sturen en verwijderen (drop). Maak eerst de meest specifieke routes voor local parts aan, noem hun eigenaar in de wijzigingsregistratie en controleer dat er per patroon maar één bedoelde regel is. De documentatie waarschuwt dat als meerdere regels hetzelfde patroon gebruiken, alleen de eerst vermelde regel inkomende mail verwerkt. Vertrouw niet op de visuele volgorde als informele bedrijfsregel; neem de dubbelzinnigheid weg. Houd drop-regels strikt verantwoord, want verwijderen betekent bewust niet afleveren. Schakel catch-all pas in nadat je de gevolgen voor privacy, spamvolume, typefouten en opslag in kaart hebt gebracht. Een catch-all kan adressen verzamelen die niemand bewust heeft aangemaakt, dus hij hoort een eigen bestemming of Worker-beleid te hebben, met meldingen en een snelle manier om hem uit te schakelen, in plaats van ongemerkt in een persoonlijke mailbox te belanden.

Gebruik subadressering bewust

Cloudflare documenteert optionele plus-adressering in lijn met RFC 5233. Als die aanstaat, kan mail voor een adres als user+detail@example.com matchen met de regel voor het basisadres user@example.com, terwijl het detail behouden blijft in de ontvanger die de Worker en de logs zien. Dat kan handig zijn voor routeringstags, test-ID's of aliassen per workflow, maar het detail is tekst die de afzender bepaalt. Behandel het niet als geauthenticeerde tenantidentiteit, autorisatie of geheim. Normaliseer en begrens het voordat je het als databasesleutel, metriekdimensie of wachtrijnaam gebruikt. Cloudflare documenteert ook dat een expliciete regel voor het volledige subadres voorrang heeft op de basisregel. Test zowel het expliciete als het fallbackgeval, zodat een latere specifieke regel niet ongemerkt een bestaande workflow verandert. Zet geen persoonlijke of vertrouwelijke gegevens in plus-tags, want die kunnen opduiken in headers, logs, doorgestuurde berichten, supportexports en analytics.

Kies alleen voor een Worker bij echte verwerkingsbehoeften

Gebruik direct doorsturen als de eis simpelweg één adres naar één geverifieerde mailbox is. Routeer naar een Worker als je gecontroleerde vertakkingen, inspectie van berichten, opslag, weigering, antwoorden of meerdere doorstuuracties nodig hebt. De e-mailhandler van Cloudflare geeft toegang tot de envelope-afzender en -ontvanger, headers, een ruwe MIME-stream en de grootte daarvan, plus methoden om door te sturen, te antwoorden of te weigeren. Houd de handler klein: valideer eerst het ontvangerbeleid, dwing limieten op berichten en parsing af, doe externe aanroepen waar mogelijk via tijdsbegrensde wachtrijen en definieer voor elke fout de uitkomst. Headers, onderwerpen, weergavenamen, bijlagen, links en MIME-grenzen worden door een aanvaller bepaald. Log standaard geen ruwe bodies of volledige adressen. Als inhoud moet worden opgeslagen, versleutel die dan, beperk de toegang per tenant en taak, leg verwijdering vast en scan bijlagen buiten het synchrone routeringspad. Een parseerfout mag nooit doorvallen naar een onbedoeld doorsturen of antwoord.

Implementeer één expliciet beslispad

Een veilige handler bepaalt een goedgekeurde actie voordat hij neveneffecten uitvoert. Koppel bijvoorbeeld de exacte envelope-ontvanger aan een geconfigureerde workflow, weiger onbekende ontvangers, zet een begrensd metadatarecord in de wachtrij en stuur daarna alleen door naar een geverifieerde bestemming die uit de configuratie komt. Accepteer nooit een bestemming uit een header, onderwerp, plus-tag of body van een bericht. Bij doorsturen naar meerdere bestemmingen moet een Worker volgens de limietendocumentatie van Cloudflare forward één keer per geverifieerde bestemming aanroepen; bepaal of gedeeltelijk succes acceptabel is en registreer elke poging apart. Gebruik in logs een stabiele interne correlatie-ID in plaats van ontvangerinhoud. Als de handler mag antwoorden, volg dan de actuele beperkingen van Cloudflare voor antwoorden en voeg lusbeveiliging toe. Een antwoord is geen bevestiging van een menselijk team. Als duurzame intake in de applicatie nodig is, sla het ticket of event dan op voordat je een automatisch antwoord stuurt, en reconcilieer dubbelzinnige fouten in plaats van te beloven dat er werk is aangemaakt.

Behandel doorsturen en antwoorden als uitkomsten met beperkte bewijskracht

Een geslaagde aanroep van een Worker-methode is bewijs over de platformbewerking, niet over de uiteindelijke uitkomst voor de gebruiker. SMTP definieert de overdracht tussen systemen, terwijl latere filtering, doorsturen, quarantaine, mailboxregels en het lezen door een mens buiten die stap vallen. Modelleer statussen zoals ontvangen door Cloudflare, Worker aangeroepen, actie geprobeerd, geaccepteerd door de bestemmingsserver, vertraagd of mislukt, en applicatierecord aangemaakt, elk afzonderlijk. Label ze niet allemaal als afgeleverd. Houd gestructureerde logs met zo min mogelijk persoonsgegevens bij, met regelidentiteit, Worker-revisie, actie, tijdstempel, correlatie-ID en een grof resultaat; sla volledige adressen of inhoud alleen op waar een gedocumenteerde operationele noodzaak dat rechtvaardigt. Stel meldingen in voor mislukte aanroepen, weigeringen vanwege grootte, abnormaal catch-all-volume, herhaalde afzenderpatronen, fouten bij bestemmingen en plotselinge veranderingen in verkeer. Stuur doorlopend gecontroleerde testberichten, maar gebruik nooit echte klantinhoud als testdata voor observability.

Houd rekening met de huidige platformlimieten en faalwijzen

Cloudflare documenteert momenteel limieten voor Email Routing, waaronder 200 routeringsregels per domein, 200 bestemmingsadressen per account, een limiet van 25 MiB voor inkomende berichten en de standaard CPU- en geheugenlimieten van Workers voor berichten die via een Worker worden gerouteerd. Behandel dit als actuele providerdocumentatie, niet als vaste constanten. Lees tijdens de planning de actuele limietenpagina en stel meldingen in ruim voordat je een limiet nadert. Grote MIME-berichten kunnen geheugen of CPU uitputten, zelfs onder de ruwe groottelimiet van het platform, als ze onvoorzichtig worden gedecodeerd. Stream of weiger onnodige inhoud, begrens het aantal bijlagen en plaats zware parsing achter begrensd asynchroon werk. Volgens de routeringsdocumentatie van Cloudflare kan het hernoemen van een Worker de routeringskoppeling breken, dus neem route-inspectie op in je deploymentverificatie. Mislukte aanroepen horen zichtbaar te zijn in de Workers-logs, maar logs alleen maken nog geen replay mogelijk. Bepaal of een afzender het via SMTP opnieuw moet proberen, of een operator een applicatiejob veilig opnieuw kan afspelen en hoe dubbele records verderop worden voorkomen.

Test uitrol en rollback als één wijziging

Maak eerst een staging-route of een route met laag risico aan. Stuur gecontroleerde berichten vanaf een ander account dan de geverifieerde bestemming, met plaintext, multipart-inhoud, verwachte bijlagen, plus-adressering, onbekende local parts en bewust misvormde invoer binnen veilige grenzen. Controleer DNS-antwoorden, de dashboardconfiguratie, de Worker-revisie, het doorstuurresultaat, het record verderop en het privacygedrag. Test daarna de negatieve paden: een niet-geverifieerde bestemming, een uitgeschakelde regel, een Worker-exceptie, een te groot bericht, herhaalde aflevering en een regel die anders in de catch-all zou vallen. Leg per fase het verwachte bewijs vast. Oefen voordat je het verkeer uitbreidt het uitschakelen van de regel, het zo nodig terugzetten van de eerdere MX-records, het loskoppelen van de Worker en het communiceren over vertraagde of geweigerde mail. Draai terug bij onverklaard routeringsverlies, blootstelling tussen tenants, lekken van inhoud, onverwachte antwoorden, onbegrensde opslag of aanhoudende Worker-fouten. Bewaar configuratiesnapshots en testresultaten zonder berichtinhoud langer dan nodig vast te houden.

Hoe SendHQ past

SendHQ ondersteunt inkomende e-mail. Deze gids behandelt Cloudflare Email Routing; volg de documentatie van elke dienst voor de eigen configuratie en limieten.

Veelgestelde vragen

Bronnen

• E-mails routeren — Cloudflare
• Routeringsregels en adressen voor e-mail — Cloudflare
• Workers API voor gerouteerde e-mail — Cloudflare
• Limieten van Cloudflare Email Service — Cloudflare
• RFC 5321: Simple Mail Transfer Protocol — RFC Editor
• RFC 5233: Sieve Email Filtering: Subaddress Extension — RFC Editor