DMARC : le guide de référence de l'enregistrement DMARC

La syntaxe de l'enregistrement _dmarc

Un enregistrement DMARC est un unique enregistrement TXT publié sur le sous-domaine _dmarc du domaine à protéger. Un domaine ne doit en porter qu'un seul — deux enregistrements rendent la politique ambiguë et peuvent conduire les destinataires à l'ignorer entièrement.

_dmarc.exemple.fr.  IN TXT
  "v=DMARC1; p=quarantine; rua=mailto:rapports@exemple.fr; adkim=s; aspf=r"

La valeur est une suite de paires balise=valeur séparées par des points-virgules. v=DMARC1 doit ouvrir l'enregistrement — y compris sous DMARCbis, qui conserve cet identifiant de version pour rester rétro-compatible. Voici les balises telles que définies par la RFC 9989 :

Balise	Rôle	Valeurs	Remarques
v	Version du protocole	DMARC1	Obligatoire, en première position — inchangée avec DMARCbis
p	Politique du domaine	none, quarantine, reject	Obligatoire ; s'applique au domaine et, par défaut, aux sous-domaines
sp	Politique des sous-domaines	none, quarantine, reject	Facultative ; remplace p pour les sous-domaines existants
np	Politique des sous-domaines inexistants	none, quarantine, reject	Nouveauté DMARCbis ; cible les sous-domaines qui ne résolvent pas
rua	Destination des rapports agrégés	mailto: (une ou plusieurs adresses)	Fortement recommandée : sans elle, aucun retour
ruf	Destination des rapports d'échec	mailto:	Facultative ; envois rares et souvent expurgés
adkim	Alignement DKIM	r (relaxed), s (strict)	Défaut : r
aspf	Alignement SPF	r (relaxed), s (strict)	Défaut : r
t	Mode test	y, n	Nouveauté DMARCbis ; remplace la balise pct, supprimée
psd	Marqueur de domaine de suffixe public	y, n, u	Nouveauté DMARCbis ; concerne surtout les registres

Deux évolutions de DMARCbis méritent d'être soulignées ici. D'abord, la balise pct — qui prétendait appliquer la politique à un pourcentage du courrier — a été supprimée : son interprétation variait d'un destinataire à l'autre et donnait une fausse impression de progressivité. Elle cède la place au mode test t, binaire et sans ambiguïté : t=y signale que la politique est en expérimentation. Ensuite, la détermination du domaine organisationnel — la base de l'alignement relaxed — ne repose plus sur la Public Suffix List, une liste externe maintenue à la main, mais sur le DNS Tree Walk : le destinataire remonte l'arborescence DNS elle-même, avec un plafond de huit requêtes. Le résultat est déterministe et auto-suffisant.

Pour partir d'une base saine plutôt que d'une page blanche, des exemples d'enregistrements prêts à adapter, fournisseur par fournisseur, sont disponibles sur le blog.

Les trois politiques : none, quarantine, reject

La balise p annonce aux destinataires ce qu'ils doivent faire d'un message qui échoue à DMARC. Les trois valeurs forment une échelle, et le barreau choisi change tout :

• p=none — observation pure. Les messages en échec sont délivrés normalement ; seuls les rapports sont produits. C'est le point de départ obligatoire : il permet d'inventorier les sources d'envoi sans aucun risque pour le courrier légitime. Mais il ne protège rien ni personne — un domaine en p=none reste intégralement usurpable.
• p=quarantine — les messages en échec sont traités avec défiance, en pratique dirigés vers le dossier indésirable. La protection devient réelle : un email usurpé n'atteint plus la boîte de réception, mais il reste consultable, ce qui limite les dégâts d'un faux positif.
• p=reject — les messages en échec sont refusés pendant la session SMTP. Ils ne sont ni délivrés ni stockés : l'usurpation du domaine exact devient impossible auprès de tout destinataire qui applique la politique. C'est l'objectif final, et le seul niveau qui arrête réellement le phishing au nom du domaine.

Quand faut-il utiliser chacune ? p=none pendant la phase d'inventaire, tant que les rapports révèlent des sources légitimes non alignées. p=quarantine dès que les rapports sont propres, comme palier de validation en conditions réelles. p=reject en régime de croisière, dès que la quarantaine n'a fait remonter aucun incident. Le comparatif détaillé des deux niveaux d'application — y compris les cas où la quarantaine prolongée se justifie — est traité dans p=quarantine ou p=reject : lequel choisir. Retenez le principe : none est un état transitoire, pas une destination. Un domaine qui y stationne des années documente son exposition sans la réduire.

Les rapports DMARC : rua et ruf

Le volet « Reporting » de DMARC est ce qui rend le déploiement pilotable. Sans lui, durcir une politique reviendrait à naviguer à l'aveugle ; avec lui, chaque décision s'appuie sur des données observées.

