Domaines parqués : verrouiller ceux qui n'envoient rien

Votre domaine principal est en p=reject. Vos rapports RUA sont propres. Vous surveillez vos sources d’envoi chaque semaine.

Et pendant ce temps, ancienne-marque.com, racheté en 2019, redirigé vers votre site et oublié depuis, n’a aucun enregistrement d’authentification. N’importe qui peut envoyer en son nom. Personne ne le verra.

Un domaine qui n’envoie rien n’est pas un domaine sans risque. C’est un domaine sans témoin : aucun destinataire légitime ne viendra vous signaler que quelque chose cloche, aucune campagne ne rebondira, aucun client ne s’étonnera. Un attaquant qui cherche un nom crédible à usurper préfère largement votre domaine dormant à votre domaine principal déjà verrouillé.

Cet article couvre la configuration complète d’un domaine sans flux sortant, y compris la partie que la plupart des guides passent sous silence : le comportement réel des wildcards DNS.

Étape 1 : faire l’inventaire avant de verrouiller

Retrouver tous vos domaines

La difficulté n’est pas technique, elle est organisationnelle. Les domaines s’accumulent sur plusieurs comptes registrar, souvent au nom de personnes parties depuis.

Quatre sources à croiser :

Les exports registrar, compte par compte. Prévoyez d’en découvrir un que vous aviez oublié.
La comptabilité : les renouvellements de noms de domaine sont des lignes de facture récurrentes, faciles à filtrer.
Les logs de Certificate Transparency (crt.sh) : tout certificat TLS émis publiquement y figure, y compris pour des domaines dont vous ne vous souvenez plus.
Vos redirections web : un domaine qui redirige vers votre site principal est un domaine que vous possédez, et probablement un domaine que vous n’avez jamais configuré côté email.

Les trois profils, qui n’appellent pas la même configuration

Profil	Description	Null MX
A	N’envoie rien et ne reçoit rien	✅ Oui
B	Reçoit encore du courrier, mais n’envoie rien (une adresse `contact@` toujours relevée)	❌ Non
C	Croit ne rien envoyer	⚠️ À vérifier d’abord

Un domaine qui héberge un site ou une redirection relève du profil A ou B selon sa boîte : la présence d’un A ou d’un AAAA ne change rien à la configuration email. Elle compte en revanche côté destinataire, car certains serveurs vérifient qu’un domaine « existe » en cherchant un MX, à défaut un A ou un AAAA. Un domaine qui répond en HTTP passe donc ce test d’existence alors qu’aucun message ne pourra jamais lui être livré, ce qui est exactement la raison d’être du null MX.

Le profil C est le seul piège réel. Un vieux formulaire de contact, un outil de facturation legacy, une sonde de monitoring qui envoie ses alertes depuis l’ancien domaine : le flux existe, il est faible, et personne ne s’en souvient.

La règle des deux semaines

Même sur un domaine que vous êtes certain d’avoir éteint, publiez d’abord un DMARC en p=none avec une adresse rua, et attendez deux semaines.

_dmarc.ancienne-marque.com  TXT  "v=DMARC1; p=none; rua=mailto:a1b2c3d4@rua.senderaudit.com"

Le coût est nul, aucun email n’est affecté, et c’est exactement ce qui vous évite de couper un flux du profil C sans le savoir. Si au bout de deux semaines les rapports ne montrent que des sources inconnues, vous pouvez verrouiller sereinement. S’ils montrent un serveur qui vous appartient, vous venez d’éviter un incident.

L’adresse ci-dessus est une adresse de collecte Sender Audit. Générez la vôtre en une ligne : elle est active immédiatement et vous évite de créer une boîte dédiée quelque part pour y accumuler du XML. La collecte démarre sans inscription, mais il faut un compte gratuit pour lire les rapports, les analyser et recevoir les alertes : rattachez l’adresse à un compte avant de lancer vos deux semaines, sinon vous attendrez devant une porte close. La section suivante explique pourquoi ce choix règle aussi un problème DNS que la plupart des gens découvrent trop tard.

