Qu'est-ce que DMARC, et comment arrête-t-il l'usurpation d'email ?

L'idée clé : l'alignement

L'alignement est ce qui rend DMARC plus fort que SPF et DKIM réunis. Soit un attaquant qui contrôle mechant.com. Il peut configurer un SPF et un DKIM parfaits pour mechant.com — donc son courrier passe ces contrôles. Mais quand il usurpe From: compta@exemple-entreprise.fr, DMARC pose une question plus dure : le domaine authentifié correspond-il au domaine du From: ? Pour l'attaquant, non (mechant.com ≠ exemple-entreprise.fr) : DMARC échoue et la politique du domaine usurpé s'applique. C'est la protection que SPF et DKIM seuls n'ont jamais offerte. Pour la version approfondie, voir notre guide sur comment SPF, DKIM et DMARC fonctionnent ensemble.

À quoi ressemble un enregistrement DMARC

Un enregistrement DMARC est un unique TXT DNS publié sur _dmarc.exemple.fr :

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

Les balises qui comptent le plus :

• p — la politique : none, quarantine ou reject.
• rua — l'adresse qui reçoit les rapports agrégés quotidiens (la boucle de retour).
• adkim / aspf — la rigueur de l'alignement : s (strict) ou r (relaxed).
• sp — la politique pour les sous-domaines (souvent calée sur p).

Les trois politiques

L'application de DMARC est une échelle, et le barreau choisi change ce que les destinataires font du courrier non authentifié :

• p=none — observation seule. Rien ne change pour la délivrabilité ; seuls des rapports sont collectés. C'est là qu'on commence, et hélas là que la plupart des domaines restent à jamais.
• p=quarantine — le courrier non authentifié part en indésirable. Une défense réelle, quoique souple.
• p=reject — le courrier non authentifié est refusé à l'entrée. C'est l'objectif : le courrier usurpé au nom du domaine n'est tout simplement pas délivré.

Seul p=reject arrête réellement l'usurpation. Surveiller en p=none ne protège personne — cela mesure seulement l'ampleur de l'exposition. C'est d'ailleurs ce que confirme notre Observatoire DMARC : dans la plupart des secteurs analysés, la majorité des domaines reste bloquée en p=none, donc visible mais non protégée.

Ce que DMARC garantit — et ce qu'il ne garantit pas

Vu du dirigeant non technique, DMARC se résume à une promesse précise : une fois en p=reject, plus personne ne peut délivrer un email qui affiche exactement le domaine protégé dans le From: sans y avoir été autorisé. C'est une garantie forte — elle protège clients, fournisseurs et salariés contre les fausses factures et les faux ordres de virement émis « au nom de l'entreprise » — mais elle a un périmètre, et le connaître évite un faux sentiment de sécurité.

DMARC ne bloque pas les domaines sosies : un attaquant qui enregistre exemple-entreprise-facturation.fr, ou remplace un « l » par un « 1 », passe à côté du contrôle, puisqu'il usurpe un domaine qui lui appartient réellement. Il n'empêche pas non plus la tromperie sur le nom d'affichage — « Direction Générale » devant une adresse webmail quelconque — ni l'envoi depuis une boîte légitime compromise, qui s'authentifie parfaitement. Et il ne filtre pas le phishing entrant venant des domaines des autres : c'est le DMARC des autres qui protège les boîtes de réception. Ces techniques voisines sont cartographiées dans notre panorama de l'usurpation d'email. DMARC est donc une brique indispensable, pas un bouclier total : il verrouille une identité exacte, et laisse les autres vecteurs à la sensibilisation et au filtrage.

Comment fonctionnent les rapports DMARC

Comme on ne peut pas appliquer une politique sans savoir qui envoie légitimement pour un domaine, DMARC inclut un canal de retour. Les destinataires comme Google, Microsoft et Yahoo envoient des rapports agrégés (XML) à l'adresse rua= chaque jour, résumant comment s'est comporté le courrier se réclamant du domaine : quelles IP l'ont émis, en quel volume, et s'il a passé SPF, DKIM et l'alignement. Ces rapports sont la carte qui sert à trouver et corriger chaque source légitime avant de durcir la politique. On les détaille dans lire les rapports agrégés DMARC.

DMARC évolue : ce que change DMARCbis (2026)

En mai 2026, l'IETF a publié DMARCbis — la version modernisée du standard, répartie en trois RFC : 9989 (le protocole lui-même), 9990 (rapports agrégés) et 9991 (rapports d'échec). Ensemble, elles remplacent la RFC 7489 d'origine et font passer DMARC, pour la première fois, sur la voie des standards (Proposed Standard). Un point rassurant d'emblée : ce n'est pas une rupture. Les enregistrements commencent toujours par v=DMARC1, et aucun changement n'est nécessaire pour rester protégé. Voici l'essentiel de ce qui bouge :

• La balise pct disparaît. Le déploiement « sur un pourcentage du courrier » s'est révélé peu fiable et est retiré, remplacé par un mode test binaire : la balise t (t=y signale « j'expérimente, n'applique pas encore strictement »). Pour monter en puissance, on s'appuie désormais sur les politiques de sous-domaine et l'observation des rapports, plus sur un pourcentage.
• Deux nouvelles balises de sous-domaine. np définit la politique pour les sous-domaines inexistants — une cible d'usurpation classique, car personne ne les surveille — et psd marque les domaines de suffixe public (registres).
• Le DNS Tree Walk remplace la Public Suffix List. Pour déterminer le « domaine organisationnel », DMARCbis interroge le DNS de proche en proche (8 requêtes maximum) au lieu de dépendre d'une liste externe maintenue à la main — plus robuste et plus prévisible.

