Come dovrebbe implementare Cloudflare Email Routing in sicurezza un team di prodotto?

Definisci il compito della posta in entrata e i confini di responsabilità

Inizia mettendo per iscritto il compito esatto della posta in entrata: quali domini e local part devono accettare posta, chi è responsabile di ogni destinazione, se un messaggio va inoltrato, elaborato da codice o scartato, e per quanto tempo si possono conservare le evidenze operative. Cloudflare Email Routing è un livello di instradamento della posta in entrata. Di per sé non crea un ticket di supporto, non stabilisce l'identità del mittente, non dimostra che la posta inoltrata sia arrivata a una persona e non garantisce il posizionamento nella casella di destinazione. Tieni separati questi stati applicativi successivi. Assegna un responsabile operativo per DNS, regole di instradamento, codice del Worker, verifica delle destinazioni, incidenti di sicurezza e rollback. Nel primo rollout usa alias dedicati come support@ o invoices@ invece di un catch-all. Una route ristretta riduce la raccolta accidentale, rende interpretabili i risultati dei test e limita l'impatto di una destinazione o di un ramo del Worker sbagliati.

Esegui l'onboarding del dominio senza trattare il DNS come un'installazione alla cieca

L'attuale documentazione di Cloudflare Email Service afferma che, per usare Email Routing, il dominio deve usare il DNS di Cloudflare. Il flusso di onboarding può aggiungere record MX per l'instradamento in entrata, oltre ai record TXT relativi a SPF e DKIM descritti dal prodotto. Esamina i record esatti proposti prima di applicarli. Fai prima un inventario di MX, SPF, DKIM, DMARC, caselle di posta, servizi di inoltro, token di verifica e deleghe di sottodominio esistenti. Sostituire i record MX cambia la destinazione delle nuove sessioni SMTP in entrata: coordina quindi una finestra di manutenzione e conserva i valori precedenti come riferimento per il rollback. Evita di creare più record TXT SPF sullo stesso nome proprietario. Dopo la modifica, interroga i resolver autoritativi e pubblici, poi testa la consegna da un account non correlato alla destinazione. Le stime di propagazione DNS non dimostrano che ogni mittente veda ora la stessa risposta, e una dashboard verde non dimostra un inoltro end-to-end.

Verifica le destinazioni prima di creare route attive

Cloudflare documenta gli indirizzi di destinazione come risorse a livello di account che devono essere verificate prima che le regole di instradamento possano usarle. La verifica è un importante confine anti-abuso: dimostra il controllo della casella in quel momento, ma non stabilisce un'autorizzazione aziendale continuativa né la corretta appartenenza al team. Registra nel tuo sistema il responsabile richiedente, lo scopo, la data di verifica e la data di revisione. Preferisci una destinazione controllata dal team all'indirizzo personale di un dipendente. Rimuovi tempestivamente le destinazioni degli utenti che hanno lasciato l'azienda e, prima di eliminarle, controlla quali regole dipendono da quell'indirizzo, perché Cloudflare documenta che eliminare una destinazione disattiva le route che la usano. Tratta le email di verifica come sensibili per la sicurezza e non cliccarle mai automaticamente né inoltrarle ad automazioni non attendibili. Per le modifiche in produzione, richiedi la revisione di una seconda persona nel tuo normale processo infrastrutturale, anche se la dashboard consente a un singolo operatore di salvare la regola.

Crea regole esplicite e comprendi la precedenza

Una regola di instradamento associa un pattern di indirizzo a una destinazione verificata oppure a un Worker. Cloudflare documenta tre azioni: invio a un indirizzo email, invio a un Worker e scarto (drop). Crea per prime le route più specifiche per local part, indica il responsabile nei registri delle modifiche e verifica che per ogni pattern esista una sola regola prevista. La documentazione avverte che, se più regole usano lo stesso pattern, solo la prima in elenco elabora la posta in arrivo. Non affidarti all'ordine visivo come regola di business informale; elimina invece l'ambiguità. Mantieni le regole di drop strettamente giustificate, perché l'eliminazione equivale intenzionalmente a una mancata consegna. Abilita il catch-all solo dopo averne elencato le conseguenze su privacy, volume di spam, errori di battitura e archiviazione. Un catch-all può raccogliere indirizzi che nessuno intendeva creare: dovrebbe quindi avere una destinazione o una policy del Worker dedicata, avvisi e un modo rapido per disattivarlo, invece di ricadere silenziosamente su una casella personale.

