2,77 milliards de dollars. C’est ce que le FBI a comptabilisé en pertes Business Email Compromise pour la seule année 2024, selon le rapport annuel IC3. Une fraction de ces attaques a réussi alors que les organisations visées avaient DMARC en place. Ce n’est pas un paradoxe : DMARC ne protège que contre une seule forme précise d’usurpation, et les attaquants le savent. Comprendre ses limites exactes (celles que la RFC 7489 documente elle-même) est la condition pour ne pas surestimer sa couverture réelle.
Ce que DMARC fait (et rien d’autre)
DMARC (Domain-based Message Authentication, Reporting and Conformance) est un protocole qui s’appuie sur SPF et DKIM pour donner des instructions aux serveurs de messagerie destinataires : rejeter, mettre en quarantaine ou livrer les emails dont l’identité de domaine ne peut être vérifiée. Avec une politique p=reject, tout message dont l’en-tête From ne correspond pas à une source SPF ou DKIM autorisée est bloqué. Cette protection est réelle. Mais son périmètre se limite strictement à l’usurpation exacte du domaine. La RFC 7489 l’écrit noir sur blanc : « DMARC n’aborde pas l’utilisation de noms de domaines visuellement similaires ni l’abus du display name lisible par l’humain. » Cinq vecteurs d’attaque courants restent donc hors de portée.
Le display name spoofing lui échappe complètement
Un email dont l’en-tête affiche « Service Client Amazon <phishing@n0treal.com> » passe DMARC sans problème. DMARC ne vérifie que le domaine technique de l’expéditeur, pas le nom affiché dans le client de messagerie. L’attaquant conserve un nom d’expéditeur identique à une marque de confiance tout en utilisant son propre domaine, correctement authentifié. Pour l’utilisateur final, la ligne « De : » affiche exactement ce que l’attaquant a décidé d’y mettre. Ce vecteur ne nécessite aucune infrastructure compromise et contourne tous les contrôles DMARC par définition : le domaine technique n’est pas usurpé, il est simplement sans rapport avec le nom affiché.
Les domaines cousins ne sont pas concernés
DMARC protège example.com. Il ne dit rien sur examp1e.com, example-support.com ou example.fr. Ces domaines dits « cousins » (typosquatting, lookalike domains) peuvent publier leur propre enregistrement DMARC valide, avec SPF et DKIM correctement configurés, et envoyer des emails parfaitement authentifiés depuis un domaine qui ressemble à s’y méprendre à celui d’une organisation légitime. Le problème est documenté par PowerDMARC : ces domaines « contournent fréquemment la portée de DMARC » parce que le protocole n’a aucune prise sur ce qu’il ne contrôle pas. La surveillance des domaines cousins enregistrés relève d’autres catégories d’outils : brand monitoring, veille DNS, analyse des certificats SSL récemment émis.
Un compte compromis passe DMARC sans alerte
Si un attaquant accède à une boîte email légitime via credential stuffing, phishing initial ou fuite de données, tous ses messages sortants passent SPF, DKIM et DMARC normalement. Le message vient du bon domaine, signé avec la bonne clé DKIM, depuis une IP autorisée. DMARC ne distingue pas un employé légitime d’un attaquant qui a volé ses identifiants. C’est précisément le modus operandi du BEC (Business Email Compromise) : les 2,77 milliards de dollars de pertes recensés par le FBI en 2024 concernent des attaques où l’infrastructure email des victimes était souvent correctement configurée. DMARC n’a rien vu parce qu’il n’y avait techniquement rien à voir.
Le transfert d’emails peut casser l’authentification
Quand un message traverse un service intermédiaire (alias d’entreprise, liste de diffusion comme Mailman ou Listserv, redirection automatique), SPF échoue presque systématiquement : l’IP du relais n’est pas listée dans l’enregistrement SPF du domaine d’origine. Si la liste de diffusion modifie le corps du message (pied de page ajouté, disclaimer inséré), DKIM peut aussi échouer. Des emails parfaitement légitimes se retrouvent rejetés ou mis en quarantaine. Selon dmarcian, 21 % des échecs DMARC observés dans les rapports agrégés proviennent de ce bris de DKIM par modification de contenu. La solution standard est ARC (Authenticated Received Chain), mais elle requiert une configuration explicite côté relais. La majorité des listes de diffusion ne l’ont pas encore implémentée.
Les sous-domaines peuvent rester des angles morts
Un enregistrement DMARC publié sur example.com ne protège pas automatiquement tous ses sous-domaines. Par défaut, mail.example.com ou newsletter.example.com héritent de la politique du domaine parent, sauf si un enregistrement DMARC spécifique existe pour ce sous-domaine, auquel cas c’est ce dernier qui prévaut, même s’il est en p=none. Un sous-domaine oublié configuré en monitoring annule la protection p=reject du domaine principal pour ce périmètre. Valimail indique que plus de 80 % des domaines n’ont pas de politique DMARC contraignante ; parmi ceux qui en ont une, la cohérence entre domaine principal et sous-domaines est rarement vérifiée de manière systématique. Les domaines « parking » non utilisés restent aussi des surfaces d’usurpation disponibles.
DMARC dans une stratégie réaliste
Ces cinq limites ne rendent pas DMARC inutile. En novembre 2025, Gmail a commencé à rejeter les emails bulk non conformes, et Valimail estime que l’enforcement DMARC a éliminé 265 milliards de messages non authentifiés en 2024. C’est un socle nécessaire. Mais ce n’est qu’un socle. Une couverture réaliste demande en plus : une solution capable d’analyser le display name et de détecter les domaines cousins, une protection contre la compromission de comptes (MFA obligatoire, détection d’anomalie comportementale), une configuration ARC pour les flux de transfert légitimes, et un audit régulier des sous-domaines y compris ceux considérés comme « inactifs ». DMARC ferme une porte. Avant de considérer le travail terminé, il faut compter les autres.
