Un enregistrement _dmarc en CNAME : piège ou pratique valable ?

Les pièges : exclusivité, cible évaporée, caches et interfaces

Un CNAME ne cohabite avec rien. Les RFC du DNS sont formelles : un nom qui porte un alias ne peut porter aucun autre enregistrement. Impossible donc d'ajouter un second TXT sur _dmarc — un jeton de vérification demandé par un outil tiers, un enregistrement de test temporaire. Les bonnes interfaces refusent la création ; les mauvaises l'acceptent et produisent une zone dont le comportement dépend du serveur qui répond. Le jour où un prestataire exige « un TXT sur _dmarc » pour valider quoi que ce soit, l'alias impose le détour par la cible.

La cible qui disparaît. C'est le scénario le plus sournois. Abonnement résilié chez le collecteur, zone centrale supprimée lors d'une migration, faute de frappe dans la cible : _dmarc.exemple.fr résout désormais en NXDOMAIN, et la politique s'évapore — sans aucune alerte, car rien ne casse visiblement. Le courrier légitime continue de circuler ; simplement, il ne reste plus aucune politique à appliquer côté destinataires, l'usurpation redevient possible et les exigences des grands fournisseurs pour les expéditeurs en volume ne sont plus remplies. Nuance apportée par DMARCbis : pour un sous-domaine, le Tree Walk remonte l'arborescence et retombe sur la politique du domaine organisationnel — filet partiel. Pour le domaine organisationnel lui-même, rien ne rattrape la chute. Le symptôme visible arrive souvent des semaines plus tard, quand quelqu'un remarque que les rapports ont cessé d'arriver.

Les TTL s'empilent. Une chaîne déléguée fait vivre deux enregistrements, donc deux TTL et deux caches indépendants. Un changement de politique effectué sur la cible se propage selon le TTL de la cible, mais l'alias lui-même reste en cache chez les résolveurs : le délai réel devient plus difficile à prédire qu'avec un TXT direct, et un TTL très long sur l'un des maillons peut retarder un durcissement — ou, plus gênant, un retour arrière d'urgence.

Les interfaces récalcitrantes. Dernier obstacle, prosaïque : certains gestionnaires DNS grand public refusent un CNAME sur un nom commençant par un underscore, ou ne valident _dmarc que comme TXT. Le contournement passe par l'éditeur de zone brut ou l'API quand ils existent — et quand ils n'existent pas, le montage est tout simplement impossible chez ce prestataire.

Une politique entre les mains d'un tiers

Les pièges précédents étaient techniques ; celui-ci relève de la gouvernance, et il pèse plus lourd. Un alias vers un nom contrôlé par un tiers revient à confier à ce tiers le pouvoir d'écrire la politique DMARC du domaine. Ce que la cible publie, les destinataires l'appliquent : un p=reject assoupli en p=none sans concertation, une adresse rua redirigée, une balise sp= modifiée — tout cela devient possible sans qu'aucune modification n'apparaisse dans la zone du titulaire. La zone du prestataire devient aussi une surface d'attaque : sa compromission vaut compromission de la politique de tous ses clients.

La grille de lecture est simple. Un alias vers une zone appartenant à la même organisation (la zone centrale du groupe) mutualise sans céder de souveraineté : la maîtrise reste en interne, seul l'emplacement change. Un alias vers un tiers est une décision de délégation à part entière, qui mérite le même traitement qu'une externalisation : clause contractuelle de réversibilité, surveillance indépendante de ce que la cible publie réellement, et procédure de sortie testée — car le jour du départ, reprendre la main se résume à remplacer l'alias par un TXT direct, encore faut-il savoir quel contenu y mettre.

Le parallèle DKIM : banal pour les sélecteurs, discuté pour _dmarc

L'ironie du débat, c'est que le même montage se pratique chaque jour sans que personne y trouve à redire — côté DKIM. Brancher un routeur d'e-mails passe presque toujours par des CNAME de sélecteurs : s1._domainkey.exemple.fr pointant vers un nom hébergé chez SendGrid, Mailjet, Brevo ou Amazon SES, qui publie la clé publique et la fait tourner sans intervention du client. Cette rotation déléguée est même un argument de sécurité : les clés changent plus souvent que si chaque client devait éditer sa propre zone.

