Trasferire la posta a un nuovo provider senza interruzioni
Quando devi trasferire la posta sull'infrastruttura di un nuovo provider, non è detto che si verifichi un'interruzione di 24 ore durante la quale i messaggi vengono respinti o scompaiono. Il temuto «buco nero» si crea quando gli amministratori ignorano i tempi di propagazione DNS e cercano di fare tutto in una volta. Con un'esecuzione in parallelo, il vecchio sistema resta attivo mentre quello nuovo si sincronizza in background; il traffico viene spostato dopo aver riconciliato i due sistemi.
Questa guida illustra il piano di passaggio usato dagli amministratori per trasferire la posta in nuovi ambienti riducendo al minimo le interruzioni. Se vuoi approfondire la teoria della migrazione, consulta la nostra guida alla migrazione IMAP.
Perché il metodo «Big Bang» fallisce
L'approccio «Big Bang», cioè copiare tutto il venerdì sera, cambiare il DNS e sperare che funzioni, fallisce perché la velocità di trasferimento non è costante. La limitazione del traffico (errori HTTP 429) e i limiti di larghezza di banda possono bloccare una migrazione a metà. Arriva il lunedì mattina, metà delle caselle è vuota e l'assistenza viene sommersa dalle richieste.
La prassi professionale per trasferire la posta a un nuovo provider prevede un'esecuzione in parallelo. Si prepara il nuovo ambiente, si sincronizzano i dati storici in background e si aggiorna il DNS solo dopo aver riconciliato la destinazione con l'origine. Per capire come preservare la reputazione del mittente durante il passaggio, leggi quella guida prima di iniziare.
Le 4 fasi di una migrazione della posta
| Fase | Tempistica | Azione | Obiettivo |
|---|---|---|---|
| Preparazione | T-7 giorni | Sincronizzare tramite IMAP le email più vecchie di 30 giorni | Trasferire il 90% dello spazio occupato senza sovraccaricare la banda |
| Riduzione del TTL | T-48 ore | Ridurre il TTL di MX/SPF a 300 secondi | Ridurre la cache DNS per una finestra di passaggio prevista di 5 minuti |
| Passaggio | Momento zero (venerdì pomeriggio) | Aggiornare i record MX al nuovo provider | Instradare la nuova posta in arrivo verso il nuovo server |
| Sincronizzazione delta | T+1 ora | Sincronizzare gli elementi recenti (ultimi 30 giorni) | Recuperare la posta consegnata al vecchio server durante la transizione |
Fase 1: propagazione DNS e regola dei 300 secondi
L'instradamento diviso, in cui alcuni mittenti raggiungono il vecchio server e altri quello nuovo, è causato da valori TTL lunghi nei record DNS. I resolver ricorsivi conservano i record MX nella cache in base al TTL. Un TTL comune è 86,400 secondi (24 ore). Se cambi i record MX senza prima ridurlo, alcuni mittenti possono continuare a inviare la posta al vecchio server finché le rispettive cache rimangono valide. Chi vuole trasferire la posta a un nuovo provider deve quindi preparare prima il TTL.
La procedura è semplice: controlla il TTL attuale, riduci i TTL di MX e SPF a 300 secondi, quindi attendi almeno la durata del TTL originale prima di proseguire. Questo valore rappresenta solo un limite indicativo per le cache che rispettano il TTL, non una garanzia di propagazione globale. Saltando l'attesa, alcuni resolver conserveranno ancora i vecchi record.
La trappola delle 10 ricerche SPF
Durante la migrazione potresti voler aggiungere l'include SPF del nuovo provider accanto a quello precedente. Fai attenzione. La RFC 7208 limita SPF a 10 ricerche DNS. Accumulare più provider (Google + Outlook + nuovo provider) spesso supera questo limite, causando PermError e problemi di consegna. Appiattisci il record SPF solo se gli indirizzi IP risultanti vengono mantenuti aggiornati in modo affidabile, oppure rimuovi temporaneamente gli strumenti di marketing non essenziali durante il passaggio. Per configurare correttamente SPF, consulta la nostra guida a SPF.
Fase 2: sincronizzazione dei dati IMAP
Quando trasferisci la posta a un nuovo provider, la migrazione utilizza il protocollo IMAP (RFC 3501). Non è una semplice copia di file, ma una sincronizzazione dello stato. Strumenti come imapsync svolgono il lavoro più impegnativo, ma è importante capire il protocollo.
Il problema della «casella fantasma» di Gmail
Se migri «All Mail» da Gmail trattando le etichette come cartelle, potresti creare più copie visibili nelle cartelle IMAP: un'unica email con 3 etichette può essere copiata 3 volte in 3 cartelle distinte. La documentazione di Google sulla migrazione dei dati descrive questo comportamento delle etichette. La soluzione consiste nel configurare lo strumento di migrazione affinché associ le etichette in modo intelligente oppure nell'escludere del tutto la cartella [Gmail]/All Mail.
Limitazione del traffico e codici di errore
Quando trasferisci la posta a un nuovo provider, è normale che il server di origine imponga dei limiti. Google restituisce gli errori di connessione 11001/11002 quando l'accesso IMAP è disabilitato o bloccato da un firewall. Gli errori HTTP 429 indicano che stai inviando troppi dati; molti provider interrompono le connessioni oltre 2 GB/hour/user. Usa uno strumento di migrazione con attesa esponenziale, in grado di rilevare la limitazione e sospendersi automaticamente.
Fase 3: impatto sui client di posta
Dopo aver trasferito la posta sui server del nuovo provider, il lato server è spesso la parte più semplice; la nostra guida sul trasferimento di una casella spiega nei dettagli il passaggio DNS. È sul lato client che può arrivare l'ondata di richieste all'assistenza.
Certificato non corrispondente: se Outlook resta aperto durante il passaggio DNS, si collega a mail.yourdomain.com, che ora punta al nuovo provider, usando le vecchie credenziali. Possono quindi comparire avvisi relativi al certificato SSL/TLS. Consiglia di riavviare il client il lunedì mattina.
OAuth sui dispositivi mobili: i client mobili moderni usano token OAuth legati a un tenant specifico. In alcune applicazioni è sufficiente autorizzare di nuovo o riconfigurare l'account; in altre, l'utente deve eliminare il vecchio account e aggiungere una nuova connessione IMAP.
Cicli di instradamento interno: dopo il cambio degli MX, il vecchio server potrebbe ancora ritenere di ospitare il dominio. Se l'utente A (sul vecchio server) scrive all'utente B (anch'esso sul vecchio), il server consegna il messaggio localmente e l'utente B, che ora legge dal nuovo, non lo vede. Riconfigura in sicurezza la consegna locale del vecchio provider affinché inoltri la posta tardiva al nuovo mentre le cache DNS scadono; non disattivarla senza aver prima verificato il percorso alternativo.
Il rollback: una rete di sicurezza di 15 minuti
Poiché hai ridotto il TTL a 300 secondi nella fase 1, il rollback può essere più rapido per i resolver che rispettano quel TTL. Se il tentativo di trasferire la posta al nuovo provider fallisce, per esempio a causa di un blocco del firewall, problemi di licenza o assenza di flusso di posta per 30+ minuti, ripristina i record MX del vecchio provider. Il traffico tornerà gradualmente man mano che le cache scadono, ma non è garantito che ciò avvenga entro 5 minuti.
Come TrekMail semplifica il trasferimento
Trasferire manualmente la posta a un nuovo provider significa gestire script imapsync, interpretare errori oscuri come 0x800CCC0E e sorvegliare la propagazione DNS. TrekMail include un motore di migrazione IMAP che automatizza l'associazione delle cartelle, l'attesa in caso di limitazione e le sincronizzazioni delta per i dati IMAP supportati; al termine resta necessaria una riconciliazione con l'origine.
| Piano | Prezzo | Ideale per |
|---|---|---|
| Free | $0 | Test e domini personali (senza carta) |
| Starter | $3.50/mo | Piccole imprese e dominio singolo |
| Pro | $10/mo | Più domini e utenti avanzati |
| Agency | $23.25/mo | MSP che trasferiscono 50+ domini dei clienti con spazio condiviso |
Tutti i piani a pagamento includono una prova di 14 giorni (carta richiesta). Il piano Nano non richiede alcuna carta.
TrekMail si concentra sull'archiviazione e sulla consegna ad alte prestazioni della posta, affiancate da calendari e contatti per ogni casella tramite CalDAV e CardDAV. Se devi anche creare un indirizzo email con il tuo dominio, la nostra guida alla configurazione illustra ogni passaggio. La migrazione trasferisce solo la posta: esporta calendari e contatti dal vecchio provider e importali quando le caselle sono operative.
Per le agenzie che trasferiscono regolarmente la posta di decine di domini alla volta a un nuovo provider, TrekMail offre spazio condiviso (distribuisci 200 GB tra tutti i tuoi domini), SMTP gestito con una reputazione IP già consolidata e provisioning tramite modelli per applicare le impostazioni DNS e di migrazione a 100 domini in una volta.
Conclusione: trasferire la posta senza un buco nero
Trasferire correttamente la posta a un nuovo provider significa gestire contemporaneamente una transizione di stato per DNS, dati e accesso dei client. Ogni amministratore che deve farlo dovrebbe pianificare questa complessità. Il successo consiste nel ridurre messaggi respinti, perdite di dati e chiamate urgenti tramite verifiche e riconciliazioni. Prepara il TTL di 300 secondi, utilizza un'architettura in parallelo e tieni pronto un piano di rollback.
Per approfondire come scegliere la piattaforma email giusta e proteggere la reputazione del dominio durante il passaggio, consulta queste guide.
Smetti di pagare tariffe per utente per funzioni che non usi. Prova TrekMail gratuitamente e scopri com'è un hosting email pensato per gli amministratori.
