Una migrazione dell'email con dominio da cPanel trasferisce le caselle da un hosting cPanel in pacchetto (Bluehost, HostGator, Hostinger o simili) a un provider specializzato senza perdere posta in entrata durante il passaggio. La chiave è la ricezione parallela: configurare il nuovo provider mentre quello precedente continua a ricevere, quindi modificare i record MX con un TTL DNS basso, affinché la finestra di transizione duri minuti anziché ore.
La maggior parte delle guide alla migrazione da cPanel omette la ricezione parallela e descrive un passaggio a freddo che può perdere messaggi durante la propagazione DNS. Un passaggio a freddo perde in genere 10-50 messaggi, in base al volume in entrata. L'approccio parallelo seguente mira a evitare questa perdita. La configurazione aggiuntiva richiede 30 minuti e contribuisce a proteggere quei messaggi.
Questa guida presenta il passaggio in sei fasi con blocchi di codice per i record DNS. Per una panoramica più ampia, consulta spostare l'email su un nuovo provider.
Perché una migrazione cPanel pulita è importante
Una migrazione pulita è importante perché la posta in transito durante la propagazione DNS rappresenta un rischio concreto per i ricavi. Un passaggio a freddo con propagazione di diverse ore perde tutto ciò che arriva al vecchio MX dopo che ha smesso di accettare messaggi. La maggior parte dei responsabili ne comprende il costo solo quando un cliente si lamenta.
L'approccio in sei fasi evita la finestra di perdita grazie alla ricezione parallela: vecchio e nuovo provider ricevono simultaneamente durante il passaggio e il responsabile avvia manualmente la disattivazione soltanto dopo aver verificato che tutta la posta in transito sia arrivata. La disciplina aggiuntiva richiede 30 minuti di configurazione e può evitare una perdita difficile da quantificare.
Il passaggio in sei fasi in sintesi
Sei fasi coprono la migrazione da cPanel con ricezione parallela. L'ordine è importante: il risultato di ogni fase rende possibile quella successiva. Il tempo complessivo è di circa una settimana, dalla riduzione del TTL alla disattivazione completa; il lavoro attivo è di circa 3-4 ore distribuite nel corso della settimana.
- Riduci il TTL DNS con 48 ore di anticipo. Diminuisce il tempo di propagazione dell'MX da ore a minuti durante il passaggio.
- Predisponi le caselle presso il nuovo provider. Crea caselle corrispondenti nel nuovo servizio mantenendo attive quelle precedenti.
- Copia lo storico tramite IMAP. Uno strumento di migrazione IMAP lato server copia i messaggi esistenti dalle vecchie caselle a quelle nuove.
- Modifica i record MX. Aggiorna il DNS affinché punti al nuovo provider; entrambi ricevono durante la propagazione.
- Verifica autenticazione e percorso completo. Conferma che SPF, DKIM e DMARC superino i controlli presso tre destinatari dal nuovo provider.
- Disattiva le vecchie caselle. Attendi 48-72 ore dopo la modifica dell'MX, quindi disattivale quando la posta in transito è arrivata.
Ogni fase è un punto di controllo; tornare indietro in qualsiasi fase fino alla fase 4 è semplice. Dopo la fase 4, la modifica dell'MX, il ripristino è ancora possibile ma diventa costoso sul piano operativo, perché i messaggi iniziano ad accumularsi presso il nuovo provider. Un passaggio standard non dovrebbe richiedere il ripristino se le fasi 1-3 sono state eseguite correttamente.
Fase 1: ridurre il TTL DNS con 48 ore di anticipo
Riduci il TTL DNS dei record MX esistenti 48 ore prima del passaggio pianificato. Il TTL predefinito è solitamente 3600 secondi (1 ora) oppure 86400 (24 ore). Impostalo su 300 secondi (5 minuti), affinché la modifica dell'MX nella fase 4 si propaghi in minuti anziché ore.
La modifica si effettua nel pannello dell'host DNS. Cambia il valore TTL di ogni record MX in 300 e salva. Attendi 48 ore perché il TTL corrente scada e il nuovo valore basso si propaghi. Dopo la fase 6, riporta il TTL a 3600 per il funzionamento normale. Esempio di modifica di un record DNS in Cloudflare:
; before: MX record with default TTL
yourcompany.com. 3600 IN MX 10 mail.oldhost.example.com.
; after: MX record with low TTL for migration window
yourcompany.com. 300 IN MX 10 mail.oldhost.example.com.
Fase 2: predisporre le caselle presso il nuovo provider
Predisponi caselle corrispondenti presso il nuovo provider. Aggiungi il dominio a TrekMail, verificane la proprietà tramite il record TXT e crea una casella per ogni indirizzo presente sul vecchio hosting cPanel. A questo punto le nuove caselle sono pronte, ma l'MX punta ancora al vecchio provider.
Genera i valori SPF, DKIM e DMARC forniti dal nuovo provider. Non pubblicarli ancora; ciò avviene nella fase 4 insieme alla modifica dell'MX. Generarli in anticipo garantisce che i valori siano pronti quando arriva la fase 4. Questa predisposizione rende possibile la successiva ricezione parallela. Consulta migrazione IMAP per i dettagli dello strumento.
Fase 3: copiare lo storico tramite IMAP
Usa lo strumento di migrazione IMAP del nuovo provider per copiare la posta storica dalle vecchie caselle cPanel a quelle nuove. Lo strumento lato server di TrekMail (Starter e piani superiori) gestisce l'operazione dal pannello: fornisci le credenziali IMAP del vecchio hosting e lascia che copi cartella per cartella nell'arco di alcune ore.
La migrazione viene eseguita in background mentre l'MX punta ancora al vecchio provider. Quest'ultimo continua a ricevere i nuovi messaggi; il nuovo possiede la copia storica. Al termine, entrambi hanno la stessa struttura di cartelle e gli stessi messaggi, esattamente lo stato necessario per il passaggio con ricezione parallela della fase 4. Consulta lista di controllo per la migrazione email come piano operativo strutturato.
Fase 4: modificare i record MX
La quarta fase aggiorna i record MX presso l'host DNS affinché puntino al nuovo provider di caselle. Pubblica i nuovi valori MX insieme ai record SPF, DKIM e DMARC della fase 2. La propagazione DNS richiede circa 5 minuti grazie al TTL basso della fase 1. Durante la finestra di propagazione, entrambi i provider ricevono in parallelo.
; new MX records pointing at TrekMail
yourcompany.com. 300 IN MX 10 mx1.trekmail.net.
yourcompany.com. 300 IN MX 20 mx2.trekmail.net.
; published SPF, DKIM, DMARC TXT records
yourcompany.com. 300 IN TXT "v=spf1 include:_spf.trekmail.net ~all"
trekmail._domainkey.yourcompany.com. 300 IN TXT "v=DKIM1; k=rsa; p=..."
_dmarc.yourcompany.com. 300 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourcompany.com"
La finestra di ricezione parallela evita il consueto intervallo di perdita. Tutto ciò che viene inviato durante la propagazione arriva al vecchio provider, ancora attivo, oppure al nuovo, appena attivato, invece di rimbalzare in uno spazio tra i due. Mantieni le vecchie caselle attive e accessibili per almeno 48 ore dopo la modifica dell'MX, così da raccogliere gli ultimi messaggi in transito.
Fase 5: verificare autenticazione e percorso completo
Verifica l'autenticazione della posta in uscita dal nuovo provider. Invia messaggi di prova da ogni nuova casella ad account Gmail, Outlook.com e Yahoo. Conferma che le intestazioni riportino SPF=PASS, DKIM=PASS e DMARC=PASS presso tutti e tre. Qualsiasi FAIL indica che i record pubblicati nella fase 4 devono essere corretti prima di considerare completato il passaggio.
Verifica anche che la posta arrivi correttamente al nuovo provider. Invia un messaggio di prova da un indirizzo esterno a una nuova casella e conferma che compaia nella nuova posta in arrivo entro pochi minuti. Se arriva al vecchio provider, la propagazione DNS non è ancora terminata; attendi altri 10-15 minuti e ripeti la prova.
Fase 6: disattivare le vecchie caselle
Disattiva le vecchie caselle 48-72 ore dopo la modifica dell'MX. A quel punto la propagazione DNS dovrebbe essere completa a livello globale e i mittenti non dovrebbero più instradare i messaggi verso il vecchio MX. Disattiva le caselle dal pannello cPanel; mantieni attivo il piano cPanel per il sito web, se necessario, ma disabilita la ricezione della posta.
Se cPanel ospita anche il sito e non vuoi continuare a pagare il servizio, questo è il momento di migrare il sito verso un hosting web separato. La migrazione dell'email da cPanel è completata quando la vecchia posta è disattivata e il nuovo provider riceve correttamente da diversi giorni. Riporta il TTL DNS a 3600 secondi per il funzionamento normale.
Passaggi successivi
La migrazione da cPanel con ricezione parallela richiede circa una settimana di tempo complessivo e 3-4 ore di lavoro attivo. L'obiettivo è evitare la perdita di messaggi e ottenere un passaggio pulito a un provider specializzato, con un'autenticazione corretta per ogni messaggio in uscita.
Il modello di migrazione in sei fasi è ripetibile: applicalo nello stesso modo a ogni dominio cPanel aggiuntivo e il processo diventerà più rapido a ogni iterazione.
Prova gratuitamente TrekMail Nano su trekmail.net/pricing, senza carta. Starter, a $4/mese, include lo strumento di migrazione IMAP lato server necessario per la fase 3. La piattaforma assume le attività operative di hosting delle caselle che i provider cPanel lasciavano gestire direttamente a te nella configurazione in pacchetto.
Una nota operativa: la finestra di ricezione parallela nella fase 4 è la ragione strutturale per cui questo approccio mira a non perdere messaggi. I passaggi a freddo ne perdono perché esiste un intervallo tra l'arresto del vecchio provider e l'inizio della ricezione globale da parte del nuovo, durante il quale i messaggi rimbalzano. La ricezione parallela elimina l'intervallo mantenendo attivi entrambi durante la propagazione.
La migrazione da cPanel è spesso più semplice sul piano operativo di quanto molti responsabili si aspettino. Il timore che la posta smetta di funzionare può ritardare lo spostamento per mesi, mentre si accumula il costo di recapito del provider cPanel in pacchetto. L'approccio in sei fasi riduce il rischio di perdita che causa quel ritardo, perciò chi esegue una migrazione tende a esitare meno nel ripeterla per altri domini.
Per chi gestisce più domini personalizzati presso hosting cPanel, il modello si applica a ogni dominio: le stesse sei fasi con voci DNS differenti. Pianifica i passaggi in giorni distinti anziché contemporaneamente. L'attenzione richiesta durante ogni migrazione è limitata ma reale; passaggi consecutivi creano un carico cognitivo inutile e aumentano la probabilità di saltare una fase.