Les rapports agrégés (rua, spécifiés par la RFC 9990) sont des documents XML envoyés — généralement chaque jour — par les destinataires qui ont reçu du courrier se réclamant de votre domaine. Google, Microsoft et Yahoo en produisent massivement. Chaque rapport résume, par adresse IP émettrice : le volume de messages, le résultat SPF, le résultat DKIM, l'état de l'alignement et la politique appliquée. Ils ne contiennent aucun contenu de message ni aucune adresse de destinataire — uniquement des statistiques. C'est la matière première de tout déploiement : ils révèlent les services d'envoi oubliés (plateforme marketing, CRM, outil de facturation) qu'il faudra aligner avant de durcir. Leur structure et leur interprétation sont détaillées dans lire les rapports agrégés DMARC.

Les rapports d'échec (ruf, RFC 9991) sont différents : émis à l'unité, au moment d'un échec, ils contiennent des extraits du message concerné. Ils promettent un diagnostic fin mais tiennent rarement : la plupart des grands destinataires n'en envoient pas ou les expurgent lourdement, pour des raisons de confidentialité — un message réel peut contenir des données personnelles. En pratique, un déploiement se pilote aux rapports agrégés ; les rapports d'échec sont un complément occasionnel, à demander en connaissance de cause. Les différences, cas d'usage et précautions des deux canaux sont comparés dans rua vs ruf : quels rapports demander.

Une adresse rua doit figurer dans tout enregistrement, dès le premier jour et quelle que soit la politique. Si les rapports sont envoyés à un domaine tiers (un prestataire d'analyse, par exemple), ce domaine doit publier un enregistrement d'autorisation externe pour confirmer qu'il accepte de les recevoir.

Le chemin de déploiement : de p=none à p=reject

Le déploiement de DMARC est un processus itératif dont chaque étape est validée par les rapports. La séquence éprouvée :

1. Publier p=none avec une adresse rua. Aucun impact sur le courrier ; la collecte commence. Comptez deux à quatre semaines pour obtenir une image représentative, cycles de facturation et envois mensuels compris.
2. Inventorier les sources. Les rapports révèlent chaque IP qui émet au nom du domaine. Classez-les : services légitimes à aligner, services inconnus à investiguer, usurpation caractérisée.
3. Aligner chaque source légitime. Ajouter les émetteurs à l'enregistrement SPF, activer DKIM avec un domaine de signature aligné chez chaque prestataire d'envoi. C'est l'étape la plus longue — elle dépend de la coopération des équipes et des fournisseurs.
4. Passer à p=quarantine. Quand les rapports montrent que tout le courrier légitime est aligné. Le mode test t=y de DMARCbis permet de déclarer ce durcissement en expérimentation le temps de vérifier qu'aucune source oubliée ne tomberait.
5. Passer à p=reject. Après quelques semaines de quarantaine sans incident. La surveillance des rapports continue ensuite en routine : une nouvelle source apparaît à chaque nouvel outil adopté par une équipe.

Les critères objectifs qui indiquent qu'un domaine est prêt à monter d'un cran — taux d'alignement, stabilité, couverture des sous-domaines — sont réunis dans la checklist d'éligibilité de p=none à p=reject, et le récit complet du parcours, écueils compris, dans atteindre p=reject sans casser ses emails. Avant toute chose, vérifiez l'état réel de votre enregistrement actuel avec notre analyseur DMARC gratuit : politique publiée, alignement, erreurs de syntaxe — le point de départ se mesure, il ne se devine pas.

DMARCbis en bref

DMARCbis est la révision complète du standard, publiée par l'IETF sous la forme de trois RFC : 9989 (le protocole), 9990 (les rapports agrégés) et 9991 (les rapports d'échec). Ensemble, elles remplacent la RFC 7489 de 2015 et font accéder DMARC, pour la première fois, au statut de Proposed Standard — la voie des standards, là où le texte d'origine n'était qu'informatif.

L'essentiel à retenir tient en quatre points :

• Rétro-compatibilité totale. Les enregistrements commencent toujours par v=DMARC1 ; un enregistrement existant reste valide sans modification.
• pct supprimée, t introduite. Le déploiement « au pourcentage » disparaît au profit d'un mode test binaire, plus honnête et interprété uniformément.
• np et psd introduites. La première verrouille les sous-domaines inexistants, cible favorite des usurpateurs ; la seconde balise les domaines de suffixe public.
• Le DNS Tree Walk remplace la Public Suffix List. La découverte du domaine organisationnel devient native au DNS, déterministe et identique chez tous les destinataires.