Usa il subaddressing in modo consapevole

Cloudflare documenta il plus addressing opzionale, conforme a RFC 5233. Se è abilitato, la posta per un indirizzo come user+detail@example.com può corrispondere alla regola base user@example.com, mantenendo il dettaglio nel destinatario del messaggio esposto al Worker e nei log. Questo può servire per tag di instradamento, identificatori di test o alias per singoli flussi, ma il dettaglio è testo controllato dal mittente. Non trattarlo come identità autenticata di un tenant, come autorizzazione o come segreto. Normalizzalo e limitane la lunghezza prima di usarlo come chiave di database, dimensione di una metrica o nome di una coda. Cloudflare documenta inoltre che una regola esplicita per il sottoindirizzo completo ha la precedenza sulla regola base. Testa sia il caso esplicito sia quello di fallback, così che una regola specifica aggiunta in seguito non cambi silenziosamente un flusso esistente. Evita di inserire dati personali o riservati nei plus tag, perché possono comparire in intestazioni, log, messaggi inoltrati, esportazioni del supporto e analytics.

Scegli un Worker solo per reali esigenze di elaborazione

Usa l'inoltro diretto quando il requisito è semplicemente un indirizzo verso una casella verificata. Instrada verso un Worker quando ti servono diramazioni controllate, ispezione dei messaggi, archiviazione, rifiuto, risposte o inoltri multipli. Il gestore email di Cloudflare espone mittente e destinatario di busta, intestazioni, uno stream MIME raw, la sua dimensione e metodi per inoltrare, rispondere o rifiutare. Mantieni il gestore ridotto: convalida prima la policy sui destinatari, applica limiti a messaggi e parsing, esegui le chiamate esterne tramite code con limiti di tempo dove possibile e definisci l'esito per ogni errore. Intestazioni, oggetti, nomi visualizzati, allegati, link e boundary MIME sono controllati da un potenziale attaccante. Per impostazione predefinita non registrare nei log corpi raw o indirizzi completi. Se il contenuto va conservato, cifralo, limita l'accesso per tenant e per job, definisci l'eliminazione ed esegui la scansione degli allegati fuori dal percorso di instradamento sincrono. Un'eccezione di parsing non deve mai sfociare in un inoltro o una risposta non previsti.

Implementa un unico percorso decisionale esplicito

Un gestore sicuro dovrebbe calcolare un'azione approvata prima di produrre effetti collaterali. Per esempio: associa il destinatario di busta esatto a un flusso configurato, rifiuta i destinatari sconosciuti, metti in coda un record di metadati limitato, poi inoltra solo a una destinazione verificata scelta dalla configurazione. Non accettare mai una destinazione da un'intestazione, dall'oggetto, da un plus tag o dal corpo del messaggio. Quando inoltri a più destinazioni, la documentazione sui limiti di Cloudflare indica che un Worker deve chiamare forward una volta per ogni destinazione verificata; decidi se un successo parziale è accettabile e registra ogni tentativo separatamente. Nei log usa un identificatore di correlazione interno stabile invece del contenuto del destinatario. Se il gestore può rispondere, segui gli attuali vincoli di Cloudflare sulle risposte e aggiungi una protezione dai loop. Una risposta non è una conferma da parte di un team umano. Se serve una presa in carico applicativa persistente, salva il ticket o l'evento prima di inviare una risposta automatica e riconcilia gli errori ambigui invece di promettere che il lavoro è stato creato.

Tratta inoltri e risposte come esiti con un ambito di evidenza preciso

