Préserver le courrier lors d’un changement DNS web : repérer les dépendances partagées

Définissez « uniquement le site web »

Notez les noms d’hôtes web prévus, l’autorité DNS réelle et la modification exacte proposée. Gardez hors périmètre fournisseur DNS, délégation, emplacement des boîtes, prestataire de courrier et conception de l’authentification. Un outil demandant de remplacer une zone ou de connecter du courrier propose un changement plus large qui doit être examiné séparément.

Conservez valeurs actuelles complètes et métadonnées pertinentes de TTL, préférence, alias, proxy ou routage avec références datées. Identifiez les responsables courrier et DNS capables d’expliquer les dépendances. Le type seul ne définit pas l’usage : une adresse web peut aussi être cible de courrier ou entrée d’une politique d’expéditeur.

Commencez par un registre de préservation vierge

En-tête : hôtes web ____ ; autorité/fournisseur DNS ____ ; périmètre/prestataire courrier ____ ; preuve datée ____ ; responsables ____ ; référence de modification exacte ____ ; exclusions ____. Écartez identifiants secrets, clés privées et adresses personnelles. Répétez la carte par enregistrement et les champs de dépendance par consommateur pertinent.

Inconnu signifie du travail restant à attribuer. Ce point de départ ne modélise pas tout le courrier : la configuration réelle détermine les autres enregistrements et consommateurs. Comptez candidats + protégés + partagés + inconnus afin de rendre visible toute classification manquante.

Suivez la réception au-delà du texte MX

La section 5.1 de RFC 5321 décrit comment une cible MX mène aux enregistrements d’adresse, tels A ou AAAA, du serveur de courrier. L’inférence de préservation est directe : si cette cible utilise une adresse du projet web, le même texte MX ne prouve pas une route inchangée. Notez le lien et suspendez la modification pour ses responsables.[2]

Cette section distingue un résultat MX vide d’enregistrements présents mais inutilisables. Le MX implicite décrit s’applique à l’absence d’entrées MX, pas aux entrées existantes inutilisables. Une erreur de requête ne prouve pas non plus l’absence. Notez la question au lieu d’inventer un repli ou de supprimer un enregistrement pour le créer.[2]

Il s’agit d’une lecture limitée du document d’octobre 2008, pas du diagnostic d’un domaine ni d’un audit complet des spécifications actuelles. Ne présumez pas que toute organisation d’adresses ou d’alias convient comme cible de courrier.

Examinez les dépendances d’authentification au-delà du TXT

Les sections 5.3 et 5.4 de RFC 7208 décrivent les mécanismes SPF a et mx. a compare l’adresse IP de l’expéditeur qui se connecte aux données A ou AAAA de la cible adaptées à la connexion ; mx utilise les adresses des hôtes MX retournés. Changer une adresse dépendante peut donc changer l’évaluation avec le même texte SPF TXT. C’est une dépendance possible, pas une évaluation complète ni un résultat de livraison.[3]

SPF mx n’hérite pas du MX implicite de SMTP lorsqu’aucun MX n’existe. Gardez cette différence dans le registre. Seuls ces mécanismes du document d’avril 2014 sont examinés ici ; includes, macros, limites de traitement et reste de la politique réelle demandent une revue distincte. Aucune nouvelle valeur SPF n’est prescrite.[3]

La page Microsoft sélectionnée traite de SPF, DKIM et DMARC. Utilisez-la pour inventorier les entrées existantes applicables d’authentification, de sélecteur, de politique et de découverte du fournisseur. Types et valeurs réels doivent venir de ses preuves actuelles ; ni sélecteur universel, clé, recette d’authentification ou garantie ne sont fournis.[1]

Examinez les changements exacts d’un flux automatique

La page Domain Connect de Microsoft 365, mise à jour le 23 avril 2026, décrit la connexion du courrier : modifier MX envoie les nouveaux messages à Microsoft 365, tandis que les anciens restent chez le précédent hébergeur sans migration. Selon le bureau d’enregistrement, Domain Connect peut proposer de supprimer automatiquement l’ancien MX. Ce sont les limites de ce flux courrier, pas des étapes web ni le comportement de tout assistant.[1]

Comparez ajouts, remplacements et suppressions au registre conservé. Écraser une ligne protégée, ajouter du courrier ou importer toute une zone élargit la proposition et exige périmètre et autorisation séparés. Ne réorientez pas MX et ne réécrivez pas SPF pour permettre un changement d’adresse web partagée non approuvé.

Amber Lantern Workshop fictif : texte identique, adresse partagée

L’annotation SPF incomplète n’est pas un enregistrement complet valide. Noms, types et valeurs de sélecteur/politique sont des espaces réservés sans clés. Deux liens comptent : adresse de cible MX M1 → W2 et adresse cible SPF a M2 → W2. Le récit a un MX explicite ; aucun repli d’absence MX SMTP ni repli SPF implicite n’est invoqué.

1 candidat + 4 protégés + 1 partagé + 0 inconnu = 6 lignes. Décision : SUSPENDRE W2 malgré le texte MX/TXT identique. W1 reste un candidat conditionnel, avec revue d’acceptation de réception, d’envoi et d’application en attente. Aucun enregistrement n’a changé et aucune livraison n’est démontrée.

Transmettez les changements permis et les questions ouvertes

Donnez au plan de bascule IDs candidats et preuves, ensemble protégé et adresses dépendantes, changements partagés/inconnus suspendus, modification automatique exacte et prochain responsable de chaque lacune. Ordre, horaires et retour appartiennent à ce plan distinct ; la classification seule n’approuve pas la publication.

Attribuez ensuite les preuves d’acceptation du courrier reçu, envoyé et applicatif aux responsables des services via leurs processus approuvés. Des chaînes DNS identiques ne prouvent ni livraison ni authentification ; cette fiche ne les effectue pas. Dans le récit, il faut résoudre la dépendance partagée de W2 en gardant W1 conditionnel.