Tester si un domaine peut être usurpé

Comment lire le résultat

Si les trois réponses sont favorables (p=reject ou p=quarantine, avec sp/np couverts) : le domaine exact n'est pas directement spoofable. C'est une bonne base, mais pas une garantie totale — une vérification régulière reste nécessaire pour détecter une dérive de la configuration (nouvelle source non alignée, changement de prestataire DNS), tout comme une surveillance des vecteurs annexes mentionnés ci-dessus.

Si l'enregistrement existe mais en p=none : le domaine est en phase d'observation, ce qui est une étape légitime du déploiement — mais il reste techniquement usurpable tant que la politique n'a pas été durcie. Ce n'est pas une urgence quand l'inventaire des sources se construit méthodiquement (voir atteindre p=reject sans casser ses emails), mais ce n'est pas non plus une protection.

Si aucun enregistrement n'existe : le domaine est spoofable sans aucune barrière, exactement comme s'il n'y avait jamais eu de DMARC. C'est le cas le plus fréquent chez les organisations qui n'ont simplement jamais entendu parler du sujet — et la bonne nouvelle est que la première étape (publier un enregistrement en p=none) est gratuite et immédiate.

Pourquoi ce test doit être répété, pas ponctuel

Un domaine correctement protégé aujourd'hui peut redevenir vulnérable demain, pour des raisons qui n'ont rien à voir avec une attaque : un changement d'hébergeur DNS qui efface accidentellement l'enregistrement, une migration de plateforme email qui modifie la configuration SPF sans toucher DMARC, ou une simple erreur de manipulation lors d'une intervention technique. C'est pourquoi ce test de spoofabilité mérite d'être répété périodiquement, pas seulement effectué une fois lors de la mise en conformité initiale — idéalement après chaque changement d'infrastructure email, et à intervalle régulier même sans changement connu.

En pratique, la façon la plus simple d'ancrer cette habitude est de donner au test un responsable explicite et un créneau dans le calendrier : un rappel trimestriel confié à la personne qui administre le DNS, plus une ligne dans la checklist de chaque ticket de changement lié à l'email — nouvelle plateforme marketing, migration de CRM, changement d'hébergeur DNS. Chaque vérification se compte en minutes : il n'y a donc aucun arbitrage réel à faire. Les organisations qui intègrent ce contrôle à leur gestion des changements détectent une régression en quelques jours ; celles qui l'ont traité comme un point d'audit ponctuel découvrent la dérive des mois plus tard, via un rapport d'incident plutôt qu'une revue planifiée — la façon la plus coûteuse possible de l'apprendre.

Un exemple de résultat, ligne par ligne

Pour rendre ce test tangible, voici comment interpréter un enregistrement DMARC réel, ligne par ligne, tel qu'une interrogation de _dmarc.exemple-entreprise.fr pourrait le renvoyer :

v=DMARC1; p=quarantine; sp=none; rua=mailto:dmarc@exemple-entreprise.fr

Chaque balise, prise séparément, révèle un morceau du verdict. v=DMARC1 confirme qu'un enregistrement DMARC valide existe — première question répondue positivement. p=quarantine indique une politique d'application partielle sur le domaine racine — deuxième question, réponse mitigée : ce n'est pas none (donc pas totalement ouvert), mais ce n'est pas non plus reject (donc pas la protection maximale). sp=none est le détail le plus révélateur ici : les sous-domaines, eux, n'ont aucune politique d'application — troisième question, réponse clairement défavorable. Un attaquant qui échoue à usurper le domaine racine (grâce à quarantine) peut se rabattre sans difficulté sur un sous-domaine, où sp=none laisse le champ libre.

Ce genre de configuration intermédiaire — ni totalement ouverte, ni totalement fermée — est en réalité très courant, et illustre bien pourquoi les trois questions du test doivent être posées ensemble : une réponse favorable à l'une ne dit rien des deux autres.

Pourquoi ce test précède toute autre discussion de sécurité email

