Ce que DMARC ne protège pas

DMARC répond à une question et une seule : le domaine que je vois dans le champ expéditeur de ce message est-il le même que celui qui a réussi SPF ou DKIM ? Si la réponse est non, la politique publiée décide du sort du message.

Cette question est étroite, et c’est voulu. Le champ contrôlé est le Header-From, la partie après le @, comparée caractère par caractère. Tout ce qui n’est pas exactement votre nom de domaine sort du périmètre, quelle que soit la ressemblance.

La norme le dit elle-même, dès sa quatrième page. Ce n’est pas un défaut d’implémentation ni une réserve d’usage : c’est le périmètre déclaré du protocole.

Un domaine sosie est un nom de domaine réel, enregistré par le fraudeur, choisi pour ressembler au vôtre. Il en est propriétaire. Il y publie donc ses propres SPF, DKIM et DMARC, parfaitement valides. Ses messages réussissent tous les contrôles techniques, parce qu’ils ne mentent sur rien : ils viennent bien du domaine qu’ils affichent.

Votre configuration ne peut rien y faire, pour une raison simple : un enregistrement DNS ne parle que du domaine sur lequel il est publié. Vous n’avez aucune autorité sur un domaine que vous ne possédez pas.

La variante la plus dure est l’homoglyphe : un caractère d’un autre alphabet au dessin identique. Le « а » cyrillique et le « a » latin s’affichent exactement pareil. Le domaine correspondant n’est pas ressemblant, il est visuellement indiscernable.

Le champ expéditeur d’un message contient deux choses : un nom affiché, libre, et une adresse. Votre logiciel de messagerie montre le premier en gros et cache souvent la seconde. Aucune norme d’authentification ne contrôle le nom affiché, parce qu’il n’en existe aucune qui le pourrait : c’est du texte.

From: "Marie Dupont | Cabinet Exemple" <compta@fournisseur-inconnu.net>

Ce message passe DMARC sans difficulté : le domaine réellement utilisé est celui du fraudeur, correctement configuré. Sur un téléphone, où la plupart des clients n’affichent que le nom, le destinataire voit « Marie Dupont | Cabinet Exemple » et rien d’autre.

Une variante plus retorse encore consiste à mettre votre adresse e-mail réelle dans le nom affiché. Le lecteur voit alors son interlocuteur habituel, adresse comprise, tandis que l’adresse effective reste invisible.

Si un fraudeur obtient le mot de passe d’une de vos boîtes, il n’usurpe plus rien : il est vous. Ses messages partent de vos serveurs, avec vos enregistrements, et votre propre DKIM les signe. DMARC les valide, comme il doit le faire.

C’est le scénario le plus coûteux, parce que le fraudeur lit d’abord. Il apprend les noms, les montants, les échéances, le ton des échanges, puis il intervient dans une conversation existante au bon moment. Aucune protection de domaine n’a de prise ici : la réponse est l’authentification à deux facteurs, la surveillance des connexions et les règles de validation des virements.

• Les transferts. Un message transféré casse SPF, car l’adresse IP change. Seul DKIM survit, et seulement si le message n’a pas été modifié. Les listes de diffusion qui réécrivent l’objet ou ajoutent un pied de page cassent aussi la signature. La réponse partielle est ARC, que tous les fournisseurs n’honorent pas.
• L’intérieur de l’entreprise. Un message déposé directement dans une boîte par un serveur interne mal configuré peut ne jamais être soumis à l’évaluation DMARC.
• Le courrier entrant. DMARC protège votre domaine chez les autres. Il ne filtre pas ce que vous recevez : cela, c’est le travail de votre passerelle de messagerie.
• Les fournisseurs qui n’appliquent pas la politique. La grande majorité du volume mondial est traitée par des serveurs qui honorent DMARC, mais pas la totalité. Un petit serveur d’entreprise peut parfaitement l’ignorer.
• Le canal. Une fraude au virement peut arriver par téléphone, par SMS ou par courrier. Le compte bancaire visé, lui, ne change pas.

Rien de ce qui précède n’est un argument contre DMARC. C’est un argument contre l’idée qu’il suffit. L’usurpation exacte reste la technique la moins chère et la plus employée, précisément parce qu’elle ne demande ni achat de domaine, ni patience, ni vol de mot de passe. La supprimer force le fraudeur à passer à des méthodes plus lentes, plus coûteuses et bien plus visibles.

Il y a une seconde raison, moins discutée : un domaine en p=reject renvoie des rapports quotidiens. Une campagne montée contre vous devient visible dans les jours qui suivent, avant même qu’un client ne se plaigne. C’est le seul dispositif de ce dossier qui vous prévient.

1. La surveillance des dépôts de domaines ressemblants, par les journaux de transparence des certificats. Un domaine sosie repéré à sa création est un domaine sosie que l’on peut signaler avant qu’il ne serve.
2. Une règle interne de validation des changements de coordonnées bancaires : rappel systématique au numéro connu du fournisseur, jamais à celui indiqué dans le message.
3. L’authentification à deux facteurs sur toutes les boîtes, sans exception de confort pour la direction.
4. Une sensibilisation courte et concrète, centrée sur le nom affiché et le domaine sosie, puisque ce sont précisément les deux cas que la technique laisse passer.

L’ordre a son importance : les deux premiers points coûtent quelques heures et couvrent la plus grande part de ce que DMARC laisse ouvert.