Étape 2 : les quatre enregistrements du verrouillage

SPF : `v=spf1 -all`

ancienne-marque.com  TXT  "v=spf1 -all"

Traduction : aucun serveur au monde n’est autorisé à envoyer pour ce domaine.

Deux précisions qui comptent :

-all, pas ~all. Le softfail existe pour les migrations, quand vous n’êtes pas encore sûr d’avoir recensé toutes vos sources. Sur un domaine mort, cette incertitude n’existe pas. Utilisez le hardfail.
SPF sert même sans DMARC. SPF est évalué sur le domaine du MAIL FROM et sur le HELO, indépendamment de DMARC. Votre -all protège donc aussi face aux serveurs destinataires qui n’implémentent pas DMARC, ce qui reste le cas d’une partie du parc.

Pour le détail de la syntaxe, voir le guide SPF.

DKIM : révoquer tous les sélecteurs d’un coup

C’est la partie que presque aucun guide ne traite, et pourtant elle tient en une ligne.

La RFC 6376, section 3.6.1 prévoit qu’une valeur p= vide signifie que la clé publique est révoquée. Un enregistrement DKIM avec p= vide n’est pas un enregistrement cassé, c’est une révocation explicite.

Combiné à un wildcard, cela donne :

*._domainkey.ancienne-marque.com  TXT  "v=DKIM1; p="

Traduction : quel que soit le sélecteur, la clé est révoquée. Un attaquant qui inventerait mail._domainkey, default._domainkey ou n’importe quel autre nom obtient une révocation, jamais une clé exploitable. Vous n’avez pas à deviner les sélecteurs qu’il choisira.

Sur le fonctionnement des signatures et des sélecteurs, voir le guide DKIM et l’anatomie d’une signature DKIM.

DMARC : `p=reject`, et surtout pas seulement `p=`

_dmarc.ancienne-marque.com  TXT  "v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:a1b2c3d4@rua.senderaudit.com"

Trois tags, trois périmètres distincts :

Tag	Couvre
`p=`	Le domaine lui-même
`sp=`	Les sous-domaines qui existent
`np=`	Les sous-domaines qui n’existent pas (DMARCbis)

np= est arrivé avec DMARCbis et c’est précisément le tag fait pour ce cas de figure : sur un domaine parqué, tous les sous-domaines imaginables sont inexistants. Voir le guide pratique DMARCbis pour le détail.

Où envoyer les rapports, et pourquoi ce n’est pas anodin

Le domaine parqué ne reçoit rien : le rua doit donc pointer ailleurs. Et c’est là que la plupart des configurations échouent en silence.

Un rua qui pointe vers un autre domaine que celui de la politique DMARC est un envoi inter-domaines. La spécification impose au domaine destinataire de déclarer explicitement qu’il accepte de recevoir les rapports de ce domaine précis, sous la forme :

ancienne-marque.com._report._dmarc.votredomaine-principal.com  TXT  "v=DMARC1"

C’est l’enregistrement le plus oublié de tout l’écosystème DMARC, et son absence ne produit aucun message d’erreur : les serveurs refusent simplement d’envoyer, et vous concluez au bout de trois semaines que personne ne vous usurpe. Pire, il faut un enregistrement par domaine surveillé. Dix domaines parqués, dix enregistrements à publier, et à ne pas oublier au prochain rachat de marque.

Faire collecter les rapports par Sender Audit

C’est exactement le problème que résout une adresse de collecte :

_dmarc.ancienne-marque.com  TXT  "v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:a1b2c3d4@rua.senderaudit.com"

L’autorisation inter-domaines est déjà publiée côté Sender Audit, en wildcard, pour tous les domaines. Vous n’avez rien à ajouter dans votre zone, quel que soit le nombre de domaines que vous branchez dessus. Vérifiez-le vous-même :

dig +short TXT ancienne-marque.com._report._dmarc.rua.senderaudit.com

