Une migration de fournisseur de messagerie peut laisser deux systèmes d’envoi légitimes actifs en même temps. Le plus sûr SPF Le plan commence par les messages et les identités qui existeront pendant ce chevauchement. L'ajout du nouveau fournisseur n'est qu'une étape ; retirer l’ancien trop tôt ou le conserver indéfiniment crée différents problèmes.
Inventorier la frontière de migration
Répertoriez le courrier des employés, les notifications d'application, la facturation, les réponses automatisées et les appareils qui transitent via l'ancienne plate-forme. Pour chaque flux, capturez le domaine d’enveloppe réel et l’itinéraire sortant. L’adresse De visible n’est pas nécessairement l’identité SPF . Utilisez le chaîne d'identité de courrier électronique pour garder ces champs séparés.
Demandez au nouveau fournisseur les instructions actuelles pour votre locataire et votre configuration. Certains services utilisent leur propre domaine d'enveloppe, sauf si un chemin de retour personnalisé est configuré. L'ajout d'une inclusion à votre domaine racine ne modifie pas automatiquement cette identité. N’inventez pas de valeurs de fournisseur et ne réutilisez pas la configuration d’un autre locataire.
Concevoir la politique de chevauchement
Conservez-en un applicable Enregistrement SPF à chaque nom de propriétaire évalué. Ne publiez pas l’ancienne et la nouvelle stratégie en tant qu’enregistrements SPF concurrents distincts. RFC 7208 §3.2 et RFC 7208 §4.5 définir la contrainte de sélection.
Construisez un candidat contenant les autorisations encore requises. Évaluez l’arborescence de dépendances combinée, car deux configurations individuellement acceptables peuvent produire un chemin combiné problématique. Testez les domaines d’enveloppe et les familles IP réellement utilisés. Évitez de simplement compter les inclusions de niveau supérieur ou de supposer qu'un nom de fournisseur dans DNS prouve la bonne configuration.
Enregistrez le résultat final non correspondant prévu et assurez-vous qu’il n’a pas changé accidentellement. Une migration n’est pas une raison pour accorder une autorisation universelle. Garder DKIM configuration et DMARC alignement vérification dans le plan en tant que domaines de travail distincts.
Répétez le basculement
Cette migration illustrative fait circuler le courrier du personnel le lundi tandis qu'une application de facturation reste sur l'ancien relais jusqu'à vendredi. Supprimer l'ancienne autorisation lundi reviendrait à ignorer le calendrier des demandes. A l’inverse, le laisser définitivement car les factures une fois utilisées éviteraient la décision de démantèlement. Le plan nécessite un propriétaire et un critère de sortie distincts pour ce flux.
Avant la production, conservez l'ancienne valeur DNS , la valeur de chevauchement proposée et la décision de récupération. Passez en revue les durées de vie précédentes et le comportement de mise en cache attendu sans promettre que tous les récepteurs changent simultanément. Testez le nouveau chemin avec des messages ordinaires et des variantes automatisées importantes, et pas seulement avec l'écran de vérification interne d'un fournisseur.
Vérifiez les preuves du séquestre
Collectez un échantillon reçu de chaque route pertinente et inspectez le résultat de l'authentification du destinataire de confiance, l'identité de l'enveloppe évaluée et le domaine visible depuis. RFC 8601 explique la limite de confiance pour Authentication-Results; un en-tête inséré en dehors de cette limite ne constitue pas une preuve indépendante.
Une passe SPF brute n’établit pas l’alignement DMARC . RFC 9989 section 4.4 relie les identités authentifiées au domaine de l'auteur. Confirmez l'authentification alignée sur la nouvelle route plutôt que de considérer une recherche DNS réussie comme une achèvement. La livraison peut toujours dépendre des politiques des autres destinataires.
Supprimer délibérément l'ancienne autorité
Utilisez la confirmation du propriétaire de l'application, l'envoi de journaux et l'observation représentative pour décider quand l'ancien itinéraire n'est plus nécessaire. Tenez compte des tentatives en file d'attente et des tâches planifiées inhabituelles. Il n’existe pas de période d’attente unique qui prouve que chaque organisation a cessé de recourir à un fournisseur.
Préparez et approuvez une deuxième modification de stratégie qui supprime uniquement la portée retirée. Répétez les évaluations positives et négatives et vérifiez les flux restants. Conservez un plan de restauration qui indique si l'ancien service existe toujours ; un enregistrement DNS enregistré ne peut pas restaurer un compte d'envoi annulé.
Fermez la migration lorsque l'inventaire, DNS , les tests de messages reçus et les enregistrements de propriété sont conformes. Conservez la preuve de mise hors service afin que le prochain administrateur sache pourquoi l'ancien fournisseur a été supprimé plutôt que de le rajouter en réponse à une panne sans rapport.
Contexte DNS : RFC 1035 section 3.2.1 définit la durée de vie de l'enregistrement de ressource ; RFC 2308 §5 couvre la mise en cache négative ; RFC 8767 §4 met à jour la sémantique TTL et autorise une utilisation obsolète en cas d'échec de l'actualisation faisant autorité. Ceux-ci décrivent le comportement DNS , et non un délai d'exécution universel pour un changement.
Enregistrez la prochaine décision
Suivez le personnel et les factures sur des lignes distinctes : propriétaire, itinéraire actuel, domaine d'enveloppe réel, exigence de chevauchement, preuve de nouvel itinéraire et condition de retrait. Le basculement du personnel n’autorise pas la suppression de la dépendance facture. Si l'ancien compte est annulé, marquez la restauration du routage comme indisponible même si une ancienne valeur DNS est enregistrée. Il s'agit d'un enregistrement d'acceptation proposé et non d'une migration exécutée.