Cambiare provider email del dominio: verifiche DNS

Potete cambiare hosting email del vostro dominio mantenendo gli indirizzi se ricostruite caselle, alias e autorizzazioni. Una modifica DNS errata può compromettere i flussi. Copia dei messaggi e passaggio della ricezione sono lavori distinti; confonderli può provocare rifiuti o consegne divise.

Per la panoramica, consultate la posta aziendale. Qui il tema è trasferire il servizio di un dominio amministrato tra provider, coordinando MX, SPF, DKIM e DMARC mentre gli utenti lavorano.

Preparate caselle prima della copia, riducete TTL in anticipo, pubblicate la nuova autenticazione e cambiate MX con destinazione verificata. Invertire l'ordine può generare correzioni successive.

Che cosa significa trasferire la posta di un dominio?

Mantenete dominio e indirizzi autorizzati, ma cambiate provider di ricezione e autenticazione dei servizi mittenti. Non è trasferimento del dominio tra registrar né permette di modificare il dominio di un account personale. Anche la copia conta; DNS, cache e autenticazione richiedono coordinamento.

Generalmente si tratta di tre attività:

1. Copiare i vecchi messaggi a destinazione, con le caselle di destinazione già create.
2. Completare e verificare le stesse caselle, alias e inoltri con autorizzazioni.
3. Modificare DNS se cambia la ricezione del dominio proprio.

Non cambiate MX prima di preparare le caselle e verificare la copia preliminare. Provate SPF e DKIM: un errore può influire sull'autenticazione in uscita senza determinare da solo spam o rifiuto.

Organizzate preparazione, passaggio e stabilizzazione. Il testo descrive importazione IMAP Gmail, Outlook, Yahoo, iCloud o altro server su Starter e superiori; verificate accesso e compatibilità. IMAP copia messaggi, non calendari, contatti e tutte le impostazioni. Consultate imapsync per la gestione della copia.

Fase 1: preparare il passaggio con 24-48 ore di anticipo

La preparazione può ridurre i rischi. Create prima le caselle, predisponete autenticazione, riducete TTL e copiate la posta. Il margine dipende da cache e ambiente, non da una scadenza universale.

1. Ridurre TTL dei record esistenti

300 secondi è un TTL illustrativo per MX, SPF e DMARC se il provider lo consente. Un margine di 24-48 ore può servire da riferimento senza garantire aggiornamento mondiale; cinque minuti prima non elimina le vecchie cache. Queste query sono basilari: l'ultima combina argomenti senza verificare affidabilmente DMARC; i TXT alla radice non validano neppure il selettore DKIM:

dig example.com MX

dig example.com TXT

dig example.com TXT _dmarc.example.com

Se il vecchio TTL era 3600 o 86400, alcuni resolver conservano risposte fino alla scadenza. Iniziate giorni prima, non venerdì alle 4:55 PM, e controllate separatamente autorità e resolver pertinenti.

2. Copiare messaggi prima di cambiare MX

Importate con origine attiva, dopo creazione della casella di destinazione. L'assistente TrekMail copia da account IMAP esterni secondo accesso e compatibilità; verificate contenuto, date, cartelle e indicatori in una prova preliminare.

Collegate il dominio, create la casella e consultate avviare un'importazione nel pannello. L'importatore usa credenziali IMAP dirette: password per le app Gmail secondo politiche oppure un altro percorso autorizzato con strumento compatibile se OAuth è obbligatorio. Il testo descrive TrekMail senza POP3; ciò non implica che POP interrompa sempre la continuità, ma salvate posta locale non sincronizzata prima di rimuovere profili.

3. Completare tutte le identità a destinazione

Prima di cambiare traffico, create e provate ogni casella, alias, inoltro e catch-all. Verificate autorizzazioni, restrizioni d'inoltro e casi meno comuni.

Esempio: billing@, support@, careers@, noreply@, una casella catch-all e un vecchio inoltro al Gmail del fondatore. Un'omissione può lasciare messaggi senza il percorso previsto anche se il resto funziona.

