Migrare una casella da Aruba a Exchange Online senza licenze

Una cassetta condivisa non costa niente fino a 50 GB. Il valore DKIM che suggerisce il portale è sbagliato, e le migrazioni IMAP non hanno un Completa.

Spostare una casella da un fornitore di hosting a Exchange Online ha due metà: copiare i messaggi, che è meccanico, e cambiare il DNS, che è la parte in cui la posta si ferma per tutti se sbagli.

Questa è stata fatta senza spendere una licenza, e il passaggio DKIM è costato un’ora perché il portale suggerisce un valore che non funziona più.

La casella che non costa niente

Una cassetta condivisa in Exchange Online è gratuita fino a 50 GB e non richiede una licenza propria.

Per un indirizzo tipo info@ — letto da più persone, non di proprietà di una — quello è comunque l’oggetto corretto, e per giunta rende la migrazione a costo zero. Creala nell’interfaccia di amministrazione sotto Team e gruppi → Cassette postali condivise prima di cominciare.

Il batch IMAP

Dal fornitore di origine servono tre cose: nome del server IMAP, porta, e se vuole SSL. Per il fornitore in questione: imaps.<fornitore>, porta 993, SSL, autenticazione Basic.

Il CSV di migrazione ha tre colonne:

EmailAddress,UserName,Password
[email protected],[email protected],PASSWORD

Interfaccia di amministrazione di Exchange → Migrazione → Aggiungi batch di migrazione.
Tipo: Migrazione a Exchange Online → Migrazione IMAP.
Crea un nuovo endpoint di migrazione con server, porta, SSL e autenticazione Basic, e lascialo validare.
Carica il CSV e avvia il batch.

Il risultato da cercare: stato Synced, coerenza dei dati Perfect, 100%, zero non riusciti.

Tenere il batch attivo per 24 ore dopo il cambio DNS conviene: raccoglie quello che è ancora atterrato sul vecchio server durante la propagazione.

Il cambio dei record DNS

Cambiano tre record. Prendi i valori esatti dall’interfaccia di amministrazione sotto Impostazioni → Domini → Record DNS — non copiarli da una guida, perché la parte specifica del tenant è diversa.

Tipo	Host	Valore
MX	`@`	`<tenant>.mail.protection.outlook.com`, priorità 0
TXT	`@`	`v=spf1 include:spf.protection.outlook.com -all`
CNAME	`autodiscover`	`autodiscover.outlook.com`

Il TXT di verifica del dominio (MS=…) resta esattamente com’è.

Se il pannello del fornitore chiede che tipo di MX stai configurando, la risposta è server esterni: la posta non è più loro.

DKIM, e il valore che il portale sbaglia

La firma si configura in Defender, non nell’interfaccia di amministrazione della posta: Email e collaborazione → Criteri e regole → Criteri per le minacce → Impostazioni di autenticazione email → DKIM. Selezioni il dominio, Crea chiavi DKIM, pubblichi i due CNAME, poi porti l’interruttore su Abilita.

I due record hanno questa forma:

Host	Punta a
`selector1._domainkey`	`selector1-<dominio>._domainkey.<tenant>.k-v1.dkim.mail.microsoft`
`selector2._domainkey`	`selector2-<dominio>._domainkey.<tenant>.k-v1.dkim.mail.microsoft`

Verifica con nslookup -type=cname selector1._domainkey.<dominio> verso un resolver pubblico. I server autoritativi del fornitore possono essere sfasati fra loro di qualche minuto, quindi che uno risponda giusto e un altro no, a metà cambio, è normale.

Cosa controllare alla fine

Il dominio risulta integro nell’interfaccia di amministrazione, con i tre record riconosciuti.
Manda una mail verso l’indirizzo da un account esterno — Gmail va bene — e verifica che arrivi.
Manda una mail da quell’indirizzo, poi apri le intestazioni del messaggio ricevuto e cerca spf=pass, dkim=pass, dmarc=pass.
Dopo 24 ore: Stop → Elimina il batch di migrazione.

Due record che puoi lasciare stare

Se il vecchio fornitore pubblicava una propria chiave DKIM — spesso su un selettore tipo a1._domainkey — e un record DMARC con p=none, entrambi sono innocui e per ora possono restare.

La vecchia chiave DKIM non firma più niente una volta che la posta esce da Microsoft, e p=none non dice a nessuno di rifiutare qualcosa. Toglierli è riordinare, non riparare, e riordinare conviene farlo quando la migrazione è stabile da un po’, non durante.