Pour l'analyse complète du nouveau standard — genèse, débats du groupe de travail, conséquences pour l'écosystème — voir DMARCbis expliqué. Et si vous vous demandez ce qu'il faut concrètement changer dans un enregistrement existant, la réponse courte est « très peu » : le mode d'emploi tient dans faut-il migrer vers DMARCbis ? — retirer un pct devenu inerte, envisager np=reject, et c'est à peu près tout.

Cas particuliers : sous-domaines et domaines parqués

Les sous-domaines héritent par défaut de la politique p du domaine organisationnel — sauf si une balise sp en décide autrement, ou si le sous-domaine publie son propre enregistrement _dmarc. Cette souplesse est utile (un sous-domaine d'envoi transactionnel peut durcir avant le domaine racine) mais elle est aussi un angle mort classique : un p=reject sur la racine accompagné d'un sp=none laisse tous les sous-domaines usurpables. DMARCbis ajoute la balise np pour un cas encore plus insidieux : les sous-domaines inexistants. Rien n'empêche un attaquant d'émettre depuis paie.exemple.fr même si ce nom n'a jamais existé dans votre zone — et comme aucun service légitime ne peut en dépendre, un np=reject se publie sans le moindre risque, souvent bien avant que la racine ne soit prête. L'articulation complète des trois niveaux — p, sp, np — et leurs pièges d'héritage sont traités dans la politique de sous-domaine DMARC.

Les domaines parqués — détenus mais n'envoyant jamais d'email — sont l'autre angle mort. Précisément parce que personne ne les surveille, ils sont des cibles d'usurpation idéales : le destinataire n'a aucune raison de se méfier d'un domaine qui vous appartient réellement. La protection est simple et immédiate, puisqu'il n'y a aucun courrier légitime à préserver : p=reject d'emblée, un SPF v=spf1 -all qui n'autorise aucun émetteur, pas de DKIM, et un null MX pour signaler qu'aucun courrier n'est attendu. La procédure complète, enregistrement par enregistrement, est décrite dans protéger un domaine parqué. Un inventaire de domaines bien tenu applique ce verrouillage à chaque domaine dormant du portefeuille — c'est le durcissement au meilleur rapport effort/protection de toute la démarche.

FAQ

DMARC remplace-t-il SPF et DKIM ?

Non. DMARC ne fonctionne pas sans eux : il s'appuie sur leurs résultats et y ajoute l'alignement avec le domaine du From:, puis la politique et les rapports. Un message passe DMARC si SPF ou DKIM réussit avec un domaine aligné. Les trois standards se déploient donc ensemble : SPF et DKIM d'abord, DMARC pour les relier à l'adresse visible et rendre le tout opposable.

Peut-on publier plusieurs enregistrements DMARC sur un même domaine ?

Non. Un domaine ne doit porter qu'un seul enregistrement TXT sur _dmarc. Si plusieurs enregistrements commençant par v=DMARC1 coexistent, le comportement des destinataires est indéfini — la plupart les ignorent tous, ce qui laisse le domaine sans politique alors qu'il se croit protégé. Toute modification passe par la fusion en un enregistrement unique.

La balise pct existe-t-elle encore ?

Non. DMARCbis (RFC 9989) a supprimé pct, dont l'interprétation « appliquer la politique à un pourcentage du courrier » variait d'un destinataire à l'autre. Elle est remplacée par la balise t, un mode test binaire : t=y signale que la politique est en expérimentation. Un pct résiduel dans un enregistrement existant est simplement ignoré par les implémentations à jour — le retirer garde l'enregistrement lisible.

Combien de temps faut-il pour passer de p=none à p=reject ?

Tout dépend du nombre de services qui émettent au nom du domaine. Un domaine simple, avec une messagerie et un ou deux outils d'envoi, se verrouille en quelques semaines. Une organisation avec des dizaines de sources — marketing, CRM, facturation, support — compte plutôt en mois, le temps d'aligner chaque prestataire. Les repères de durée réalistes, phase par phase, sont détaillés dans combien de temps pour atteindre p=reject.

p=none protège-t-il un domaine contre l'usurpation ?

Non. En p=none, les messages qui échouent à DMARC sont délivrés normalement : la politique ne demande aucune action aux destinataires. p=none sert à observer — c'est une étape indispensable, mais un domaine qui y reste indéfiniment demeure aussi usurpable qu'un domaine sans DMARC. La protection commence à p=quarantine et devient complète à p=reject.

Que se passe-t-il si un domaine n'a aucun enregistrement DMARC ?

Les destinataires ne trouvent aucune politique et traitent le courrier selon leurs seules heuristiques : un email usurpant le domaine peut parfaitement arriver en boîte de réception. Le domaine ne reçoit par ailleurs aucun rapport, donc aucune visibilité sur son usage frauduleux. S'y ajoute un effet délivrabilité : les grandes messageries exigent désormais un enregistrement DMARC des expéditeurs en volume — son absence pénalise aussi le courrier légitime.