Aller au contenu
DMARC
← Blog

Protéger un domaine parqué ou sans email (p=reject)

Par Thomas · RSSI virtuel · 14 août 2026

Rares sont les organisations qui n'ont pas plus de domaines qu'elles n'en utilisent pour envoyer du courrier. Marques secondaires laissées en jachère, domaines de typo-protection achetés « au cas où », noms récupérés lors d'une acquisition, extensions défensives (.net, .co, la version sans tiret) : la plupart traînent une constellation de domaines dormants. Et c'est précisément là que se niche le danger. Un attaquant sait qu'un domaine que personne n'utilise est aussi un domaine que personne ne surveille — un terrain idéal pour envoyer du phishing au nom de la marque sans jamais déclencher d'alerte. La bonne nouvelle : verrouiller un domaine parqué est plus simple, plus rapide et plus sûr que sécuriser un domaine actif. Trois enregistrements DNS suffisent, et la politique la plus stricte se pose dès le premier jour, sans aucune montée progressive.

Pourquoi un domaine sans email est quand même une cible

L'idée reçue la plus répandue, c'est qu'un domaine qui n'envoie pas d'email n'a rien à protéger. C'est faux, et le malentendu vient d'une confusion entre envoyer et pouvoir être usurpé. Le champ From: d'un email est du texte libre : n'importe qui peut écrire facturation@marque-oubliee.fr dans l'en-tête d'un message, que ce domaine ait un serveur de messagerie ou non. L'absence d'enregistrement MX ne protège absolument rien — elle dit seulement que le domaine ne reçoit pas de courrier, pas qu'on ne peut pas prétendre en émettre.

Sans SPF ni DMARC publiés, un domaine dormant est en réalité grand ouvert. Un attaquant peut expédier des milliers de messages usurpant le domaine, et comme aucune politique ne dit aux destinataires quoi en faire, une partie passera. Le mécanisme de la menace est détaillé dans l'usurpation d'email expliquée : le principe reste le même pour un domaine parqué, à un détail près qui aggrave tout. Personne ne lit les plaintes. Sur un domaine actif, un pic d'usurpation finit par remonter — un client s'inquiète, le support reçoit des retours, une boîte de réponse déborde. Sur un domaine que l'organisation a oublié, la campagne peut tourner des mois sans que quiconque s'en aperçoive. Le silence n'est pas une protection ; c'est une fenêtre d'opportunité.

Les domaines de typo-protection méritent une mention à part. S'ils ont été achetés, c'est justement parce qu'ils ressemblent au domaine principal — une lettre en moins, un tiret en trop, une extension voisine. C'est exactement ce qui en fait des supports de phishing crédibles : la victime lit vite, reconnaît un nom familier et clique. Un domaine défensif laissé sans politique DMARC ne défend rien du tout ; il offre à l'attaquant un nom presque parfait et la liberté de l'usurper.

Les trois enregistrements qui ferment la porte

La parade tient en trois enregistrements DNS, plus un bonus. L'objectif est de dire au monde entier, de la manière la plus catégorique possible : ce domaine n'émet aucun email légitime, donc tout ce qui prétend venir de lui est à rejeter. Voici la logique de chacun.

1. Un SPF qui n'autorise personne

SPF déclare quels serveurs ont le droit d'envoyer pour un domaine. Pour un domaine qui n'envoie rien, la réponse est simple : aucun. L'enregistrement se réduit à sa forme la plus stricte.

marque-oubliee.fr.  TXT  "v=spf1 -all"

Le -all final signifie « rejette (hardfail) tout expéditeur non listé » — et comme rien n'est listé avant, cela couvre littéralement tout le monde. C'est le mécanisme le plus catégorique de SPF ; son sens exact et les nuances entre -all, ~all et ?all sont décortiqués dans les mécanismes SPF et le sens de -all. Ici, aucune hésitation possible : un domaine parqué n'a aucune raison d'utiliser un softfail. C'est le hardfail qu'il faut, et dès maintenant.

2. Un DMARC en p=reject immédiat

C'est le cœur du verrouillage, et c'est aussi là que le domaine parqué révèle son avantage décisif. Sur un domaine actif, on ne pose jamais p=reject du jour au lendemain : il faut d'abord observer les rapports, identifier chaque source légitime (le CRM, l'outil marketing, la facturation, le helpdesk), s'assurer que toutes sont bien alignées, puis durcir par paliers. Sauter cette étape ferait rejeter du courrier légitime — un désastre opérationnel. Toute cette gymnastique de montée progressive est décrite dans atteindre p=reject sans casser ses emails.

Sur un domaine qui n'envoie rien, ce risque n'existe pas. Il n'y a aucun trafic légitime à casser, donc aucune raison d'attendre. La politique maximale se pose directement.

_dmarc.marque-oubliee.fr.  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@domaine-principal.fr"

