Dopo Cloudflare la posta non arriva più: cosa controllare, in ordine

È l'incidente più comune dell'intero passaggio a Cloudflare, e ha una firma riconoscibile: il sito va benissimo — anzi, va più veloce di prima — e la posta è morta. Nessun errore visibile, nessun avviso. Semplicemente non arriva più niente, e chi scrive all'azienda riceve un rimbalzo o, peggio, non riceve niente.

La causa è quasi sempre una delle due qui sotto, e in entrambi i casi si ripara in mezz'ora.

Perché succede

Quando si cambiano i nameserver, la zona DNS non si sposta: si ricostruisce. Cloudflare prova a leggere quella esistente e a copiarla, ma può copiare solo quello che il provider precedente espone pubblicamente, e alcuni pannelli espongono meno di quanto contengano.

Da quel momento il mondo chiede a Cloudflare dove sta la posta dell'azienda. Se Cloudflare non ha quel record, la risposta è "non c'è". Non è un guasto: è una zona incompleta che risponde con sicurezza.

Controllo 1: i record MX ci sono?

È la prima cosa da guardare, prima di qualunque teoria.

Nella zona DNS su Cloudflare devono comparire gli stessi record MX che c'erano prima del passaggio, con le stesse priorità. Se usi Google Workspace o Microsoft 365, quei record sono documentati dal provider e si ricopiano da lì. Se usi la posta dell'hosting, il record punta a un host del tuo fornitore e va recuperato dal pannello vecchio, non ricostruito a memoria.

Due errori frequenti in questo punto:

• manca del tutto un MX secondario. La posta funziona a intermittenza, il che è peggio che non funzionare, perché nessuno capisce il motivo;
• il record punta al dominio invece che all'host di posta. Sembra giusto e non lo è: mail.tuodominio.it e tuodominio.it sono due nomi diversi, e il secondo di solito porta al sito.

Controllo 2: la nuvoletta arancione

Questo è l'errore più insidioso, perché la zona sembra corretta.

In Cloudflare ogni record ha un'icona a forma di nuvola. Arancione significa "il traffico passa attraverso di noi": Cloudflare risponde al posto del tuo server e nasconde il suo indirizzo IP. Grigia significa "rispondi e basta", cioè DNS normale.

Il proxy arancione è pensato per il traffico web. Su tutto il resto fa danni:

• il record a cui puntano gli MX deve essere grigio. Se mail.tuodominio.it è in arancione, il mondo riceve un indirizzo di Cloudflare, che non è un server di posta. Nessuna consegna;
• i sottodomini usati da servizi esterni devono essere grigi: webmail, pannelli, endpoint di integrazioni, il record che il gestionale usa per spedire;
• i record TXT e i record di autenticazione non hanno nuvoletta, ma vanno comunque verificati: SPF, chiavi DKIM e il record DMARC sono TXT e sono esattamente i più facili da perdere in un'importazione parziale.

Regola pratica: arancione solo su ciò che serve un sito web. Tutto il resto grigio.

Controllo 3: quello che l'importazione perde sempre

Oltre agli MX e alle nuvolette, in una zona ricostruita mancano quasi sempre queste cose. Vale la pena guardarle una per una:

• il record SPF, senza il quale la posta in uscita comincia a finire in spam nel giro di ore;
• le chiavi DKIM, che stanno su sottodomini poco intuitivi e nessuno ricorda;
• il record DMARC, se c'era;
• i TXT di verifica di Google, Microsoft, Search Console e simili: la loro assenza non rompe niente subito, ma un giorno un servizio si "sverifica" e nessuno collega la causa;
• il record autodiscover o le impostazioni automatiche del client di posta, senza cui Outlook smette di configurarsi da solo;
• i CNAME dei servizi esterni: newsletter, fatturazione, tracciamento delle spedizioni.

Come si ripara adesso

1. Recupera la zona vecchia. Se il pannello precedente è ancora accessibile, esportala. Se non lo è, i record si possono interrogare uno per uno, e i backup pubblici del DNS aiutano.
2. Confronta riga per riga con la zona attuale su Cloudflare. Non a occhio: affiancate.
3. Rimetti gli MX con le priorità originali e porta in grigio tutto ciò che non è web.
4. Verifica con un invio vero, da un indirizzo esterno verso l'azienda e viceversa. I test automatici dicono se un record esiste; solo un'email dice se arriva.
5. Aspetta la propagazione, che dipende dai TTL impostati prima del cambio. Se erano alti, ci vorrà più del previsto: è il motivo per cui si abbassano prima di una migrazione, non dopo.

E le email arrivate mentre era rotto?

Dipende da chi le ha mandate. Un server serio non butta via un messaggio al primo tentativo fallito: lo mette in coda e riprova per giorni. Quindi buona parte della posta arriva da sola una volta rimessi i record.

Quello che non torna sono i messaggi rifiutati in modo definitivo e quelli mandati da sistemi che non riprovano — moduli web, notifiche automatiche, alcune piattaforme di fatturazione. Per questi vale la pena avvisare i contatti principali, invece di sperare.

Il modo per non arrivarci

Il passaggio a Cloudflare è un'ottima idea: DNS veloce, HTTPS gestito, cache e protezione inclusi. Non è l'idea a essere sbagliata, è la sequenza.

L'ordine che non fa danni è: esportare la zona, abbassare i TTL un giorno prima, ricostruire e confrontare, mettere in grigio ciò che non è web, cambiare i nameserver fuori orario, e verificare la posta subito dopo, non il giorno dopo.

Se la posta è ferma adesso e preferisci che qualcuno guardi la zona invece di provare a indovinare, la configurazione e assistenza Cloudflare è esattamente questo lavoro — e se il problema si rivela più profondo del passaggio, si continua sulla posta aziendale.