Per diversi marchi, un modello multidominio può semplificare attività entro i limiti. Consultate l'hosting email multidominio se serve scala, non solo un passaggio.

4. Unire SPF prima del trasferimento

Durante la sovrapposizione, autorizzate tutti i servizi legittimi ancora mittenti, vecchi e nuovi, per l'identità SMTP valutata. La RFC 7208 limita a 10 i meccanismi e modificatori valutati che richiedono DNS, inclusi quelli annidati; non conta tutti i pacchetti o query di rete. L'esempio vale solo se questi provider restano autorizzati:

v=spf1 include:_spf.google.com include:spf.trekmail.net -all

Il testo descrive SMTP esterno su TrekMail Free e gestito sui piani a pagamento; verificate condizioni e percorsi reali. Pubblicate una politica SPF per nome DNS, non due distinte; altri TXT non correlati possono coesistere.

5. Pubblicare DKIM e rivedere la politica DMARC

Pubblicate il nuovo selettore prima del passaggio e configurate la firma reale del provider. Non sovrascrivete il vecchio finché firma; conservate la chiave pubblica mentre messaggi in transito possono usarla. Passare a p=none è una decisione temporanea facoltativa del titolare dopo valutazione dei rischi, non obbligo né garanzia contro rifiuti. La politica può mantenere le richieste di quarantena o rifiuto se l'autenticazione è verificata.

Considerate cache negativa: un selettore interrogato prima di esistere può restare assente in cache secondo il SOA descritto nella RFC 2308. Pubblicate presto e verificate scadenza e risposte reali.

Fase 2: eseguire la transizione

Verificate DNS autoritativo, modificate MX con destinazione pronta, controllate resolver pubblici e provate ricezione e invio tra account reali. La durata dipende dall'ambiente.

Effettuate la modifica prevista senza pulizia DNS non correlata. Mantenete piano di ritorno e origine disponibile per ricezione tardiva e sincronizzazione amministrativa.

1. Verificare la preparazione della destinazione

Controllate ciò che si può prima di MX e provate le caselle. Active e indicatori verdi dipendono dai valori pubblicati senza dimostrare tutti i flussi. Consultate aggiungere un dominio a TrekMail. Il testo di marzo 2026 presenta questo esempio; usate valori attuali dell'account e politica DMARC approvata, non pubblicate alla cieca:

MX   @              mail.trekmail.net.   priority 10
TXT  @              v=spf1 include:spf.trekmail.net -all
TXT  dkim._domainkey  [unique value from dashboard]
TXT  _dmarc         v=DMARC1; p=quarantine;

Sostituite MX Google Workspace, Microsoft 365, Zoho, cPanel o registrar al momento opportuno. Le priorità generalmente indicano preferenza e alternativa, non distribuzione uniforme; mantenere destinazioni che accettano posta può portare messaggi a server differenti.

2. Cambiare MX e mantenere TTL basso

Sostituite l'insieme MX del dominio proprio dopo verifica della preparazione. Mantenere 300 nella transizione è una scelta illustrativa, non aggiornamento simultaneo di tutti i mittenti.

dig @8.8.8.8 example.com MX

dig @1.1.1.1 example.com MX

Interrogate almeno due resolver pubblici e confrontate l'autorità. Provate invio esterno al dominio e uscita dalla nuova casella; ripetete i passaggi per arrivi tardivi, spostamenti e indicatori, inclusi messaggi con data precedente.

3. Verificare i client IMAP

Verificate impostazioni attuali: IMAP imap.trekmail.net su 993 con TLS e SMTP smtp.trekmail.net su 465 con TLS implicito o 587 con STARTTLS. Controllate catena dei certificati, nome del server, indirizzo completo e password della casella, non del pannello. Consultate le impostazioni IMAP e SMTP dei client.