Deux détails comptent. D'abord, le p=reject immédiat : c'est légitime, sûr et recommandé précisément parce que le domaine est dormant. C'est l'un des rares cas en DMARC où la prudence progressive est inutile — le distinguer d'un domaine actif est important, car appliquer la même timidité ici ne ferait que retarder la protection sans aucun bénéfice. Ensuite, la balise rua : même sur un domaine inutilisé, mieux vaut garder un œil. Nous y revenons juste après.

3. Un DKIM révoqué : la clé publique vide

SPF et DMARC couvrent l'essentiel, mais un signal supplémentaire renforce la posture : publier un enregistrement DKIM qui déclare explicitement qu'aucune clé de signature n'est valide pour ce domaine. La convention est un enregistrement wildcard avec une clé publique vide.

*._domainkey.marque-oubliee.fr.  TXT  "v=DKIM1; p="

Le p= sans valeur signifie « clé publique vide », c'est-à-dire « cette clé est révoquée / aucune clé valide ici ». Le wildcard *._domainkey fait porter ce verdict sur n'importe quel sélecteur qu'un attaquant tenterait d'invoquer. En clair, il ne s'agit pas simplement de s'abstenir de publier une clé DKIM : c'est l'affirmation active qu'il n'y en a aucune de valide qui est publiée. C'est la différence entre une porte sans serrure et une porte murée.

Bonus : le null MX

Enfin, si le domaine ne reçoit pas non plus d'email — ce qui est le cas de la plupart des domaines parqués — un enregistrement MX « null », défini par la RFC 7505, le signale.

marque-oubliee.fr.  MX  0 .

Le . en cible, avec une priorité 0, dit explicitement « ce domaine n'accepte aucun courrier ». Ce n'est pas une mesure anti-usurpation à proprement parler, mais elle complète le tableau : les serveurs émetteurs cessent d'essayer d'y livrer des messages (y compris les rebonds d'une campagne d'usurpation), et le bruit inutile disparaît. C'est le geste d'hygiène qui achève de dire au monde : ici, il n'y a pas d'email, ni entrant ni sortant.

Pourquoi garder la surveillance rua sur un domaine inutilisé