Vous obtenez "v=DMARC1;" pour n’importe quel domaine placé devant. Une ligne de moins par domaine, et surtout une source d’erreur silencieuse en moins.

Le reste suit : les rapports agrégés arrivent en XML compressé, illisibles à l’œil nu, et sont parsés, dédoublonnés et rattachés à une source identifiée. Sur un domaine parqué, l’intérêt n’est pas le tableau de bord, c’est l’alerte : le volume attendu est nul, donc la première ligne qui remonte est un signal, pas du bruit à trier.

Générer une adresse de collecte prend une ligne. La collecte commence dès que l’adresse est publiée, y compris sans inscription, mais lire les rapports, être alerté et suivre plusieurs domaines dans le temps demandent un compte gratuit auquel l’adresse est rattachée.

Un détail d’ordonnancement qui a son importance : faites ce rattachement avant de publier le null MX. Sans compte lié, la notification qui signale l’arrivée des premiers rapports part vers l’adresse contact@ du domaine concerné, et ce domaine est précisément celui que vous venez de rendre incapable de recevoir quoi que ce soit.

Null MX : `MX 0 .`

ancienne-marque.com  MX  0 .

La RFC 7505 définit cet enregistrement comme une déclaration formelle : ce domaine ne reçoit aucun email.

Le bénéfice est concret. Sans lui, un serveur qui tente de vous livrer un message (souvent un backscatter, le rebond d’un spam usurpant votre domaine) va réessayer pendant cinq jours avant d’abandonner. Avec un null MX, il abandonne immédiatement, avec une erreur permanente.

⚠️ Profil A uniquement. Le null MX coupe aussi la réception légitime. Si une seule adresse est encore relevée sur ce domaine, ne le publiez pas.

Étape 3 : le piège des wildcards DNS

Vous pourriez être tenté de couvrir tous les sous-domaines d’un coup :

*.ancienne-marque.com  TXT  "v=spf1 -all"

Cela semble économique. En réalité, cela produit un comportement que peu de gens anticipent.

Un wildcard DNS ne s’arrête pas à un niveau

Contrairement à l’intuition, *.example.com ne couvre pas seulement foo.example.com. La RFC 4592 définit la synthèse par wildcard à partir de l’encloser le plus proche présent dans la zone. S’il n’y a rien entre le wildcard et le nom demandé, le wildcard répond, quel que soit le nombre de labels.

Concrètement, avec pour seul enregistrement le wildcard ci-dessus :

Requête	Réponse obtenue
`foo.ancienne-marque.com` TXT	`v=spf1 -all` ✅ attendu
`selecteur._domainkey.ancienne-marque.com` TXT	`v=spf1 -all` ❌ ce n’est pas du DKIM
`_dmarc.sous.ancienne-marque.com` TXT	`v=spf1 -all` ❌ ce n’est pas du DMARC

Une requête DKIM se voit répondre un enregistrement SPF. Ce n’est pas dramatique (un serveur destinataire ignore un enregistrement qui ne commence pas par v=DKIM1 ou v=DMARC1, et conclut à une absence), mais c’est sale, et surtout c’est un cauchemar à diagnostiquer : vos outils de test signaleront des enregistrements « invalides » là où vous croyiez n’avoir rien publié.

La sortie est élégante

Publier le wildcard DKIM vu plus haut règle le problème tout seul :

*._domainkey.ancienne-marque.com  TXT  "v=DKIM1; p="

En créant ce nom, vous créez aussi le nœud intermédiaire _domainkey.ancienne-marque.com dans la zone. Ce nœud devient l’encloser le plus proche pour toute requête DKIM, et reprend donc la main sur le wildcard large. Chaque requête selecteur._domainkey récupère désormais la révocation, plus jamais le SPF.

Autrement dit : les deux wildcards ne sont pas redondants, le plus spécifique protège le plus large de ses propres effets de bord.

Quatre conséquences pratiques

