Coller un enregistrement DMARC dans la zone DNS ne clôt rien : le record ne fait rien tant que personne ne lit les rapports qu’il génère chaque jour. La surveillance de domaine désigne ce travail de lecture continue, réparti sur 4 axes : les rapports DMARC, les enregistrements DNS (MX, SPF, DKIM), la date d’expiration du domaine et les domaines similaires enregistrés par des tiers. Sans elle, une équipe growth découvre la panne après coup, quand le CMO demande pourquoi le taux d’ouverture a chuté. Le scénario est classique : une sender reputation qui s’effondre de 30% en trois mois sans qu’aucun contenu de campagne n’ait changé, la cause finissant presque toujours dans un enregistrement DNS modifié sans que personne ne s’en aperçoive.
Les 4 axes de la surveillance de domaine
Un domaine mal surveillé perd le contrôle sur 4 fronts en même temps, rarement un seul. Le premier concerne les rapports DMARC agrégés (RUA), qui arrivent quotidiennement dans une boîte mail dédiée et que peu d’équipes ouvrent. Le deuxième couvre les enregistrements DNS eux-mêmes : SPF, DKIM et l’enregistrement DMARC peuvent être modifiés par un prestataire externe ou un script de migration, sans qu’aucune alerte ne parte. Le troisième axe touche l’expiration du domaine, sujet administratif que personne ne veut porter. Le quatrième concerne les domaines qui ressemblent au vôtre à un caractère près, enregistrés pour tromper vos clients par usurpation ; le mécanisme de cette menace est traité plus loin. La surveillance de domaine ne bloque aucune attaque à elle seule. Elle déclenche l’alerte tôt, sur les 4 fronts à la fois.
Lire les rapports DMARC au lieu de se contenter de les publier
Un enregistrement DMARC en p=none ne rejette ni ne met en quarantaine un seul message. Il déclenche l’envoi de rapports agrégés (RUA), au format XML, une fois par jour en moyenne, par chaque fournisseur qui reçoit du courrier signé de votre domaine : Gmail, Outlook, Yahoo, ainsi que les serveurs d’entreprise qui appliquent DMARC. Les rapports forensiques (RUF), eux, détaillent un message individuel en échec. Google ne les envoie plus. Microsoft et Yahoo le font encore par intermittence. Décoder les champs d’un rapport agrégé (source IP, alignement SPF/DKIM, disposition appliquée par le serveur receveur) est un exercice technique à part entière, traité en détail dans notre article comment lire un rapport DMARC agrégé sans se tromper. Concrètement, sans lecture régulière, la politique reste bloquée en p=none. C’est le cas de la majorité des domaines protégés dans le monde, faute de personne pour dépouiller le flux XML et faire monter la politique vers p=quarantine puis p=reject.
Détecter un changement DNS non autorisé sur MX, SPF, DKIM, DMARC
Des outils comme MXToolbox, CaptainDNS ou DNS Assistant interrogent la zone DNS à intervalle régulier et déclenchent une alerte par email ou par Slack dès qu’un enregistrement MX, SPF, DKIM ou DMARC change de valeur, après comparaison avec la valeur précédente. La différence entre l’ancienne et la nouvelle valeur figure dans l’alerte, ce qui évite de rejouer un diagnostic complet à chaque incident. Un enregistrement SPF qui dépasse sa limite de 10 requêtes DNS échoue sans bounce ni alerte visible côté expéditeur, un scénario détaillé dans notre article sur la limite SPF des 10 lookups DNS. Un enregistrement DKIM supprimé après une migration d’hébergeur casse pareillement la signature de tous les emails sortants ; le seul symptôme visible est parfois un NDR (non-delivery report) affichant l’Enhanced Status Code 5.7.1, sans lien évident avec le changement DNS survenu la veille. Une bascule protocolaire planifiée, comme le retrait de la balise pct prévu par DMARCbis, produit ce même type de changement en apparence suspect mais légitime : comparer avant et après reste plus fiable que réagir à l’aveugle. Rien à consulter chaque matin dans une stack déjà chargée d’alertes : ces services tournent en tâche de fond et ne remontent un signal que lorsqu’une valeur bouge réellement. Un seul cas justifie l’installation. Le domaine change rarement de configuration DNS une fois stabilisé. Quand il change, c’est presque toujours une modification volontaire de quelqu’un dans l’équipe. Le monitoring sert à repérer celle qu’aucun ticket interne n’annonce, la piste la plus fréquente derrière un enregistrement détourné sans compromission du compte registrar, un scénario documenté par Infoblox et Eclypsium sous le nom Sitting Ducks.
Près de 800 000 domaines vulnérables identifiés et plus de 30 000 détournements confirmés depuis 2019, sans qu’aucun compte registrar n’ait été compromis (Infoblox et Eclypsium, 2024).
Surveiller l’expiration et le renouvellement du domaine
Le cycle qui suit une expiration compte trois phases : une période de grâce d’environ 30 jours où le renouvellement reste simple, une période de rédemption d’environ 30 jours avec pénalité de 80 à 200 euros, puis une fenêtre de suppression finale de 5 à 15 jours avant remise en vente publique. 13% des noms de domaine d’entreprise expirés sont réenregistrés par un tiers, selon les recherches internes de CSC publiées en 2024. Ce chiffre grimpe pour les domaines historiques laissés dans l’angle mort d’un portefeuille de marque jamais audité après une fusion ou un changement de prestataire. Un domaine perdu à ce stade emporte le site et les adresses email professionnelles. Il efface aussi le positionnement Google accumulé sur plusieurs années.
Repérer les domaines similaires et le typosquattage
Un domaine copié d’un caractère (remplacement d’un l par un i majuscule, ajout d’un tiret, omission d’une lettre, extension .co au lieu de .com) suffit à monter une page de phishing crédible ou une adresse d’envoi qui trompe un client pressé. Plus de 30 000 domaines lookalike imitant des marques connues ont été recensés entre février et juillet 2024 par Zscaler ThreatLabz, dont plus de 10 000 identifiés comme malveillants. Rien qu’en mars 2025, plus de 26 000 domaines usurpant des marques ou des services publics ont été détectés par Palo Alto Networks Unit 42 lors de campagnes de smishing. Le mécanisme technique de cette usurpation, la manière dont un attaquant falsifie l’expéditeur d’un email, est développé en détail dans notre article dédié à l’email spoofing. La détection en amont, avant l’envoi de la première campagne frauduleuse, limite les dégâts. Un service de veille sur les variantes proches du nom de marque déposé complète l’ensemble.
Fréquence de vérification recommandée par axe
| Axe surveillé | Fréquence recommandée | Signal déclencheur | Action si alerte |
|---|---|---|---|
| Rapports DMARC (RUA) | Lecture hebdomadaire | IP source non identifiée, alignement SPF/DKIM en échec | Identifier l’expéditeur, ajuster SPF ou faire monter la politique vers p=quarantine |
| Enregistrements DNS (MX, SPF, DKIM) | Monitoring continu avec alerte automatique | Valeur modifiée sans changement planifié | Comparer ancien/nouveau, restaurer si non autorisé |
| Expiration du domaine | Vérification trimestrielle du portefeuille | Renouvellement inférieur à 60 jours | Activer le renouvellement automatique et le verrou registrar |
| Domaines similaires / typosquattage | Veille mensuelle | Enregistrement d’une variante proche du nom de marque | Signalement au registrar, procédure UDRP si usage frauduleux confirmé |
Cette cadence tient dans la majorité des configurations observées sur des domaines déjà stabilisés. Un domaine qui vient de migrer vers un nouveau prestataire d’emailing justifie une lecture DMARC quotidienne le premier mois, le temps que l’alignement SPF et DKIM se stabilise sur la nouvelle infrastructure.
Ce que la surveillance de domaine ne couvre pas
La cause d’une délivrabilité qui chute pointe parfois ailleurs que le domaine : presque toujours vers la liste elle-même, avec un taux de hard bounce en hausse et des adresses catchall accumulées au fil des imports. Un domaine peut être parfaitement surveillé (DMARC lu, DNS stable, renouvellement anticipé, aucune variante typosquattée détectée) et voir sa délivrabilité chuter quand même. Le complaint rate grimpe aussi, visible via les feedback loops de plusieurs FAI. Ces signaux dégradent la réputation d’expéditeur au même titre qu’un enregistrement SPF cassé. Aucun outil de monitoring DNS ne les détecte et l’équivalent Microsoft du Postmaster de Gmail (SNDS, Smart Network Data Services, moins consulté mais tout aussi révélateur) ne couvre pas non plus la qualité des adresses envoyées. La seule façon de savoir si la liste a dérivé en même temps que le DNS reste de la passer au crible avant le prochain envoi, plutôt que de découvrir le problème dans un tableau de bord une fois la réputation déjà entamée.
La norme BIMI, qui affiche le logo de l’expéditeur dans la boîte de réception, exige un DMARC en p=reject stable depuis plusieurs semaines pour être activée chez la plupart des fournisseurs. Peu de domaines remplissent encore cette condition en 2026.