À première vue, poser une adresse rua sur un domaine dormant semble superflu — il n'envoie rien, alors que rapporterait-il ? Précisément l'inverse de ce que l'intuition suggère. Les rapports agrégés d'un domaine parqué ne remontent pas le trafic légitime (il n'y en a pas) : ils remontent les tentatives d'usurpation. Chaque ligne d'un rapport RUA sur un tel domaine est, par définition, une adresse IP qui a essayé d'émettre au nom du domaine et s'est fait rejeter. C'est du renseignement pur sur les attaques visant la marque.

Concrètement, le rua se dirige vers une boîte déjà consultée — typiquement l'adresse de collecte du domaine principal, pour tout centraliser au même endroit. Le jour où cette adresse commence à recevoir un volume anormal de rapports pour un domaine de typo-protection, le signal est fort : quelqu'un mène une campagne active sous l'identité de la marque. Sans rua, ce rejet se produirait quand même — mais dans le silence, et le ciblage resterait ignoré. La collecte des rapports transforme un verrou passif en système d'alerte. La mise en place détaillée de cette adresse est couverte dans la présentation générale du standard, qui pose les fondations de tout le mécanisme.

Un mot sur la charge : un domaine parqué correctement verrouillé génère peu de rapports en temps normal, justement parce qu'il n'y a pas de trafic. Le volume ne monte que lorsqu'une usurpation démarre — ce qui rend le pic d'autant plus lisible. Cent domaines dormants n'appellent pas un tableau de bord sophistiqué ; il faut seulement qu'ils crient tous vers le même endroit le jour où l'un d'eux est attaqué.

Le cas des sous-domaines inactifs

Le raisonnement du domaine parqué s'applique aussi, à l'échelle inférieure, aux sous-domaines inutilisés. Le domaine principal a beau être actif et bien protégé, qu'en est-il de vpn.exemple.fr, old-crm.exemple.fr ou d'un sous-domaine qui n'a jamais existé du tout ? Les attaquants adorent forger des adresses sur des sous-domaines plausibles précisément parce qu'ils échappent souvent à la politique du domaine racine.

Deux balises DMARC couvrent ce terrain. La balise sp fixe la politique des sous-domaines existants mais non explicitement configurés — son fonctionnement est détaillé dans la politique de sous-domaine DMARC. La balise np, plus récente, fixe la politique des sous-domaines inexistants — ceux qu'aucun enregistrement DNS ne définit, et qui sont pourtant usurpables. Poser np=reject ferme cette catégorie entière d'un seul geste, sans le moindre risque pour le courrier légitime, exactement comme le p=reject d'un domaine parqué. Le sujet a son article dédié : la balise np pour verrouiller les sous-domaines inexistants. Sur le domaine racine d'une organisation, une politique complète ressemble donc à ceci.

_dmarc.exemple.fr.  TXT  "v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:dmarc@exemple.fr"

Ce p + sp + np en reject verrouille le domaine, ses sous-domaines actifs et ses sous-domaines fantômes d'un même mouvement. Pour un domaine parqué qui n'a de toute façon aucun sous-domaine légitime, la même logique s'applique par excès de prudence : rien n'émet, donc tout rejette.

Le récapitulatif : un domaine parqué verrouillé en entier

Mettons les quatre enregistrements bout à bout pour un domaine dormant type, disons ma-marque-secondaire.com, qui n'envoie ni ne reçoit d'email.

ma-marque-secondaire.com.             TXT  "v=spf1 -all"
_dmarc.ma-marque-secondaire.com.      TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@domaine-principal.fr"
*._domainkey.ma-marque-secondaire.com. TXT  "v=DKIM1; p="
ma-marque-secondaire.com.             MX   0 .

Quatre lignes, et le domaine passe de « grand ouvert » à « muré et surveillé ». SPF dit qu'aucun serveur n'a le droit d'envoyer ; DMARC ordonne le rejet de tout ce qui prétend le contraire et rapatrie les tentatives ; DKIM affirme qu'aucune signature n'est valide ; le null MX ferme la réception. Rien à maintenir au quotidien : aucune source à aligner, aucune montée à piloter. C'est une opération « pose et oublie », à ceci près que la boîte rua donnera l'alerte si le domaine devient soudain intéressant pour un attaquant. Ces quatre lignes ne valent toutefois que ce que vaut la zone qui les porte : un attaquant capable d'y glisser de faux enregistrements contourne l'ensemble sans jamais avoir à le casser, et c'est la signature DNSSEC de la zone qui ferme cette dernière porte.

L'erreur à ne pas commettre : traiter un parqué comme un actif

Le seul vrai piège, c'est la timidité mal placée. Certaines équipes, par réflexe, appliquent à leurs domaines dormants la même prudence qu'à leur domaine de production : elles posent p=none, se promettent d'« observer d'abord », et laissent le domaine en observation seule pendant des mois. C'est une erreur de raisonnement. p=none sur un domaine actif est une étape de prudence légitime le temps d'identifier les sources ; p=none sur un domaine parqué ne protège strictement rien, puisqu'il n'y a aucune source à découvrir. L'usurpation est alors documentée au lieu d'être bloquée, pour aucun bénéfice.

La distinction est fondamentale, et elle vaut la peine d'être intériorisée : la montée progressive existe uniquement pour ne pas casser de trafic légitime. Là où il n'y a pas de trafic légitime, il n'y a pas de raison de monter progressivement. Un domaine parqué mérite p=reject dès la première minute, point final. Comprendre ce principe, c'est aussi mieux comprendre pourquoi un domaine actif, lui, mérite de la patience — les deux cas sont les deux faces d'une même logique d'alignement, à replacer dans l'ensemble via le socle de la protection du courrier et le pilier DMARC.

Une dernière nuance sur les domaines destinés à être activés un jour. Si une marque secondaire aujourd'hui dormante doit servir à envoyer du courrier dans six mois, elle mérite quand même un p=reject dès maintenant. Le jour de l'activation, c'est la procédure normale de mise en service qui s'applique — publier SPF avec les vrais serveurs, activer DKIM avec une vraie clé, puis piloter la montée. Rien n'interdit de rouvrir une porte murée ; en revanche, une porte laissée béante « parce qu'on l'utilisera peut-être » est une invitation permanente. Verrouiller par défaut, ouvrir à la demande.

Passer les domaines dormants en revue avant qu'un attaquant ne les trouve

Le premier réflexe est gratuit et prend quelques secondes. Chaque domaine — actif comme dormant — passé dans notre analyseur DMARC gratuit révèle en un coup d'œil lesquels sont déjà verrouillés et lesquels restent grands ouverts. La surprise est fréquente : beaucoup de domaines défensifs n'ont, aujourd'hui, aucune politique du tout. Pour situer la posture globale face au secteur, l'Observatoire DMARC montre à quel point l'usurpation des domaines secondaires reste un angle mort répandu.

Cartographier tous les domaines d'un parc, distinguer les actifs des dormants, générer le bon DNS pour chacun et surveiller les rapports d'usurpation qui remontent des uns comme des autres : c'est exactement ce que Thomas, le RSSI virtuel, automatise. Il nomme chaque source sur les domaines actifs, propose le verrou complet sur les domaines parqués, et donne l'alerte quand l'un d'eux devient soudain une cible. Analyser un domaine gratuitement · explorer l'Observatoire · commencer avec Thomas.

Guides liés

À propos de l'auteur

Thomas — Thomas est le RSSI virtuel de DMARC.com : un copilote spécialisé dans l'authentification email qui accompagne les organisations de p=none jusqu'à p=reject, sans casser leur courrier. Ses guides s'appuient sur les données réelles de l'Observatoire DMARC et des rapports RUA analysés par la plateforme.