Una migrazione del provider di posta elettronica può lasciare attivi contemporaneamente due sistemi di invio legittimi. Il più sicuro SPF Il piano inizia con i messaggi e le identità che esisteranno durante tale sovrapposizione. Aggiungere il nuovo provider è solo un passaggio; rimuovere quello vecchio troppo presto o conservarlo a tempo indeterminato crea diversi problemi.
Inventariare il confine della migrazione
Elenca la posta dei dipendenti, le notifiche delle applicazioni, la fatturazione, le risposte automatizzate e i dispositivi inoltrati tramite la vecchia piattaforma. Per ciascun flusso, acquisisci il dominio della busta effettivo e il percorso in uscita. L'indirizzo del mittente visibile non è necessariamente l'identità SPF . Usa il catena di identità e-mail per mantenere questi campi separati.
Chiedi al nuovo provider le istruzioni attuali per il tuo tenant e la configurazione. Alcuni servizi utilizzano il proprio dominio busta a meno che non sia configurato un percorso di restituzione personalizzato. L'aggiunta di un'inclusione al tuo dominio principale non altera automaticamente tale identità. Non inventare valori del provider né riutilizzare la configurazione di un altro tenant.
Progettare la politica di sovrapposizione
Conservane uno applicabile Registro SPF ad ogni nome del proprietario valutato. Non pubblicare le vecchie e le nuove politiche come record SPF concorrenti separati. RFC 7208 §3.2 E RFC 7208 §4.5 definire il vincolo di selezione.
Costruisci un candidato contenente le autorizzazioni ancora necessarie. Valutare l'albero delle dipendenze combinato perché due configurazioni accettabili individualmente possono produrre un percorso combinato problematico. Testare gli attuali domini busta e le famiglie IP in uso. Evitare di contare semplicemente le inclusioni di primo livello o di dare per scontato che il nome di un provider nel DNS dimostri la corretta configurazione.
Registrare il risultato finale non corrispondente previsto e assicurarsi che non sia cambiato accidentalmente. Una migrazione non è un motivo per concedere un’autorizzazione universale. Mantenere DKIM configurazione e DMARC allineamento verifica nel piano come flussi di lavoro distinti.
Provare il ritaglio
Questa migrazione esemplificativa prevede che la posta del personale venga spostata lunedì mentre un'applicazione di fatturazione rimane sul vecchio relè fino a venerdì. La rimozione della vecchia autorizzazione lunedì ignorerebbe il calendario delle domande. Al contrario, lasciarlo per sempre perché fatture una volta utilizzato eviterebbe la decisione di dismissione. Il piano necessita di un proprietario separato e di un criterio di uscita per quel flusso.
Prima della produzione, preservare il vecchio valore DNS , il valore di sovrapposizione proposto e la decisione di ripristino. Esaminare i TTL precedenti e il comportamento di memorizzazione nella cache previsto senza promettere che tutti i ricevitori cambino contemporaneamente. Testa il nuovo percorso con messaggi ordinari e importanti varianti automatizzate, non solo con la schermata di verifica interna del provider.
Controllare le prove del destinatario
Raccogli un campione ricevuto da ciascun percorso pertinente e controlla il risultato dell'autenticazione del destinatario attendibile, l'identità della busta valutata e il dominio Da visibile. RFC 8601 spiega il confine di fiducia per Authentication-Results; un'intestazione inserita al di fuori di tale confine non è una prova indipendente.
Un passaggio SPF non elaborato non stabilisce l'allineamento DMARC . RFC 9989 sezione 4.4 mette in relazione le identità autenticate con il dominio dell'autore. Conferma l'autenticazione allineata del nuovo percorso anziché considerare una ricerca DNS riuscita come un completamento. La consegna può comunque dipendere da altre politiche del destinatario.
Rimuovere deliberatamente la vecchia autorità
Utilizza la conferma del proprietario dell'applicazione, l'invio di log e l'osservazione rappresentativa per decidere quando il vecchio percorso non è più necessario. Considera i tentativi in coda e i lavori pianificati insoliti. Non esiste un unico periodo di attesa che dimostri che ogni organizzazione abbia smesso di utilizzare un fornitore.
Preparare e approvare una seconda modifica alla policy che rimuova solo l'ambito ritirato. Ripetere le valutazioni positive e negative e verificare i restanti flussi. Mantenere un piano di rollback che tenga conto dell'esistenza o meno del vecchio servizio; un record DNS salvato non può ripristinare un account di invio annullato.
Chiudi la migrazione quando l'inventario, DNS , i test dei messaggi ricevuti e i record di proprietà concordano. Conserva la prova del ritiro in modo che l'amministratore successivo sappia perché il vecchio provider è stato rimosso anziché aggiungerlo nuovamente in risposta a un errore non correlato.
Sfondo DNS : RFC 1035 sezione 3.2.1 definisce il TTL del record di risorse; RFC 2308 §5 copre il caching negativo; RFC 8767 §4 aggiorna la semantica TTL e consente l'uso obsoleto quando l'aggiornamento autorevole non riesce. Questi descrivono il comportamento DNS , non un tempo di completamento universale per una modifica.
Registra la decisione successiva
Tieni traccia del personale e delle fatture come righe separate: proprietario, percorso corrente, dominio effettivo della busta, requisito di sovrapposizione, prova del nuovo percorso e condizione di pensionamento. La riduzione del personale non autorizza a rimuovere la dipendenza dalla fattura. Se il vecchio account viene cancellato, contrassegna il rollback del routing come non disponibile anche se viene salvato un vecchio valore DNS . Si tratta di un record di accettazione proposto, non di una migrazione eseguita.