La migrazione della posta aziendale viene spesso pianificata come una sola modifica al record MX. MX decide dove consegnare i messaggi in ingresso, ma non aggiorna automaticamente siti, applicazioni, campagne, sistemi di fatturazione o moduli che inviano posta. Dopo il cambio, la ricezione può funzionare mentre SPF autorizza ancora una sorgente vecchia, DKIM non firma il messaggio nuovo oppure DMARC non trova allineamento con il dominio From. Un collaudo serio separa ricezione, invio, inoltro, bounce, autenticazione, report e accesso degli utenti, assegnando a ogni percorso un proprietario e una prova di chiusura.
Mappare domini, caselle e flussi
Crea un elenco di domini e sottodomini usati per caselle personali, condivise, notifiche, marketing, assistenza, fatture, recruiting e applicazioni. Per ogni voce annota destinatari, sorgenti di invio, inoltri, alias, auto-risposte, archiviazione, client mobili, credenziali applicative e contatti di escalation. Una piattaforma può mostrare un dominio come verificato senza dimostrare che tutti i messaggi del sito o dei servizi esterni usino la firma corretta. Chiedi ai proprietari delle applicazioni di fornire campioni reali, intestazioni e orari di invio. Senza una mappa, il team correggerà soltanto il percorso più visibile e lascerà attivi flussi dimenticati.
- Dominio, sottodominio e funzione della posta
- MX attuale, MX nuovo e priorità
- Sorgenti applicative, campagne e moduli
- SPF, selettori DKIM e firme effettive
- Politica DMARC, rua e responsabile dei report
- Finestra di cutover, rollback e gestione dei bounce
Verificare prima la ricezione
Prima del cambio salva MX, priorità, TTL, orario e sistema di ricezione. Dopo la modifica osserva il risultato da più resolver, poi prova caselle nuove, condivise, alias, inoltri e indirizzi inesistenti. Un test completo verifica anche il bounce: deve tornare a un mittente previsto con un messaggio interpretabile. Controlla se il vecchio sistema riceve ancora posta durante la finestra, quanto dura il periodo parallelo e chi può chiuderlo. La cache DNS può produrre consegne verso sistemi diversi, quindi registrare solo una prova locale non basta per dichiarare conclusa la transizione.
Dopo la ricezione, invia messaggi reali da sito, CRM, fatturazione, applicazioni interne e campagne. Per ogni campione conserva From, Return-Path, Received, Authentication-Results, DKIM-Signature, destinatario, data e risultato. Controlla consegna, spam, bounce, allegati e link. Se un inoltro o un sistema intermedio modifica il messaggio, documenta il percorso perché il risultato SPF può cambiare. Le prove di posta devono essere ridotte al necessario e trattate con attenzione, evitando di condividere dati personali o contenuti sensibili in sistemi non autorizzati.
Ricostruire SPF senza trascinarsi il passato
SPF dichiara quali sorgenti possono inviare per un dominio, non firma il contenuto del messaggio. Parti dall’elenco delle sorgenti realmente autorizzate: nuova piattaforma, servizi di assistenza, fatturazione, marketing, sito, applicazioni e processi programmati. Per ogni include o indirizzo chiedi chi lo usa e con quale scadenza. Rimuovere un’autorizzazione vecchia prima di aver trovato tutti i processi può bloccare messaggi legittimi; mantenerla per sempre amplia invece la superficie autorizzata. Verifica sintassi, record duplicati, catene include e limiti di query. Una risposta temporaneamente irraggiungibile deve restare distinta da una sorgente definitivamente non autorizzata.
Verificare DKIM e allineamento DMARC
DKIM richiede che il messaggio venga firmato e che la chiave pubblica del selettore sia pubblicata correttamente. Controlla il valore d= della firma reale, il selettore s=, la validità della chiave e l’effetto di eventuali modifiche al messaggio. DMARC confronta il dominio From con il dominio autenticato da SPF o DKIM. Microsoft spiega che un messaggio può superare DMARC quando almeno uno dei due meccanismi passa ed è allineato, mentre il solo record pubblicato non dimostra il risultato di un invio. Durante la migrazione vecchio e nuovo sistema possono usare Return-Path, selettori o domini di firma diversi: registra ciascuna combinazione.
_dmarc.example.it. IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]"Usa i report DMARC per confrontare sorgente IP, dominio From, dominio DKIM, selettore, dominio SPF, volume e risultato di policy con la mappa delle applicazioni. Una sorgente sconosciuta potrebbe essere un vecchio job, un servizio esterno legittimo, un inoltro o una configurazione incompleta; non chiamarla attacco senza prova. Una sorgente autorizzata che fallisce va assegnata a un responsabile con una correzione e una nuova verifica. I report non coprono necessariamente ogni destinatario e possono arrivare con ritardo, quindi una bassa quantità di dati non dimostra l’assenza di problemi.
Procedere con una policy graduale
Microsoft suggerisce un percorso da p=none a quarantine e poi reject, monitorando gli effetti e iniziando da domini o sottodomini con meno sorgenti. È un buon principio anche fuori da una piattaforma specifica: prima osserva, poi correggi le sorgenti legittime, poi aumenta l’azione della policy. Definisci chi approva il passaggio, quale periodo di osservazione serve, quali messaggi devono essere esclusi dal rischio e come si torna indietro. Il parametro più importante non è una percentuale universale di pass, ma la capacità di spiegare ogni sorgente che avrebbe impatto su clienti, utenti o processi finanziari.
Per domini parcheggiati o non usati, valuta una policy che impedisca invii inattesi soltanto dopo aver confermato che nessun processo legittimo li utilizzi. Per sottodomini di campagne può essere utile separare identità e volume dal dominio principale, ma la scelta deve riflettere la responsabilità reale. Mantieni report, bounce, reclami e risultati SPF e DKIM nello stesso progetto di migrazione. Chiudere la finestra appena il nuovo MX risponde elimina proprio le prove che servono per comprendere un problema tardivo.
Preparare rollback e post-migrazione
Il rollback non consiste solo nel ripristinare il vecchio MX. Devi sapere come riattivare caselle, inoltri, firme DKIM, autorizzazioni SPF, credenziali applicative, auto-risposte e gestione dei bounce. Stabilire una finestra e un responsabile evita che due sistemi ricevano messaggi senza controllo. Dopo il cutover ripeti i test in più momenti e da indirizzi esterni: ricezione, invio, password reset, fatture, risposte, allegati, spam, bounce e report. Conserva la baseline e la nuova fotografia, in modo da distinguere una conseguenza della migrazione da un nuovo cambiamento.
Per più domini, usa controlli strutturati invece di fogli con una sola colonna di stato. Il controllo sicurezza email, SPF Builder, DKIM Discovery, DMARC Builder e Lookup DNS di DomScan possono aiutare a verificare il singolo dominio e a preparare risultati riutilizzabili. Un flusso batch deve conservare dominio, tipo di record, orario, risultato, unknown e prova. Se il controllo non viene eseguito o una risposta è parziale, non presentare il record precedente come se fosse ancora aggiornato. Il monitoraggio deve segnalare anche la propria mancata esecuzione.
La migrazione coinvolge anche identità e accessi. Prima del cutover assegna le caselle, verifica alias e gruppi, controlla indirizzi di recupero e prepara il trattamento degli account di persone che cambiano ruolo. Se un’applicazione usa una credenziale SMTP, registrane proprietario, scadenza e percorso di rotazione senza inserire il segreto nel dossier pubblico. Dopo il cambio prova password reset, notifiche di sicurezza, fatture e risposte automatiche. Un messaggio arrivato alla casella giusta non dimostra che il flusso di recupero o l’autorizzazione applicativa siano corretti.
Controlla anche l’effetto dei domini secondari. Un’organizzazione può migrare la posta principale e dimenticare un dominio acquisito, un sottodominio marketing o un nome registrato ma non usato. Questi nomi possono essere usati per spoofing o possono ereditare una policy inattesa. Crea una decisione per ciascuno: invio autorizzato e monitorato, nessun invio previsto con policy coerente, oppure dismissione. La decisione deve avere owner, data, record osservati e una prova di nuova verifica. In questo modo la migrazione non lascia una parte del portafoglio senza controllo.
Simula un problema prima del rilascio. Invia una mail da una sorgente non autorizzata in un ambiente concordato, verifica un DKIM errato, prova un bounce e simula la perdita temporanea del nuovo MX. L’obiettivo non è produrre traffico inutile, ma dimostrare che il team riconosce la differenza tra un errore di configurazione, un messaggio sospetto e un controllo non riuscito. Documenta chi riceve l’evento, quanto tempo impiega a reagire e quale azione ripristina il servizio senza cancellare le prove.
Dopo la chiusura organizza una revisione a distanza di alcuni giorni. Confronta volume di invio, bounce, reclami, risultati DMARC, chiamate al supporto e sorgenti ancora presenti nei report. Un nuovo servizio può essere stato attivato durante la migrazione senza passare dal registro. Quando compare una sorgente inattesa, non aumentare subito la policy: identifica il proprietario, verifica il messaggio e aggiungi l’eventuale correzione alla mappa. Il valore dell’osservazione continua è proprio scoprire differenze che il test di una singola giornata non può vedere.
Misura anche la continuità operativa dal punto di vista degli utenti. Raccogli per alcuni giorni i ticket su accesso, sincronizzazione mobile, caselle condivise, calendari collegati e messaggi finiti nello spam. Un test tecnico può superare SMTP e DMARC mentre una persona non riesce a rispondere da un telefono o un gruppo perde la propria auto-risposta. Definisci una soglia per aprire un incidente, una procedura per recuperare un messaggio e una pagina interna con i contatti corretti. Quando il nuovo sistema è stabile, revoca gradualmente le credenziali e gli inoltri del vecchio sistema, mantenendo una registrazione della data e dell’approvazione. Non cancellare subito le prove necessarie per capire un ritardo o un bounce comparso dopo la riduzione del TTL.
La migrazione è chiusa quando i percorsi di ricezione e invio sono noti, tutte le sorgenti legittime hanno una spiegazione, SPF e DKIM contribuiscono all’allineamento DMARC, i report hanno un responsabile, i test di bounce sono comprensibili e il rollback è possibile. Non è necessario promettere che ogni messaggio verrà sempre accettato: è necessario sapere dove cercare quando un destinatario rifiuta, classifica o ritarda una comunicazione. Questa differenza trasforma una migrazione fragile in un cambiamento osservabile e gestibile.