Publiez toujours _dmarc explicitement. Sans enregistrement explicite, le wildcard répond à sa place, avec un contenu qui n’est pas du DMARC. Un enregistrement explicite l’emporte toujours sur un wildcard.
Vos validations de propriété continuent de fonctionner. Google Search Console, les challenges ACME _acme-challenge : dès qu’un enregistrement explicite existe à ce nom, le wildcard n’est pas utilisé du tout.
Tous les hébergeurs DNS ne suivent pas. Wildcards TXT, noms commençant par un underscore, null MX : certaines interfaces refusent l’un ou l’autre. Si le wildcard DKIM est impossible, publiez au minimum les sélecteurs les plus courants (default, mail, selector1, selector2, google, k1) avec p= vide.
Surveillez les TTL pendant la mise en place. Un TTL long sur un enregistrement erroné vous coûtera plusieurs heures d’attente à chaque correction.

La zone complète

Profil A : n’envoie rien, ne reçoit rien

ancienne-marque.com                TXT  "v=spf1 -all"
ancienne-marque.com                MX   0 .
*._domainkey.ancienne-marque.com   TXT  "v=DKIM1; p="
_dmarc.ancienne-marque.com         TXT  "v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:a1b2c3d4@rua.senderaudit.com"
*.ancienne-marque.com              TXT  "v=spf1 -all"
*.ancienne-marque.com              MX   0 .

Six lignes, et rien d’autre à publier ailleurs : l’autorisation inter-domaines des rapports est portée par le domaine de collecte. Si vous préférez recevoir les rapports sur une boîte à vous, ajoutez ancienne-marque.com._report._dmarc.votredomaine.com TXT "v=DMARC1" dans votre zone, et recommencez pour chaque domaine parqué.

Profil B : reçoit encore du courrier, mais n’envoie rien

Identique, sans les deux lignes MX 0 ., et en conservant vos enregistrements MX réels.

Plusieurs domaines : centraliser la politique

Si vous verrouillez dix domaines, dupliquer dix fois le même enregistrement _dmarc garantit qu’ils divergeront un jour. Le DNS permet de n’en maintenir qu’un seul et de pointer tous les autres dessus :

_dmarc.ancienne-marque.com  CNAME  _dmarc.parked.votredomaine.com.
_dmarc.autre-marque.com     CNAME  _dmarc.parked.votredomaine.com.
_dmarc.parked.votredomaine.com  TXT  "v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:a1b2c3d4@rua.senderaudit.com"

Un seul enregistrement à faire évoluer, et les rapports restent attribués au bon domaine, puisque c’est le domaine usurpé, et non la cible du CNAME, qui figure dans le rapport.

Le SOA, le seul moyen de vous joindre

Point presque toujours oublié. Une fois le null MX publié, postmaster@ et abuse@ de ce domaine n’existent plus, alors que la RFC 2142 en fait les points de contact attendus. Il reste un endroit dans le DNS pour indiquer à qui s’adresser : le champ RNAME du SOA.

ancienne-marque.com  SOA  ns.votredomaine.com. hostmaster.votredomaine.com. 2026082900 3600 7200 86400 86400

Le second champ, hostmaster.votredomaine.com., se lit hostmaster@votredomaine.com, sur un domaine qui reçoit vraiment du courrier. C’est le seul canal qu’un chercheur en sécurité ou un opérateur de blocklist aura pour vous signaler un problème sur ce domaine.

Les quatre valeurs suivantes sont les temporisations recommandées pour un domaine parqué : rafraîchissement une heure, nouvelle tentative deux heures, expiration un jour, TTL minimal un jour. Une zone qui ne bouge jamais n’a pas besoin d’être interrogée souvent.

Vérifier

dig +short TXT ancienne-marque.com
dig +short TXT _dmarc.ancienne-marque.com
dig +short TXT test._domainkey.ancienne-marque.com
dig +short MX ancienne-marque.com

La troisième commande est la plus instructive : le sélecteur test n’existe pas, et c’est justement le but. Vous devez voir revenir v=DKIM1; p=. Si vous voyez v=spf1 -all, votre wildcard DKIM n’est pas publié.

