Emails et réputation · 10 min · publié le 15 juillet 2025

Enregistrements MX modifiés : la messagerie a été détournée

Si les enregistrements MX ont changé, ce n'est plus seulement un site WordPress touché : c'est le DNS du domaine. Reprendre le registrar, rétablir les MX et changer les accès DNS est un incident à part, avec ses propres preuves.

Réponse directe

Le DNS du domaine a été touché, pas seulement le FTP. Reprenez le registrar, rétablissez les MX, changez les accès DNS. C'est un incident à part.

mx modifiés dns pirate email messagerie détournée

Ce que change un MX détourné

Le MX dit à Internet où livrer le courrier de votre domaine. S'il pointe vers un serveur que vous n'avez pas choisi, les nouveaux messages — devis, resets, factures fournisseurs — arrivent chez quelqu'un d'autre. Vos anciennes boîtes peuvent encore s'ouvrir : elles ne reçoivent plus rien d'utile.

Ce n'est pas un symptôme de plugin. C'est un accès au registrar, au panel DNS de l'hébergeur, ou à un compte Cloudflare / OVH dont le mot de passe était le même que l'admin CMS. Nettoyer les fichiers du site sans toucher au DNS laisse le détournement en place.

Inversement, un site piraté n'implique pas que les MX ont bougé. Vérifiez avant de tout reconstruire. Une copie d'écran de la zone DNS datée vaut plus qu'un souvenir.

  • MX modifié : la livraison est détournée.
  • Site infecté seul : les mails peuvent encore arriver au bon endroit.
  • Les deux : traitez le DNS en premier si la messagerie métier est critique.
Les réponses automatiques et les notifications de commande qui « ne partent plus » sont parfois un MX, parfois une file d'envoi saturée. On vérifie les deux.

Comment on s'en aperçoit vraiment

Les signes côté métier : plus aucun mail depuis 24 ou 48 heures, alors que le webmail s'ouvre ; des clients qui disent avoir écrit « plusieurs fois » ; un bounce vers une infrastructure inconnue. Les signes techniques : un `dig MX votre-domaine.fr` (ou l'équivalent dans le panel) qui ne correspond plus à la doc de votre hébergeur mail.

Comparez à une sauvegarde de zone, un ticket ancien, ou l'email d'activation de la messagerie. Un MX vers un hostname générique (serveur d'un pays que vous n'utilisez pas, un chiffre au hasard) est suspect. Un changement de TTL très bas juste avant, aussi : quelqu'un préparait la bascule.

Vérifiez A, AAAA, CNAME et les enregistrements de messagerie (SPF, DKIM, DMARC) dans la même passe. Un attaquant qui a le DNS peut aussi rediriger le www vers une page d'hameçonnage tout en gardant un site « propre » sur l'ancien hébergement.

Registrar d'abord, pas le FTP

Reconnectez-vous au registrar (où le domaine est facturé), pas seulement au FTP du site. Changez ce mot de passe, activez la double authentification si elle existe, parcourez l'historique des connexions et des modifications de zone. Un email « nameservers updated » reçu il y a trois semaines et ignoré est souvent le vrai début.

Si vous ne contrôlez plus le compte registrar — mot de passe inconnu, email de récupération détourné — c'est un vol de domaine, pas un simple MX. Contactez le support du registrar avec pièce d'identité et factures. Le nettoyage WordPress attend.

Listez qui avait l'accès : agence, freelance, ancien associé. Les mêmes secrets partout (registrar = panel = admin) transforment un incident CMS en incident DNS. Trois secrets distincts, ensuite.

Verrouillez le transfert du domaine (registrar lock) dès que vous avez la main. Ça n'annule pas un MX déjà changé ; ça évite l'étape suivante.

Rétablir les MX sans improviser

