Trasferire una casella email: guida al passaggio DNS

Come trasferire una casella a un nuovo provider: guida al passaggio DNS

Quando devi trasferire i dati di una casella tra provider email, la strategia DNS può fare la differenza tra un passaggio lineare e un'interruzione fino a 48 ore. Un TTL configurato male o un include SPF dimenticato può causare messaggi respinti e perdite commerciali.

Non c'è spazio per l'improvvisazione. Si tratta di una sequenza di operazioni tecniche precise. Questa guida spiega come trasferire il contenuto di una casella in sicurezza, gestendo i tempi di propagazione, unendo le identità di autenticazione SPF, DKIM e DMARC e instradando la posta verso il nuovo provider con il minor rischio possibile di perdere messaggi.

Per la migrazione dei dati, cioè lo spostamento effettivo delle email, consulta la guida alla sincronizzazione IMAP.

Perché la propagazione DNS non è immediata durante il trasferimento

Il DNS è un sistema di cache distribuito. Quando modifichi un record, dipendi da ogni resolver ricorsivo, dai server DNS degli operatori Internet al 8.8.8.8 di Google fino ai router locali, e dal modo in cui rispetta il valore Time-To-Live (TTL).

Se il TTL mantiene il valore comune di 86,400 secondi (24 ore), l'instradamento può rimanere diviso fino alla scadenza delle cache. Alcuni messaggi potrebbero arrivare nella nuova casella e altri in quella vecchia.

La coda lunga e la cache negativa

Due fattori poco visibili compromettono spesso il passaggio delle caselle:

• La coda lunga: anche con un TTL basso, si stima che tra l'1 e il 5% dei resolver globali ignori i valori inferiori a 60 minuti. Metti in conto del traffico residuo verso il vecchio provider per circa un'ora dopo il passaggio.
• Cache negativa (SOA): se interroghi un record prima che esista, per esempio un nuovo selettore DKIM troppo presto, la risposta NXDOMAIN viene conservata in base al TTL minimo del record SOA, spesso 1 ora. Il record valido può quindi restare invisibile fino alla scadenza della cache, anche dopo la pubblicazione.

Fase 1: il conto alla rovescia di 48 ore

Non modificare ancora i record MX. Prepara prima l'ambiente ad accettare il cambiamento.

Passaggio 1: abbassa i TTL (48 ore prima)

Individua i record MX, SPF (TXT) e DMARC. Riduci il loro TTL a 300 secondi (5 minuti).

In questo modo riduci la finestra di propagazione prevista. Al momento del passaggio definitivo, le cache che rispettano il TTL potranno aggiornarsi in circa 5 minuti anziché attendere fino a 24 ore.

Passaggio 2: unisci gli SPF (24 ore prima)

SPF (RFC 7208) autorizza gli indirizzi IP a inviare messaggi per tuo conto. Durante la transizione devi autorizzare entrambi i provider nello stesso momento.

Il problema: SPF consente al massimo 10 ricerche DNS. L'unione di due provider, per esempio Google Workspace e TrekMail, può superare questo limite.

La soluzione: semplifica il record. Sostituisci le istruzioni include: annidate con meccanismi ip4: diretti soltanto quando il provider pubblica indirizzi stabili e ne supporta la manutenzione.

Esempio di record per la transizione:

Se utilizzi un servizio SMTP esterno con TrekMail, come Amazon SES o SendGrid, includi invece i relativi record SPF.

Passaggio 3: pubblica DKIM in anticipo

DKIM utilizza dei selettori, per esempio google._domainkey. Genera le chiavi DKIM sul nuovo provider con un selettore univoco, come tm1._domainkey. Non riutilizzare mai il nome di un selettore. Puoi pubblicare quello nuovo con diversi giorni di anticipo senza creare conflitti con il vecchio provider.

Passaggio 4: rendi DMARC meno restrittivo

Se la policy DMARC è p=reject oppure p=quarantine, cambiala in p=none almeno 24 ore prima del passaggio. Nelle prime ore possono verificarsi errori di autenticazione. p=none consente di registrarli nei rapporti RUA senza richiederne il rifiuto tramite DMARC, ma il recapito dipende comunque dagli altri controlli del destinatario. La guida di Google alla configurazione DMARC spiega come impostare correttamente la policy.