Pour un contrôle complet, scannez le domaine sur senderaudit.com : SPF, DKIM, DMARC, MX et cohérence d’ensemble sont vérifiés en une passe.

Et les sous-domaines dormants d’un domaine actif ?

Vous n’avez peut-être aucun domaine parqué. Vous avez en revanche presque certainement des sous-domaines inutilisés, et le raisonnement est le même.

mail.example.com, smtp.example.com, webmail.example.com, mx.example.com : ces noms n’envoient rien chez vous, mais ils inspirent confiance à un lecteur pressé. Ce sont des cibles évidentes.

La bonne nouvelle est que vous n’avez rien à publier sous-domaine par sous-domaine. Sur le domaine principal :

_dmarc.example.com  TXT  "v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:a1b2c3d4@rua.senderaudit.com"

np=reject couvre d’un coup tous les sous-domaines qui n’existent pas dans votre zone, y compris ceux qu’un attaquant inventera demain.

Une réserve : si vous créez des sous-domaines dynamiquement (environnements de préproduction, sous-domaines clients), commencez par np=quarantine et surveillez vos rapports avant de durcir.

Ce que ce verrouillage ne fait pas

Soyons honnêtes sur le périmètre. Une fois votre domaine parqué verrouillé, un attaquant conserve deux options :

Les domaines cousins. ancienne-marque-facturation.com ne vous appartient pas, votre DMARC n’a aucune prise dessus, et il sera parfaitement authentifié pour son propriétaire.
Le nom affiché. Rien n’empêche d’envoyer depuis random@gmail.com avec « Service facturation Ancienne Marque » comme nom d’expéditeur. Sur mobile, une bonne partie des clients mail n’affiche que ce nom.

Verrouiller vos domaines réduit la surface d’attaque, il ne l’annule pas. C’est nécessaire, ce n’est pas suffisant.

Checklist

Avant de verrouiller

Inventaire complet des domaines (registrar, comptabilité, crt.sh, redirections)
Profil déterminé pour chaque domaine (A, B ou C)
p=none avec rua publié depuis au moins deux semaines
Rapports RUA relus, aucune source légitime identifiée
Destination des rapports opérationnelle : adresse de collecte Sender Audit, ou autorisation _report._dmarc publiée sur votre domaine destinataire

Le verrouillage

v=spf1 -all sur le domaine
v=spf1 -all sur le wildcard
*._domainkey avec v=DKIM1; p=
_dmarc explicite en p=reject; sp=reject; np=reject
MX 0 . sur le domaine et sur le wildcard (profil A uniquement)
RNAME du SOA pointant vers une boîte réellement relevée, sur un autre domaine
Vérification dig des quatre enregistrements, dont le sélecteur DKIM inexistant

Ensuite

Renouvellement automatique activé chez le registrar
Alerte active sur le domaine parqué : tout rapport reçu doit vous parvenir, pas attendre votre prochaine visite

Conclusion

Un domaine parqué se verrouille en quatre enregistrements DNS, une fois, sans maintenance. Le seul vrai travail est en amont : savoir quels domaines vous possédez, et vérifier qu’ils n’envoient réellement rien avant de fermer la porte.

Gardez le rua en place après le verrouillage. C’est contre-intuitif sur un domaine qui n’envoie rien, mais c’est précisément là qu’il devient intéressant : le moindre rapport reçu ne peut être que la trace d’une tentative d’usurpation. Sur un domaine actif, il faut trier le légitime de l’illégitime. Sur un domaine parqué, tout ce qui remonte est suspect par construction.

C’est le seul témoin que vous aurez jamais sur ces domaines. Ne le débranchez pas, et surtout ne le renvoyez pas vers une boîte que personne n’ouvre : sur un domaine parqué, un rapport non lu et un domaine non surveillé reviennent au même.

Pour auditer un domaine, parqué ou actif, lancez un scan sur senderaudit.com. Pour collecter ses rapports DMARC et être alerté au premier signe d’usurpation, générez une adresse de collecte.