Le reste — p, sp, rua, ruf, adkim, aspf, fo — garde exactement le même sens. En pratique : les enregistrements actuels restent valides, mais c'est le bon moment pour retirer un pct devenu inutile et poser un np=reject sur les sous-domaines fantômes.

Pourquoi la plupart des domaines restent bloqués en p=none

Publier p=none est facile ; le dépasser est là où les équipes calent. La raison est la peur : les organisations émettent depuis bien plus d'endroits qu'elles ne le croient — la plateforme marketing, le CRM, la facturation, le support, cette appli configurée par une équipe il y a deux ans. Durcir la politique avant que chacune ne soit authentifiée et alignée, c'est risquer d'envoyer son propre courrier légitime en indésirable. Alors l'enregistrement reste en p=none, en surveillance éternelle, pendant que les usurpateurs opèrent librement.

La sortie n'est pas le courage, c'est la méthode : inventorier chaque source depuis les rapports agrégés, aligner chacune en SPF/DKIM, puis monter la politique de quarantine à reject en vérifiant que les rapports restent propres. On déroule toute la séquence dans atteindre p=reject sans casser ses emails.

DMARC dans une démarche de conformité

Pour qui porte la casquette RSSI ou DPO, DMARC a une seconde vie au-delà de la technique : c'est une pièce qui revient dans presque tous les dossiers à défendre. Les questionnaires d'assurance cyber et les évaluations de sécurité fournisseurs demandent de plus en plus explicitement quelle politique DMARC est publiée — et un p=none y fait mauvaise figure. Les grandes messageries grand public l'exigent désormais des expéditeurs en volume, ce qui transforme une simple recommandation en condition de délivrabilité. Plusieurs États l'ont rendu obligatoire pour leurs propres administrations — signe que le standard a quitté depuis longtemps le territoire du « nice to have ». Et dans un système de management de la sécurité de type ISO 27001, une politique DMARC appliquée documente concrètement une mesure de réduction du risque de fraude par usurpation d'identité, tandis que les rapports agrégés fournissent une preuve vérifiable, continue, que la mesure fonctionne réellement — exactement ce qu'un auditeur aime voir.

L'angle conformité a une grande vertu : il donne une échéance à un projet que la technique seule laisse volontiers traîner. Un bon point de départ pour objectiver l'urgence : vérifier noir sur blanc si le domaine peut être usurpé aujourd'hui, et joindre le résultat au dossier.

Où en est le domaine

Pas besoin de deviner. Une vérification gratuite et instantanée de la posture DMARC, SPF et DKIM est accessible via notre analyseur de domaine — il montre la politique actuelle, l'alignement, et une note claire. L'Observatoire DMARC permet par ailleurs de voir comment des secteurs entiers se comparent.

Les erreurs DMARC courantes à éviter

Même les équipes qui publient DMARC trébuchent souvent sur les mêmes détails, et chacun sape discrètement la protection :

• Deux enregistrements DMARC. Comme pour SPF, un domaine ne doit avoir qu'un seul enregistrement TXT _dmarc. Un second rend la politique ambiguë, et les destinataires peuvent ignorer les deux — le domaine reste exposé alors qu'il est réputé couvert. Tout doit fusionner en un seul enregistrement.
• Sauter directement à p=reject. Appliquer avant que chaque source légitime soit alignée est le moyen le plus rapide d'envoyer ses propres factures, reçus et réinitialisations de mot de passe dans le vide. La montée passe par none puis quarantine, avec surveillance des rapports à chaque étape.
• Ignorer la politique de sous-domaine. La balise sp contrôle les sous-domaines, et avec DMARCbis la balise np couvre désormais les sous-domaines inexistants. Une application sur le domaine racine assortie d'un sp permissif laisse les attaquants usurper simplement news.exemple.fr ou mail.exemple.fr. sp (et np) se règlent délibérément, en général comme p.
• Considérer p=none comme la ligne d'arrivée. La surveillance est le départ, pas la destination. Un enregistrement qui ne dépasse jamais none ne protège personne — il documente seulement une exposition.
• Publier sans adresse rua. Sans rapports agrégés, la navigation se fait à l'aveugle : impossible de durcir sereinement sans voir qui envoie légitimement pour le domaine. Un rua doit toujours figurer.
• Oublier les domaines dormants. Les domaines détenus mais d'où rien ne part sont des cibles d'usurpation favorites, précisément parce que personne ne les surveille. Un p=reject strict se publie sur chaque domaine dormant.

Aucune n'est difficile à corriger ; c'est surtout une question de patience et de bonnes données — exactement ce qu'un processus guidé, piloté par les rapports, apporte à la place des suppositions.

Thomas prend le relais

Atteindre p=reject est un projet, mais ce n'est pas obligé d'être un projet interne de plus. Thomas, le RSSI virtuel, nomme chaque source d'envoi depuis les rapports, génère le DNS exact à coller (balises DMARCbis comprises), évalue la préparation du domaine sur des données glissantes, et signale le moment précis où durcir sans risque — de p=none jusqu'à p=reject, sans bloquer un seul email légitime.

Analyser un domaine gratuitement ou créer un compte et laisser Thomas faire le gros du travail.