Un enregistrement DMARC bloque-t-il vraiment le spoofing ou seulement les campagnes que le service marketing envoie encore depuis un routeur mal aligné ? DMARC (Domain-based Message Authentication, Reporting and Conformance) est un enregistrement DNS qui indique aux serveurs receveurs, Gmail, Outlook, Yahoo, quelle politique appliquer à un email qui échoue à l’alignement SPF ou DKIM. Publié seul, sans les deux protocoles qu’il supervise, il ne bloque rien. Fin 2025, 83,9% des domaines analysés par Red Sift n’avaient aucun enregistrement DMARC publié, sur un échantillon de 73,3 millions de domaines. La suite détaille la syntaxe exacte de l’enregistrement, les trois politiques disponibles et la lecture des rapports rua.
Qu’est-ce que DMARC ?
Un domaine qui publie SPF et DKIM sans _dmarc laisse chaque serveur receveur décider seul de la conduite à tenir face à un échec d’authentification. Certains rejettent, d’autres livrent quand même en marquant l’email suspect, d’autres ne changent rien du tout. DMARC ferme cette ambiguïté : le propriétaire du domaine fixe lui-même la politique, dans un enregistrement TXT publié sur l’hôte _dmarc.votredomaine.com. Le standard est documenté dans la RFC 7489 depuis 2015 mais son adoption reste inégale. Les grands comptes cotés dépassent 85% de couverture selon les analyses par pays, la moyenne mondiale plafonne sous 15% (Red Sift, 2025). L’écart tient surtout à la complexité perçue de la syntaxe, rarement à sa difficulté réelle.
Pourquoi DMARC est important
Un domaine sans politique DMARC laisse n’importe qui envoyer un email signé de son nom, sans qu’aucun mécanisme ne prévienne le destinataire. C’est le vecteur principal du phishing par usurpation de marque, celui qui fait cliquer un comptable sur une fausse facture censée venir de son propre fournisseur. Le tableau de bord d’un SaaS d’emailing peut afficher une délivrabilité correcte sans rien dire de ce qu’un tiers envoie hors de cette plateforme : la délivrabilité mesurée en interne et la surface d’usurpation externe restent deux mesures différentes. Un domaine ciblé par une campagne de spoofing voit aussi sa sender reputation se dégrader auprès des filtres Gmail et Outlook, un signal que révèlent ensuite les métriques de postmaster Gmail, même quand aucun email frauduleux ne part réellement de l’infrastructure de l’entreprise. Les filtres associent le nom de domaine visible, pas l’IP d’envoi.
Comment DMARC s’appuie sur SPF et DKIM
DMARC ne remplace ni SPF ni DKIM. Il les supervise, en s’appuyant sur leurs résultats. SPF vérifie que le serveur émetteur est autorisé à envoyer pour le domaine indiqué dans l’enveloppe MAIL FROM. DKIM signe le contenu du message avec une clé cryptographique, ce qui permet de détecter toute modification en transit. Un email peut échouer l’un et passer l’autre : DMARC exige qu’au moins un des deux réussisse et surtout que le domaine vérifié par ce protocole corresponde au domaine affiché dans l’en-tête From, celui que voit le destinataire. Cette correspondance porte un nom, l’alignement.
L’alignement peut être strict ou relâché, réglé par les balises aspf et adkim de l’enregistrement DMARC. En mode relâché, valeur par défaut, un sous-domaine comme newsletter.entreprise.com aligne avec entreprise.com. En mode strict, seule une correspondance exacte est acceptée. La majorité des plateformes d’envoi tierces publient leurs propres enregistrements SPF et signent avec leurs propres clés DKIM, qu’il s’agisse d’un routeur transactionnel ou d’un CRM externe. Sans configuration explicite du sous-domaine d’envoi côté DNS, ces emails échouent à l’alignement même quand ils sont parfaitement légitimes. C’est la cause la plus fréquente d’un taux de rejet DMARC qui grimpe après l’ajout d’un nouvel outil marketing, sans qu’aucune campagne de phishing n’en soit responsable.
Créer un enregistrement DMARC : syntaxe et exemple
Configurer un enregistrement DMARC commence toujours par le choix du bon hôte DNS. L’enregistrement se publie comme un TXT classique, sur l’hôte _dmarc de la zone DNS du domaine, jamais sur le domaine racine. Voici un exemple commenté, pensé pour un déploiement progressif :
v=DMARC1; p=quarantine; pct=50; rua=mailto:rua@entreprise.com; ruf=mailto:ruf@entreprise.com; aspf=r; adkim=r; sp=none
Chaque balise a un rôle précis. v fixe la version du protocole, toujours DMARC1. p définit la politique appliquée au domaine. pct fixe le pourcentage de messages non conformes concernés par cette politique. rua indique l’adresse qui reçoit les rapports agrégés quotidiens. ruf indique l’adresse des rapports forensiques, rarement honorée par les grands FAI. sp fixe la politique appliquée aux sous-domaines qui n’ont pas leur propre enregistrement.
Pour créer et vérifier l’enregistrement :
- Identifier tous les émetteurs légitimes du domaine (ESP, CRM, facturation, helpdesk) et confirmer que chacun publie SPF ou signe en DKIM.
- Créer une adresse dédiée aux rapports rua.
- Publier l’enregistrement TXT sur _dmarc avec p=none pendant au moins deux à quatre semaines, en observant uniquement.
- Lire les premiers rapports agrégés pour repérer les sources qui échouent à l’alignement et les corriger une par une.
- Relever la politique par palier, pct=25 puis pct=50 puis pct=100, avant de passer en quarantine puis en reject.
Un enregistrement mal formé, une balise en double ou une adresse rua invalide, n’empêche généralement pas sa publication en DNS. Il empêche silencieusement la réception des rapports, ce qui rend le pilotage impossible sans qu’aucune alerte ne prévienne l’administrateur.
Les trois politiques DMARC et le déploiement progressif
Trois valeurs sont possibles pour la balise p. none ne change rien à la livraison : l’email suit son cours normal, seul le rapport rua enregistre l’échec. quarantine envoie l’email non conforme vers le dossier spam ou équivalent du destinataire. reject bloque l’envoi avant même qu’il atteigne la boîte de réception, avec un rejet SMTP renvoyé à l’expéditeur.
Passer directement en p=reject sans étape d’observation bloque aussi les emails légitimes non alignés, liste de diffusion qui réécrit l’en-tête From, routeur CRM tiers mal configuré, service de facturation externalisé. Le déploiement recommandé commence en observation avec none, avant de monter progressivement vers la mise en quarantaine, pour terminer par le rejet complet, en augmentant pct par paliers. Une politique reject à 100% ouvre aussi la voie au déploiement du BIMI, le logo de marque affiché dans la boîte de réception de Gmail et Yahoo, qui exige un DMARC strict comme prérequis technique.
Lire les rapports DMARC : rua et ruf
Les rapports rua arrivent en XML compressé. Chaque FAI qui a reçu du courrier du domaine en envoie généralement un par jour, listant les IP émettrices, le volume traité, le résultat d’alignement SPF et DKIM et la politique appliquée. La lecture manuelle reste possible pour un domaine avec deux ou trois émetteurs. Au-delà d’une dizaine de sous-domaines actifs et de plusieurs plateformes d’envoi, le volume de lignes XML rend une lecture ligne par ligne peu réaliste sans outil de parsing dédié.
Les rapports ruf, eux, détaillent un email précis qui a échoué, en-têtes complets inclus. Gmail et Yahoo ne les envoient pas, pour des raisons de confidentialité des données personnelles contenues dans les en-têtes. Seule une minorité de fournisseurs de messagerie plus modestes les honore encore. Le guide complet pour lire un rapport DMARC agrégé sans se tromper détaille le parsing XML champ par champ.
Ce que DMARC ne couvre pas
DMARC protège le domaine exact publié dans l’enregistrement, rien de plus. Un email envoyé depuis entreprise-support.com au lieu d’entreprise.com, un domaine visuellement proche enregistré par un attaquant, passe entièrement à côté du dispositif : aucun SPF, DKIM ou DMARC ne couvre un domaine que l’entreprise ne possède pas. Ce typosquatting reste l’angle mort le plus fréquent des déploiements DMARC, y compris ceux configurés en p=reject. La liste complète des limites, du contenu du message à la protection des domaines non enregistrés, mérite d’être connue avant d’annoncer en interne qu’un domaine est désormais protégé.
Qui doit publier un enregistrement DMARC en 2026
Depuis le 1er février 2024, Google exige une authentification SPF et DKIM alignée, plus un enregistrement DMARC au moins en p=none, pour tout expéditeur envoyant 5 000 messages ou plus par 24 heures vers des comptes Gmail personnels. Microsoft a suivi à partir du 5 mai 2025 sur Outlook.com, Hotmail et Live.com : au-delà du même seuil, les emails non authentifiés sont rejetés au niveau SMTP avec l’Enhanced Status Code 550 5.7.15, plutôt que redirigés vers le dossier spam. Le complaint rate remonté via les feedback loops FAI doit rester sous 0,3%, avec un seuil recommandé sous 0,1% pour éviter tout filtrage renforcé.
Google précise que le seuil de 5 000 messages s’évalue sur une fenêtre glissante de 24 heures : un expéditeur qui le dépasse une seule fois reste soumis aux mêmes exigences que s’il l’atteignait chaque jour.
En dessous de ce seuil, rien n’oblige légalement à publier DMARC. Mais un domaine actif en B2B, même à faible volume, reste une cible de choix pour l’usurpation : la facture frauduleuse qui vise un fournisseur ne se soucie pas du volume d’envoi de la victime. Encore un outil de plus dans la stack, diront certains en découvrant qu’il faut aussi surveiller le taux de hard bounce et la sender reputation associés au domaine. DMARC ne remplace rien de ce qui existe déjà. Il consomme surtout les données déjà présentes dans Google Postmaster Tools. Nettoyer la liste de diffusion, une pratique de list hygiene élémentaire, avant de resserrer la politique vers DMARC reject évite de confondre une adresse qui rebondit avec un échec d’alignement mal diagnostiqué, une confusion qui retarde le déploiement de plusieurs semaines dans la plupart des cas observés.
Combien de temps s’est écoulé depuis la dernière lecture du rapport rua de ce domaine ?
