Le limitazioni del routing e-mail di Cloudflare che il tutorial non menziona

Il tutorial No Cloudflare Email Routing inizia spiegando cosa non fa il servizio. Mostrano la configurazione in cinque passaggi, confermano che l'e-mail è arrivata a destinazione e si chiudono. Ciò che viene escluso sono i casi in cui l'inoltro inizia a rifiutare messaggi legittimi, il catch-all diventa un tocco di spam o Worker elimina l'e-mail del client perché una riga di codice ha generato un'eccezione. Questi casi esistono, sono prevedibili e vale la pena conoscerli prima di mettere in produzione il servizio per qualcosa di critico.

L'invio tramite dominio non esiste qui

Il punto più importante e spesso frainteso: l'email routing riceve la posta elettronica. Soltanto. Non è possibile inviare un messaggio da voce@seudominio.com utilizzando questo servizio. Quando imposti l'inoltro e qualcuno ti invia un'e-mail a contato@seudominio.com, la ricevi in Gmail. Quando rispondi in Gmail, il mittente che il destinatario vede è il tuo indirizzo Gmail, non il tuo alias di dominio.

Per inviare email tramite il proprio dominio è necessario un servizio separato: Resend, SendGrid, Mailgun, Amazon SES, Postmark, Brevo. Ognuno di questi richiederà i propri record DNS: SPF e DKIM specifici per il provider scelto. Cloudflare configura automaticamente i record SPF per quelli in entrata, ma non ha nulla a che fare con i record di cui avrà bisogno un provider in uscita. Chiunque mescoli i due flussi nella stessa configurazione DNS si ritrova con [errori di autenticazione in entrambe le direzioni.

Il problema della consegna con l'inoltro e DMARC

Quando Cloudflare inoltra un'e-mail, inoltra il messaggio dai propri server, non dai server originali del mittente. Ciò crea attriti con DMARC che riguardano casi specifici ma importanti.

Se il mittente originale ha una policy DMARC con p=reject (comune nelle banche, grandi aziende, provider di posta elettronica come Gmail e Outlook) e l'e-mail viene inoltrata tramite Cloudflare, il server di destinazione finale riceve un messaggio la cui intestazione From: mostra il dominio del mittente originale, ma il cui IP di invio appartiene a Cloudflare. L'allineamento DMARC fallisce perché SPF confronta l'IP di invio (Cloudflare) con il dominio su From: (la banca, l'azienda) e non si allineano.

Cloudflare utilizza ARC (Authenticated Received Chain) durante l'inoltro, che preserva le informazioni di autenticazione dall'hop originale. Ciò migliora la situazione per i fornitori che comprendono e rispettano ARC, inclusi Microsoft e Google. Ma non è universale. Alcuni server di posta elettronica aziendali con policy più rigorose continuano a rifiutare la posta elettronica inoltrata anche con ARC. Il risultato pratico: potresti perdere email legittime inviate da p=reject domini rigidi e Cloudflare non ha alcun controllo sulla politica di ricezione del server di destinazione.

Non esiste una soluzione completa per questo problema all'interno del routing della posta elettronica. Chi ha bisogno di una consegna garantita a tutti i possibili mittenti ha bisogno di una soluzione con una propria casella di posta: Google Workspace, Fastmail, Microsoft 365.

Tutto sommato e lo spam che ne deriva

Abilitare il catch-all *@seudominio.com è utile: qualsiasi indirizzo che fornisci nei moduli, nelle newsletter e negli eventi rientra nella stessa casella di posta senza dover creare alias in anticipo. Il problema è che gli spammer scansionano i domini cercando di consegnare la posta elettronica a indirizzi casuali. Con catch-all attivo, ogni tentativo arriva nella tua casella di posta.

Un dominio con una certa visibilità sul web può ricevere centinaia di email al giorno a indirizzi che non sono mai esistiti: info@, admin@, noreply@, sales@, variazioni casuali. Tutti arrivano. Gmail ha filtri antispam, ma il volume crea rumore.

La mitigazione all'interno del routing della posta elettronica stessa consiste nell'instradare il catch-all a un operatore di posta elettronica anziché direttamente a un indirizzo di destinazione. Il Worker può verificare se l'indirizzo di destinazione è uno degli alias legittimi che hai definito, rifiutare tutto ciò che non corrisponde e inoltrare solo il resto. Mantieni la flessibilità generale senza accettare tutta la spazzatura.

Il lavoratore che rilascia la posta elettronica in produzione

Gli Email Worker hanno un comportamento che coglie di sorpresa gli sviluppatori: se il Worker lancia un'eccezione non rilevata, il messaggio viene rifiutato con un errore 5xx. Non c'è nessun tentativo, non c'è coda, non c'è lettera morta. L'e-mail scompare.

Immagina un lavoratore che esegue il POST su un'API esterna per creare un ticket di supporto. L'API esterna è inattiva. Il Worker genera un errore di rete. L'e-mail del cliente che richiede supporto viene rifiutata e non lo scoprirai mai a meno che il cliente non riprovi e si lamenti.

Il modello corretto è racchiudere tutta la logica di elaborazione in un try/catch e, in catch, chiamare message.forward() per un indirizzo di ordinamento manuale. L'e-mail non viene persa ed è possibile elaborare ciò che non è riuscito dopo il ripristino del servizio esterno. Senza questo fallback, qualsiasi errore temporaneo in qualsiasi dipendenza Worker diventa un messaggio di posta elettronica perso.

Cosa cambia quando si va oltre i casi base

Il semplice inoltro di alcuni alias agli indirizzi Gmail o Fastmail funziona in modo affidabile e senza sorprese. I problemi compaiono quando si aggiungono dipendenze: lavoratori con chiamate esterne che possono fallire, catch-all senza filtraggio, scenari con mittenti che hanno limitato DMARC. In questi casi il servizio è comunque utile, ma richiede di comprendere le superfici di errore e creare soluzioni di mitigazione corrispondenti.