“Posso inviare ma non ricevere” richiede diagnosi: DNS, caselle e alias, quote, filtri, cartelle, cache e connessione del client. Usate test e registri per individuare la causa reale.

Fase 3: osservare le prime 72 ore

Le prime 72 ore sono una finestra illustrativa, non prova di completamento. Monitorate ricezione, autenticazione e servizi ancora sull'origine. Rimuovete autorizzazioni temporanee solo dopo conferma che non servano più.

Il passaggio può sembrare concluso dopo dieci minuti e rivelare dipendenze nei giorni successivi. Continuate il monitoraggio secondo traffico e servizi.

1. Cercare traffico sul vecchio provider

CRM, scanner, moduli WordPress, fatturazione e assistenza possono mantenere il vecchio SMTP. Esaminate intestazioni e registri; aggiornate e provate ogni integrazione prima di rimuovere autorizzazioni o rafforzare la politica.

2. Monitorare autenticazione, non soltanto consegna

Un messaggio consegnato può avere errori d'autenticazione; questo non dimostra da solo perdita di reputazione. Verificate risultati aggiunti dal ricevente affidabile e allineamento con From. DMARC può passare tramite SPF valido e allineato o qualsiasi firma DKIM valida e allineata. L'inoltro può influire su SPF; DKIM aiuta solo se resta valido e allineato.

Per inoltro esterno, consultate inoltrare email del dominio a Gmail per effetti e configurazione.

3. Rimuovere sovrapposizione dopo verifica del traffico

Rimuovete da SPF servizi non più autorizzati e conservate i vecchi record DKIM mentre code o verifiche di messaggi inoltrati ne hanno bisogno. Potete tornare a un TTL illustrativo di 3600 secondo l'operatività. Se avete scelto p=none, esaminate inventario, test e rapporti prima di ripristinare le richieste di quarantena o rifiuto della politica.

La rimozione verificata fa parte del trasferimento: evita autorizzazioni inutili senza eliminare chiavi o servizi ancora usati secondo un termine fisso.

Improvvisazione e processo controllato

Non confondete hosting e trasferimento del dominio tra registrar. Preparate caselle e copia, pianificate un'unica sostituzione MX, verificate autenticazione e usate controlli che non sostituiscano test completi.

Se gestite più di un dominio, confrontate TrekMail per domini propri, caselle IMAP, catch-all, SMTP esterno su Nano o incluso sui piani a pagamento, inoltri, importazione e API secondo condizioni attuali. Il testo indica Starter da $3.50 al mese e cita Free, Starter, Pro, Agency ed Enterprise. Consultate i prezzi TrekMail per limiti e costi attuali.

Elenco finale del trasferimento

L'elenco riassume preparazione, copia, identità, SPF, DKIM, decisione DMARC, passaggio, test e rimozione verificata. Non autorizza MX prima di creare e verificare la destinazione né impone di allentare politiche.

1. Ridurre TTL con margine illustrativo di 24-48 ore e considerare le vecchie cache.
2. Copiare posta tramite IMAP con caselle di destinazione già create.
3. Completare e provare caselle, alias, inoltri e catch-all.
4. Unire autorizzazioni SPF in una politica per nome.
5. Pubblicare DKIM con nuovo selettore e configurare firma reale.
6. Considerare p=none solo se il titolare approva modifica temporanea e rischi.
7. Verificare destinazione, accesso e controlli disponibili.
8. Sostituire MX pubblicati mantenendo temporaneamente vecchia ricezione.
9. Provare ingresso e uscita e ripetere sincronizzazioni dei cambiamenti.
10. Dopo una finestra illustrativa di 72 ore, valutare traffico e chiavi dei messaggi in transito prima di rimuovere autorizzazioni o modificare DMARC.

Un trasferimento controllato richiede inventario, test e monitoraggio, non solo impostazioni. TrekMail può offrire modello multidominio, spazio condiviso e importazione IMAP secondo piano; valutate limiti e costi senza presumere assenza d'interruzioni, perdite o supplementi.