Remettez les valeurs documentées par votre prestataire mail (OVH Exchange, Google Workspace, Microsoft 365, messagerie de l'hébergeur), pas celles d'un tutoriel générique. Une priorité ou un hostname faux rend le domaine sourd pendant la propagation.

Gardez une copie de la zone pirate avant de l'écraser : IP, hostnames, date. C'est une pièce pour l'assureur, pour une plainte, et pour savoir si d'autres enregistrements ont été touchés.

La propagation n'est pas instantanée. Les correspondants dont le cache DNS est long continuent d'envoyer vers l'ancien MX quelques heures. Prévenez les clients réguliers par un canal hors domaine (téléphone, LinkedIn, autre adresse) si un contrat brûle.

  • Copie de la zone actuelle (pirate).
  • Valeurs officielles du prestataire mail.
  • Vérification `dig` depuis un réseau extérieur après TTL.

Changer les accès DNS et les délégations

Panel DNS, tokens d'API (Cloudflare, OVH), utilisateurs secondaires, délégation vers un prestataire SEO « qui gérait les emails ». Révoquez ce que vous ne reconnaissez pas. Un token d'API survit au mot de passe du panel comme un mot de passe d'application WordPress survit à l'admin.

Si les nameservers ont été changés vers une infrastructure tierce, les remettre chez vous est prioritaire sur le contenu du site. Tant que la délégation est ailleurs, rétablir un MX dans « votre » panel ne sert à rien : ce n'est plus la zone autoritaire.

Documentez qui est autorisé à toucher la zone après l'incident. C'est une ligne de contrat de maintenance, pas un détail technique.

Ce qui a pu être lu dans les boîtes

Pendant la fenêtre où le MX pointait ailleurs, les messages reçus ont pu être lus, stockés, ou utilisés pour des relances. Partez du principe que les fils sensibles (banque, social, clients) sont compromis. Changez les mots de passe des services dont le reset est passé par cet email.

Ce n'est pas automatiquement une fuite de fichier clients au sens RGPD — encore faut-il un constat : durée, volume, nature des messages. Mais c'est un accès à des correspondances. Conservez les journaux DNS et registrar. N'affirmez pas « personne n'a rien lu » : vous n'en savez rien.

Ouvrez chaque boîte restante : règles de transfert, réexpédition, délégués. Un MX rétablit n'efface pas une règle posée plus tôt via un webmail déjà ouvert.

Messagerie, site et hébergeur : trois horloges

Le DNS se propage en minutes à quarante-huit heures selon les TTL. Le site, lui, peut rester infecté indépendamment. L'hébergeur mail peut avoir blacklisté le domaine pendant le détournement. Traiter les trois comme un seul ticket produit des « c'est bon » trop tôt.

Ordre utile : contrôle registrar, MX et nameservers, mots de passe DNS, puis nettoyage du site, puis délivrabilité. Si une page d'hameçonnage est encore en ligne sur le domaine, elle se coupe tout de suite, MX ou pas.

Prévenez l'hébergeur web et le prestataire mail avec des faits (date du changement MX, hostname pirate). Ils ont parfois déjà un abus ouvert. Demandez les journaux, pas « remettez comme avant » sans copie.

Après le rétablissement

Testez la réception depuis une adresse extérieure, pas seulement un envoi interne. Vérifiez SPF/DKIM/DMARC : ils ont pu être réécrits en même temps que le MX. Surveillez une semaine les volumes et les absences de réponses clients.

Activez les alertes de modification de zone si le registrar les offre. C'est le filet le moins cher après un vol de MX. La double authentification sur le registrar vaut plus, ici, que celle du seul wp-admin.

Si vous déléguez la suite, un constat DNS (avant / après, dates, comptes) est aussi utile qu'un constat fichiers. Vous pouvez ouvrir un espace sans accès immédiat ; joignez la copie de zone.

Un site « propre » avec un MX encore pirate est un site qui a l'air réparé et une entreprise sourde.

Questions fréquentes

Le site s'affiche normalement. Les MX peuvent-ils quand même avoir changé ?

+
Oui. Le web (enregistrement A) et le courrier (MX) sont indépendants. Un attaquant peut ne toucher que le mail, ou les deux. Vérifiez la zone, ne vous fiez pas à la page d'accueil.

Combien de temps avant que les mails reviennent après correction ?

+
Souvent moins d'une heure si le TTL était court, jusqu'à 24–48 h pour les caches longs. Les messages déjà livrés sur le serveur pirate ne « reviennent » pas tout seuls.

Faut-il recréer toutes les boîtes ?

+
Pas si le prestataire mail n'a pas changé et que vous avez encore les comptes. Changez les mots de passe, chassez les règles de transfert, révoquez les applications. Recréer sert si l'infrastructure d'arrivée était entièrement compromise.

Est-ce une violation de données à déclarer ?

+
Possible, si des messages contenant des données personnelles ont été interceptés. Le constat (fenêtre, nature) décide. La notification CNIL, si elle est due, part dans les 72 heures à compter de la confirmation, et vous incombe.

L'agence dit que « c'est l'hébergeur ». Qui corrige ?

+
Celui qui a la main sur la zone DNS. Parfois l'hébergeur web, parfois le registrar, parfois Microsoft ou Google. Le contrat de maintenance devrait le dire. En attendant, c'est vous qui validez la zone rétablie.
À lire ensuite
Emails blacklistés Webmail piraté Règles de transfert Porter plainte Fuite de données Déclarer mon site