Una chiamata riuscita a un metodo del Worker è un'evidenza sull'operazione della piattaforma, non sull'esito finale per l'utente. SMTP definisce il trasferimento tra sistemi, mentre filtri, inoltri, quarantena, regole della casella e lettura da parte di una persona restano al di fuori di quel passaggio. Modella separatamente stati come ricevuto da Cloudflare, Worker invocato, azione tentata, accettato dal server di destinazione, ritardato o fallito e record applicativo creato. Non etichettarli tutti come consegnati. Mantieni log strutturati e minimizzati per la privacy con identità della regola, revisione del Worker, azione, timestamp, identificatore di correlazione e risultato sintetico; conserva indirizzi completi o contenuti solo dove un'esigenza operativa documentata lo giustifica. Imposta avvisi su errori di invocazione, rifiuti per dimensione, volumi anomali del catch-all, pattern ripetuti di mittenti, errori di destinazione e variazioni improvvise del traffico. Invia di continuo messaggi di test controllati, ma non usare mai contenuti reali dei clienti come fixture di osservabilità.

Rispetta i limiti attuali della piattaforma e le modalità di errore

Cloudflare documenta attualmente limiti di Email Routing che includono 200 regole di instradamento per dominio, 200 indirizzi di destinazione per account, un limite di 25 MiB per la dimensione dei messaggi in entrata e i limiti standard di CPU e memoria dei Workers per i messaggi instradati tramite Worker. Considerali documentazione attuale del provider, non costanti permanenti. In fase di pianificazione leggi la pagina dei limiti aggiornata e imposta avvisi con largo anticipo rispetto al raggiungimento di una soglia. Messaggi MIME di grandi dimensioni possono esaurire memoria o CPU anche al di sotto del limite di dimensione grezzo della piattaforma, se decodificati senza cautela. Elabora in streaming o rifiuta i contenuti non necessari, limita il numero di allegati e sposta il parsing costoso in lavori asincroni limitati. Secondo la documentazione di instradamento di Cloudflare, rinominare un Worker può interromperne il binding di instradamento: includi quindi l'ispezione delle route nella verifica del deployment. Le invocazioni fallite dovrebbero essere visibili nei log dei Workers, ma i log da soli non permettono di rieseguire nulla. Decidi se un mittente debba ritentare via SMTP, se un operatore possa rieseguire in sicurezza un job applicativo e come evitare record duplicati a valle.

Testa rollout e rollback come un'unica modifica

Crea prima una route di staging o a basso rischio. Invia messaggi controllati da un account diverso dalla destinazione verificata, coprendo testo semplice, contenuto multipart, allegati previsti, plus addressing, local part sconosciute e input volutamente malformati entro limiti sicuri. Verifica risposte DNS, configurazione della dashboard, revisione del Worker, risultato dell'inoltro, record a valle e comportamento in termini di privacy. Poi testa i percorsi negativi: destinazione non verificata, regola disattivata, eccezione del Worker, messaggio troppo grande, consegna ripetuta e una regola che altrimenti ricadrebbe nel catch-all. Registra le evidenze attese per ogni fase. Prima di aumentare il traffico, prova la disattivazione della regola, il ripristino dei record MX precedenti se necessario, lo scollegamento del Worker e la comunicazione della posta ritardata o rifiutata. Esegui il rollback in caso di perdite di instradamento inspiegabili, esposizione tra tenant, fuga di contenuti, risposte inattese, archiviazione senza limiti o errori persistenti del Worker. Conserva snapshot della configurazione e risultati dei test senza trattenere il contenuto dei messaggi più a lungo del necessario.

Come si inserisce SendHQ

SendHQ supporta le email in entrata. Questa guida tratta Cloudflare Email Routing; segui la documentazione di ciascun servizio per la relativa configurazione e i relativi limiti.

Domande frequenti

Fonti

• Instradare le email — Cloudflare
• Regole e indirizzi di Email Routing — Cloudflare
• API Workers per le email instradate — Cloudflare
• Limiti di Cloudflare Email Service — Cloudflare
• RFC 5321: Simple Mail Transfer Protocol (SMTP) — RFC Editor
• RFC 5233: Sieve Email Filtering: Subaddress Extension — RFC Editor