Fase 2: eseguire il passaggio

I TTL sono bassi e l'autenticazione include entrambi i sistemi. È il momento di trasferire l'instradamento della casella al nuovo hosting.

Passaggio 1: confronta le risposte autoritative e ricorsive

Controlla che i nuovi record siano visibili sul nameserver autoritativo prima di verificarli tramite i resolver pubblici:

Passaggio 2: aggiorna i record MX

Aggiungi e verifica i nuovi MX prima di rimuovere quelli vecchi, oppure applica la modifica in modo atomico se il provider DNS lo consente. Per gli utenti TrekMail:

Mantieni il TTL a 300 secondi. Non aumentarlo ancora.

Passaggio 3: svuota la cache e verifica

Svuota la cache DNS locale con ipconfig /flushdns su Windows o sudo dscacheutil -flushcache su macOS. Esegui nuovamente dig. Questa operazione pulisce soltanto la cache locale, e i nuovi MX compariranno quando il resolver interrogato avrà aggiornato la propria.

Fase 3: stabilizzazione dopo il passaggio

Controlla gli errori di attribuzione del tenant (550 5.7.64)

È un errore comune quando si trasferisce l'hosting della casella a Microsoft 365 o a suite simili. Se la destinazione non ha ancora completato il provisioning del dominio nella directory interna, può rifiutare i messaggi con «Relay Access Denied». Assicurati che lo stato del dominio sia «Verified» o «Healthy» nella dashboard del nuovo provider prima di modificare gli MX.

Monitora i rapporti DMARC (72 ore)

Controlla i rapporti RUA per tre giorni:

• Esito positivo: il traffico proveniente dagli IP del nuovo provider supera i controlli SPF e DKIM.
• Errore: il traffico legittimo, proveniente per esempio da sistemi di fatturazione o piattaforme di marketing, non supera l'autenticazione. Aggiorna subito SPF o DKIM.

Pulizia (72 ore dopo)

Quando il traffico si è stabilizzato:

1. Rimuovi l'include: del vecchio provider dal record SPF.
2. Rimuovi i vecchi record DKIM CNAME/TXT soltanto dopo un intervallo sicuro per i messaggi che portano ancora le vecchie firme.
3. Riporta i TTL a 3,600s (1 ora) o 86,400s (24 ore).
4. Applica di nuovo DMARC con p=quarantine oppure p=reject.

Checklist sintetica per trasferire una casella

TrekMail semplifica il trasferimento delle caselle

La gestione manuale del DNS è soggetta a errori. Un solo errore di sintassi in un record TXT può invalidare l'intera policy SPF.

Per le piccole imprese

TrekMail offre un controllo dello stato DNS in tempo reale. La dashboard interroga i nameserver autoritativi e convalida i record MX, SPF e DKIM rispetto alla configurazione richiesta. Conferma la pubblicazione autoritativa, non la propagazione su tutti i resolver, e segnala gli errori di sintassi prima che possano causare messaggi respinti.

Scopri come configurare l'email sul tuo dominio.

Per le agenzie

Gestire più di 50 domini richiede uniformità. TrekMail permette di applicare un modello DNS coerente a tutti i tenant dei clienti. Nei piani Starter e Agency, il servizio SMTP gestito si occupa della reputazione IP e delle intestazioni di recapito, riducendo la necessità di una complessa semplificazione SPF o di programmi interni per il riscaldamento degli IP.

Scopri come funziona l'hosting email multidominio per le agenzie.

Tutti i piani a pagamento includono una prova gratuita di 14 giorni e richiedono una carta. Il piano Nano non richiede una carta.

Conclusione

Quando trasferisci una casella a un nuovo provider, il passaggio DNS è uno dei punti più delicati. Riduci i TTL in anticipo, unisci i record di autenticazione, modifica gli MX durante una finestra di manutenzione e monitora i rapporti DMARC per 72 ore. Questa è la procedura.

Se preferisci evitare la gestione manuale di molti record DNS, prova TrekMail gratuitamente e usa la dashboard per convalidare la configurazione.