Délimiter ce qui ne rentre plus
Le site ouvre correctement depuis la migration, mais les messages envoyés à contact@atelier.example.test n’arrivent plus. Commencez par savoir si le problème touche toute la réception, une seule boîte ou seulement les notifications de WordPress. Demandez le domaine exact après le signe @, l’heure approximative de l’envoi, l’adresse de destination et le texte du message de retour s’il existe. Le domaine des adresses peut être différent de celui qui figure dans la barre du navigateur. C’est le domaine de l’adresse de destination que les serveurs expéditeurs cherchent à joindre.
Ouvrez le webmail ou le portail du fournisseur qui héberge déjà les boîtes, avec un compte autorisé. Vérifiez qu’une boîte connue existe et que vous pouvez voir des messages antérieurs. Demandez si d’autres personnes ont perdu la réception au même moment. Si un seul logiciel de bureau ne relève plus le courrier mais que le webmail le reçoit, examinez la connexion ou la synchronisation de ce logiciel. Si seuls les formulaires ou les réinitialisations de WordPress sont touchés, vérifiez le trajet des notifications avec le guide correspondant.
Notez ensuite les changements effectués lors de la migration. Une modification de l’adresse web dans la même zone, un changement de serveurs de noms et un transfert du domaine au bureau d’enregistrement n’ont pas la même portée. Si la zone a été déplacée, cherchez le relevé antérieur des DNS et la configuration attendue du fournisseur de messagerie. Une page web accessible prouve que son adresse fonctionne. La route du courrier se vérifie séparément à partir des enregistrements MX.
Identifier la zone active et le fournisseur des boîtes
Repérez où le domaine est enregistré et quels serveurs de noms lui sont actuellement délégués. L’espace qui facture le domaine peut être différent de celui qui héberge la zone DNS. Si vous avez changé de serveurs de noms, une ancienne zone peut rester visible dans un panneau alors que les expéditeurs interrogent la nouvelle. Notez l’espace qui contrôle effectivement la zone avant de modifier quoi que ce soit. Lorsque le domaine des boîtes est un sous-domaine, vérifiez si celui-ci a sa propre délégation.
Chez le fournisseur de messagerie, récupérez la liste complète des MX attendus pour ce domaine et leur priorité. Relevez aussi les autres valeurs DNS qu’il demande pour son service. Les MX sont des noms d’hôtes, à publier au nom approprié dans la zone. Dans un panneau, la racine peut être notée @ ou représentée par un champ vide. Pour un sous-domaine, le panneau peut attendre un nom relatif à la zone. Contrôlez l’enregistrement publié après sauvegarde pour éviter de créer par erreur un nom qui répète le domaine.
Conservez les valeurs avant toute correction. Photographiez ou exportez la partie de la zone qui concerne la messagerie, avec le nom, le type, la valeur, la priorité et le TTL. Notez aussi les paramètres web utiles. Vous pourrez ainsi réparer la réception en gardant les valeurs qui rendent le site accessible. Si le fournisseur des boîtes change lui aussi, obtenez la confirmation que les boîtes et alias ont été créés sur la destination prévue avant de rediriger le courrier.
Lire les réponses MX de l’extérieur
Sous Windows, remplacez atelier.example.test par le domaine de l’adresse qui ne reçoit plus. Les commandes comparent les MX vus par le résolveur du poste, les serveurs de noms de la zone interrogée et l’adresse web dans l’exemple. Si le domaine des boîtes est un sous-domaine géré dans une zone parente, recherchez les serveurs de noms de cette zone parente lorsque la requête NS directe ne montre aucune délégation. Pour interroger une autorité précise, ajoutez -Server et l’adresse confirmée de ce serveur. Avec dig, demandez de la même façon le type MX et, si besoin, précisez le serveur de noms.
Vérifiez le nom d’échange et la priorité de chaque réponse. Une valeur de priorité plus petite indique une préférence plus forte. Contrôlez que les hôtes MX annoncés correspondent à ceux du fournisseur et qu’ils ont les adresses attendues. Des MX anciens et nouveaux de priorité égale peuvent répartir les tentatives entre deux systèmes. Garder un ancien MX comme secours improvisé risque aussi d’acheminer des messages vers un serveur qui ne connaît plus les boîtes. Comparez avec la liste entière donnée par le fournisseur.
Resolve-DnsName -Name atelier.example.test -Type MX -DnsOnly
Resolve-DnsName -Name atelier.example.test -Type NS -DnsOnly
Resolve-DnsName -Name atelier.example.test -Type A -DnsOnlyRétablir les MX dans la zone effectivement publiée
Si la zone active n’annonce pas les MX prévus et que votre contrat de messagerie n’a pas changé, restaurez les valeurs du fournisseur déjà utilisé. Dans le panneau DNS de la zone active, ouvrez les enregistrements du domaine des boîtes. Ajoutez les valeurs exactes ou corrigez les entrées erronées avec le bon nom et la bonne priorité. Retirez les entrées anciennes du même ensemble lorsqu’elles ne font plus partie de la configuration confirmée. Ne recopiez pas une liste trouvée pour un autre compte. Chez certains fournisseurs, le serveur d’échange ou le nombre d’entrées dépend du domaine configuré.
Sur WordPress.com, si ses serveurs de noms contrôlent la zone, ouvrez le tableau de bord d’hébergement, choisissez Domaines puis le domaine concerné. Dans Réglages, ouvrez Enregistrements DNS et utilisez Ajouter un enregistrement pour les valeurs fournies. Si la zone est gérée ailleurs, appliquez les valeurs chez ce fournisseur de DNS. La connexion du site à WordPress.com et l’hébergement des boîtes peuvent rester chez deux prestataires différents. Si le problème suit une nouvelle délégation de la zone, examinez aussi les autres enregistrements exigés par le fournisseur, dont les validations du domaine. Les réglages d’authentification des expéditeurs ne remplacent pas le routage par les MX.
Après l’enregistrement, comparez la réponse autoritaire et celle de votre résolveur. Si la réponse autoritaire est bonne mais que certains réseaux voient encore l’ancienne valeur ou une absence, conservez l’heure et les TTL observés. Une absence peut aussi être mémorisée. Modifier de nouveau la zone ne vide pas les caches distants. Si la requête échoue au lieu de renvoyer une liste ou une absence de MX, vérifiez d’abord la délégation et l’état de la zone avec le fournisseur DNS.
Interpréter un MX absent, inattendu ou provisoirement en cache
Un MX dirigé vers un serveur lié au nouvel hébergement web peut expliquer la panne s’il n’héberge pas les boîtes. Un ensemble MX vide est un autre cas. Selon la résolution SMTP, un serveur expéditeur peut alors tenter l’adresse du domaine lui-même si elle existe et si la recherche ne signale pas une autre erreur. C’est une raison supplémentaire de rétablir les MX explicites du fournisseur. Un enregistrement 0 . est différent. Il déclare que le domaine n’accepte pas de courrier. Si vous voyez cette valeur sur un domaine qui doit recevoir, confirmez l’intention du service avant de la remplacer par la liste prescrite.
Dans l’essai local, la zone fictive atelier.example.test annonçait d’abord mx-web.atelier.example.test. Le serveur SMTP simulé de cette route a répondu 550 5.1.1 pour contact@atelier.example.test. Après remplacement du MX par mx-boites.atelier.example.test, la même adresse a été acceptée et le message fictif a été conservé en mémoire dans le banc. L’enregistrement web A est resté le même. L’essai utilise de vraies requêtes au serveur DNS local et des dialogues SMTP locaux. Il ne reproduit ni les caches des expéditeurs ni leurs tentatives ultérieures.
Un retour 550 5.1.1 indique typiquement un destinataire inconnu dans le système qui a répondu. Il peut se produire parce que le mauvais serveur a été atteint ou parce que l’adresse manque chez le bon. Identifiez ce serveur avant de créer une boîte ou de changer encore les DNS. Une erreur temporaire de classe 4xx appelle une autre lecture du message de retour et des journaux. Les tentatives peuvent rester en file chez l’expéditeur, selon sa politique.
Vérifier la boîte, l’alias et les traces chez le bon fournisseur
Lorsque les MX attendus sont visibles, ouvrez l’administration de la messagerie et vérifiez le domaine, puis l’adresse exacte. Distinguez une boîte avec connexion, un alias vers une boîte existante, un groupe avec restrictions et un renvoi. Une adresse peut avoir été recréée dans le mauvais espace, désactivée ou absente de la nouvelle destination. Si seule une adresse manque, comparez-la à une autre adresse du même domaine qui fonctionne. Créez ou restaurez l’objet prévu après validation du propriétaire et vérifiez sa destination.
Dans l’essai, après rétablissement du MX, contact@atelier.example.test était accepté tandis que devis@atelier.example.test recevait toujours 550 5.1.1. Les deux adresses passaient par le même MX, mais seule la première existait dans le serveur simulé. Répéter un changement de MX pour résoudre le second rejet aurait déplacé une route déjà fonctionnelle. Sur un service réel, les conditions d’un groupe, la quarantaine ou un filtre de transport peuvent aussi expliquer la différence.
Si le fournisseur dispose d’un outil de suivi, recherchez un envoi autorisé par heure, expéditeur, destinataire ou identifiant du message. Un résultat de rejet, de mise en quarantaine ou de livraison oriente vers des vérifications différentes. Une acceptation SMTP signifie que le serveur a pris en charge le message à ce stade. Vérifiez ensuite sa présence dans la boîte, la quarantaine ou la destination du renvoi avant de déclarer la réception rétablie.
Valider la réception avec deux adresses témoins
Une fois le DNS et les objets vérifiés, organisez un essai autorisé avec un expéditeur extérieur au service concerné. Utilisez un texte de test sans pièce jointe ni donnée personnelle et notez son heure. Testez une boîte principale et un alias ou un groupe important si le domaine en utilise. Pour chaque adresse, relevez le fournisseur qui a traité le message, le résultat dans son outil de suivi et l’emplacement où il est finalement visible. Un test émis depuis le même fournisseur peut suivre un trajet interne et ne pas vérifier le MX vu par un serveur externe.
Si un test échoue, attendez le relevé ou l’avis de non-remise correspondant avant d’en lancer plusieurs. Vérifiez la différence entre refus, attente, mise en quarantaine et livraison à un autre endroit. Une trace absente chez le fournisseur attendu peut conduire à relire le DNS et le message de retour. Elle peut aussi signifier que l’expéditeur n’a pas encore tenté la livraison ou que la recherche de journal ne couvre pas la bonne période. Conservez une adresse témoin qui fonctionne pour comparer.
Vérifiez ensuite que le site ouvre toujours sur les noms attendus. Dans une zone partagée avec le web, la correction doit laisser les enregistrements de site utiles en place. Traitez séparément un défaut d’envoi propre à WordPress qui subsisterait après rétablissement de la réception générale. Une boîte qui reçoit un message extérieur peut encore manquer les notifications si WordPress ou son service d’envoi connaît une autre panne.
Préparer un retour qui préserve les messages déjà reçus
Si vous avez modifié les MX et que la cible prévue ne reçoit pas, identifiez d’abord si la configuration précédente est encore opérationnelle. Rétablissez l’ancien ensemble fonctionnel uniquement si les boîtes y existent et si vous pouvez encore y consulter les messages. Remettez le nom, les valeurs, les priorités et les TTL relevés dans la zone active. Un changement des seuls MX ne déplace ni ne fusionne les messages qui sont déjà entrés dans l’une des boîtes. Si deux fournisseurs ont accepté du courrier pendant la bascule, conservez l’accès aux deux et organisez leur rapprochement avec les personnes responsables.
Refaites le relevé autoritaire après le retour. Il est possible que des expéditeurs continuent à utiliser la destination précédente pendant la durée de leur cache. Gardez en service les routes qui peuvent encore être utilisées, lorsque vous en avez la maîtrise. Si le service précédent a été fermé ou ne connaît plus les boîtes, rétablir son MX pourrait prolonger l’incident. Dans ce cas, préparez d’abord une destination capable de recevoir pour le domaine avec le fournisseur qui l’héberge.
Dans la recette locale, remettre le MX initial a reproduit le rejet du mauvais serveur. Cela vérifie le retour technique à un état connu de la zone de test. Sur un service réel, le point de retour choisi doit être un état qui peut effectivement livrer le courrier, et sa validation doit inclure une boîte et une trace de réception.
Identifier les messages à faire renvoyer
Vérifiez les deux systèmes si le fournisseur a aussi changé. Relevez les messages livrés à l’ancien service et ceux qui sont arrivés au nouveau pendant l’incident. Un message accepté par l’ancien fournisseur peut toujours y être consultable. Une erreur temporaire peut laisser des tentatives en file d’attente chez l’expéditeur. Un rejet définitif peut au contraire nécessiter un nouvel envoi de sa part. N’annoncez pas que tous les messages manquants réapparaîtront après la correction DNS.
Pour un message important, demandez à l’expéditeur de confirmer sa réponse de livraison ou de le renvoyer après le contrôle de la réception, en évitant de multiplier les copies si un premier envoi a déjà été livré. Notez l’intervalle touché, l’ensemble MX validé, les adresses témoins et l’endroit où les messages ont été retrouvés. Ce relevé permet de reprendre le diagnostic si un seul alias ou un seul correspondant continue à rencontrer un problème.