Un piège fréquent dans les organisations qui commencent à s'intéresser à la sécurité email : sauter directement à des discussions sophistiquées — faut-il du BIMI, quelle solution de veille de domaines ressemblants choisir, comment former les équipes contre la fraude au président — sans avoir vérifié ce test de base en trois questions. C'est une erreur de priorisation coûteuse : toutes ces mesures avancées supposent, implicitement, que l'usurpation directe du domaine exact est déjà fermée. Investir du temps et du budget dans une veille de domaines ressemblants pendant que le domaine principal reste ouvert revient à installer une alarme sophistiquée sur les fenêtres d'une maison dont la porte d'entrée n'est même pas verrouillée.

C'est pourquoi ce test devrait être la toute première étape de n'importe quelle discussion de sécurité email dans une organisation — avant le budget, avant le choix d'outils, avant même la décision de qui portera le projet en interne. La réponse conditionne tout ce qui suit.

Le cas des domaines qui n'envoient jamais d'email

Un angle souvent oublié dans ce test : que faire des domaines détenus par l'organisation mais qui n'envoient jamais de courrier — marques défensives, anciens noms de produit, domaines réservés par prudence ? La réponse au test de spoofabilité pour ces domaines devrait toujours être « protégé au maximum », et immédiatement, sans phase d'observation. Puisqu'aucun email légitime n'en part jamais, il n'y a strictement aucun risque de faux positif à publier directement p=reject; sp=reject; np=reject sur un domaine parqué. C'est souvent le test le plus rapide à corriger de toute cette liste : quelques minutes de configuration DNS, sans aucune période de surveillance nécessaire au préalable, contrairement à un domaine actif où l'inventaire des sources légitimes prend du temps. Beaucoup d'organisations découvrent, en faisant cet inventaire, qu'elles possèdent bien plus de domaines dormants qu'elles ne le pensaient — anciens noms de marque, domaines achetés lors d'un rachat d'entreprise jamais nettoyés depuis, variantes réservées à titre défensif — et que chacun d'eux est resté grand ouvert pendant des années, cible gratuite que personne ne surveillait.

Faire le test en pratique

Vérifier manuellement ces trois points demande de consulter les enregistrements DNS du domaine avec un outil de requête (dig, ou l'interface de l'hébergeur DNS), puis d'interpréter la syntaxe DMARC — accessible, mais qui demande un minimum de familiarité technique pour ne pas se tromper sur un détail de syntaxe.

La méthode la plus rapide et la plus fiable reste de soumettre le domaine à l'analyseur DMARC gratuit, qui effectue ces trois vérifications automatiquement et rend un résultat clair en quelques secondes — politique actuelle, couverture des sous-domaines, et alignement des sources si un enregistrement existe déjà. C'est l'équivalent d'un scanner de vulnérabilité, mais pour une seule question précise et fondamentale : ce domaine est-il usurpable aujourd'hui ? Contrairement à un scanner de vulnérabilité générique qui produit une longue liste de résultats à trier et à prioriser, ce test donne une réponse directement actionnable, sans expertise nécessaire pour l'interpréter ni triage supplémentaire avant de décider quoi corriger en premier.

En résumé

Savoir si un domaine est spoofable n'exige ni expertise poussée ni long audit — trois questions factuelles suffisent : un enregistrement DMARC existe-t-il, en quelle politique, et les sous-domaines sont-ils couverts. C'est le point de départ de toute stratégie de protection contre l'usurpation, et la question à se reposer régulièrement, pas seulement au lancement d'un projet de sécurité email — un domaine correctement configuré aujourd'hui n'est pas une garantie de le rester demain sans surveillance continue. Un test qui prend trois minutes aujourd'hui peut éviter un incident qui coûtera, lui, bien plus de trois minutes à résoudre — en temps, en argent, et en confiance client à reconstruire, aucun des trois ne revenant aussi vite qu'il n'a été perdu.