Pourquoi la même technique passe-t-elle sans débat là-bas et fait-elle froncer les sourcils ici ? Parce que la portée n'a rien de comparable. Un sélecteur DKIM est un matériau technique, propre à un flux d'envoi, révocable individuellement, et noyé parmi d'autres sélecteurs : sa compromission ou sa disparition dégrade un flux, pas le domaine. L'enregistrement _dmarc, lui, est unique et gouverne le traitement de tout le courrier du domaine — et, via sp et le Tree Walk, celui de ses sous-domaines. Déléguer un sélecteur, c'est confier une clé d'appartement ; déléguer _dmarc, c'est confier le passe du bâtiment. La technique est identique, l'enjeu ne l'est pas — d'où des exigences de confiance différentes.

Quand préférer le TXT direct

La conclusion pratique se dessine d'elle-même. Le TXT direct reste le choix par défaut dans la majorité des situations : un ou deux domaines à gérer, une politique stable qui change trois fois dans la vie d'un domaine, une équipe qui veut lire sa configuration dans sa propre zone sans suivre une chaîne. L'alias n'y apporterait aucune économie réelle et ajouterait une pièce mobile de plus.

Le CNAME se justifie dans deux cas assumés : la flotte nombreuse pilotée depuis une zone centrale de la même organisation — le gain opérationnel est massif et la souveraineté intacte — et la délégation consciente à un prestataire, documentée comme telle, avec surveillance et porte de sortie. Entre les deux, la règle tient en une phrase : l'alias est un outil d'échelle et de délégation, pas un réglage par défaut ; à petite échelle et sans besoin de déléguer, il n'a que des inconvénients.

Vérifier une chaîne déléguée avec dig

La vérification tient en deux commandes. La première suit la chaîne comme le ferait un destinataire :

$ dig +short _dmarc.exemple.fr TXT
dmarc.groupe-exemple.fr.
"v=DMARC1; p=reject; rua=mailto:rapports@groupe-exemple.fr"

La première ligne montre l'alias, la seconde le TXT lu au bout : c'est cette valeur-là que les destinataires appliqueront. La seconde commande isole chaque maillon : dig +short _dmarc.exemple.fr CNAME confirme la cible exacte, puis dig +short dmarc.groupe-exemple.fr TXT interroge la cible en direct. Les points de contrôle : une chaîne d'un seul saut, une cible qui répond avec exactement un TXT commençant par v=DMARC1, aucun enregistrement parasite au même nom, et des TTL raisonnables des deux côtés. Un NXDOMAIN sur n'importe quel maillon signifie politique évaporée — le cas appelle une correction immédiate, pas une investigation de confort. Et parce que la chaîne peut casser côté cible sans qu'aucune modification n'ait eu lieu dans la zone du domaine, une vérification périodique automatisée vaut mieux qu'un contrôle ponctuel au moment du déploiement.

En résumé

Un _dmarc en CNAME n'est ni une hérésie ni un réglage anodin. Le DNS l'autorise pleinement : l'alias délègue tout le nom, la résolution suit la chaîne et le TXT lu au bout fait foi pour tous les destinataires. Deux usages le justifient — la délégation à un collecteur de rapports et la gestion d'une flotte depuis une zone centrale. En face, quatre pièges documentés : l'exclusivité du CNAME, qui interdit tout autre enregistrement au même nom ; la cible qui peut disparaître en emportant la politique sans alerte ; les TTL qui s'empilent ; et les interfaces DNS qui refusent le montage. Le facteur décisif reste la gouvernance : un alias vers sa propre zone centrale mutualise sans rien céder ; un alias vers un tiers délègue le pouvoir d'écrire la politique et se traite comme une externalisation. À petite échelle, le TXT direct conserve tous ses avantages.

Pour trancher sur un domaine précis, l'analyse DMARC gratuite suit les chaînes CNAME exactement comme le ferait un serveur destinataire et montre la politique réellement lue au bout — alias compris, maillon par maillon. Et lorsqu'une flotte entière repose sur ce montage, l'ouverture d'un compte permet d'en surveiller chaque maillon en continu : une cible qui s'évapore se détecte alors en quelques heures, pas au moment où le premier message frauduleux porte le nom du domaine.