DMARC pour les banques : pourquoi les marques financières sont des cibles de choix

Le piège marque grand public vs domaine corporate

Il y a une subtilité propre aux grandes institutions, et il vaut la peine de la souligner car elle masque une exposition réelle. Une banque a souvent un domaine corporate soigné et bien protégé (celui des communiqués et des pages investisseurs) tandis que le domaine de marque grand public — celui depuis lequel les clients reçoivent réellement du courrier et qu'ils reconnaîtraient — accuse du retard en p=none. Les équipes sécurité pointent le domaine corporate protégé ; les attaquants visent le domaine grand public exposé.

Évaluer une banque — ou sa propre organisation — suppose de vérifier le domaine que les clients voient dans leur boîte, pas seulement la maison mère corporate. C'est l'adresse que la fraude usurpera. Nos pages de vérification par domaine montrent le verdict du domaine exact saisi, pour distinguer les deux.

Pas seulement les clients : les équipes et les contreparties

L'usurpation d'un domaine bancaire ne vise pas que le grand public. Le même From: falsifié sert aussi contre la banque elle-même : un faux message « de la direction fraude » adressé à un conseiller en agence, ou « de la trésorerie » envoyé à un client entreprise pour faire modifier des coordonnées de paiement. Ces attaques ciblées coûtent cher précisément parce qu'elles empruntent l'identité interne la plus crédible qui soit — personne ne conteste un ordre qui semble venir de sa propre maison. p=reject protège aussi ces flux, à une condition souvent oubliée : que la passerelle entrante de la banque évalue réellement DMARC. Publier une politique stricte protège le monde entier contre le domaine de l'établissement ; l'honorer à l'entrée protège ses propres équipes contre lui. Les deux gestes vont ensemble, et le second ne dépend que d'elle.

DORA, NIS2 et le vent réglementaire favorable

Pour les entités financières de l'UE, ce n'est plus seulement une question de sécurité — c'est de plus en plus une question de conformité. DORA (Digital Operational Resilience Act) relève les attentes en matière de gestion du risque informatique et de protection contre l'intrusion pour le secteur financier, et NIS2 élargit les obligations de cybersécurité à travers les industries critiques. Aucun ne nomme « DMARC » explicitement, mais l'authentification email est un contrôle évident et auditable pour les attentes anti-phishing et de résilience opérationnelle qu'ils posent. À cela s'ajoutent les exigences expéditeurs de Gmail et Yahoo qui font déjà de DMARC un prérequis pour quiconque envoie en volume — ce que fait toute banque. Nous détaillons ailleurs ce que DORA exige concrètement côté messagerie, et comment NIS2 se traduit en obligations email.

La direction est sans ambiguïté : le DMARC appliqué passe de « bonne hygiène de sécurité » à « contrôle attendu ». Les banques qui y arrivent tôt transforment une obligation imminente en avantage de confiance. Et dans un établissement déjà certifié ISO 27001, l'argument interne est à moitié construit : DMARC s'inscrit naturellement dans les contrôles de l'Annexe A.

Comment une banque devrait aborder DMARC

La méthode est celle de tout grand expéditeur, exécutée avec une rigueur supplémentaire car le parc d'envoi est vaste :

1. Inventorier tout le parc d'envoi. Chaque métier, chaque région, chaque plateforme tierce (relevés, marketing, alertes fraude, signature électronique, sondages). Publier DMARC en p=none et exploiter les rapports agrégés fait apparaître des sources insoupçonnées — il y en a toujours.
2. Aligner chaque source légitime. Régler SPF et DKIM pour chaque plateforme jusqu'à un passage aligné. L'alignement DKIM est la cible durable, surtout avec le transfert.
3. Traiter chaque domaine de marque séparément. Le domaine grand public mérite la même application que le corporate — voire davantage, puisque c'est celui auquel les clients font confiance.
4. Monter délibérément. Passer à quarantine, puis à reject, en surveillant les rapports à chaque étape. (Le déploiement « par pourcentage » via pct est retiré par DMARCbis au profit du mode test t=y — voir ci-dessous.) La séquence complète est dans atteindre p=reject sans casser ses emails.
5. Y rester. Les parcs d'envoi dérivent — de nouveaux prestataires apparaissent. Une surveillance continue maintient le domaine en application au lieu de régresser en silence.

DMARCbis et les sous-domaines bancaires

DMARCbis (RFC 9989, mai 2026) tombe à pic pour les banques, qui exploitent souvent des dizaines de sous-domaines — alertes., releves., secure., news. — et en laissent autant d'inexistants mais usurpables. La nouvelle balise np fixe justement la politique des sous-domaines qui n'existent pas : un np=reject ferme d'un coup une surface d'attaque que sp seul ne couvrait pas, et sans aucun risque pour le courrier légitime, puisque rien ne part de ces sous-domaines. Pour une marque financière, c'est un durcissement à coût quasi nul. DMARCbis remplace par ailleurs la Public Suffix List par un DNS Tree Walk (huit requêtes maximum) pour identifier le domaine organisationnel — plus prévisible sur les arborescences de domaines complexes des grands groupes. Rien à refondre : l'enregistrement existant reste valide, c'est l'occasion d'ajouter np et de retirer un pct devenu inutile.

Au-delà de reject : BIMI et le logo vérifié

Atteindre p=reject débloque une chose que les banques en particulier devraient vouloir : BIMI (Brand Indicators for Message Identification). BIMI permet d'afficher le logo vérifié de l'établissement à côté de ses messages dans les boîtes compatibles — une marque de confiance visible, placée exactement là où les clients décident si un email est authentique. Pour une marque dont toute l'activité repose sur la confiance, cet emplacement est un bien précieux.

Le détail crucial : BIMI exige DMARC en application (quarantine ou, idéalement, reject). Pas de logo affiché avant le travail décrit dans cet article. Cela transforme le projet de prévention de l'usurpation en gain de visibilité de marque : le même p=reject qui arrête l'usurpation fait aussi gagner le logo qui rend le courrier légitime instantanément reconnaissable — et fait paraître une falsification sans logo visiblement suspecte.

La plupart des fournisseurs qui honorent BIMI attendent aussi un VMC (Verified Mark Certificate), qui lie cryptographiquement le logo à une marque déposée. C'est naturel pour les marques financières établies, qui détiennent presque toujours des marques enregistrées. La séquence est donc sans ambiguïté : aligner chaque source, atteindre p=reject, puis publier BIMI avec un VMC.

C'est le dernier barreau de l'échelle. p=none ne fait que documenter l'exposition ; p=quarantine et p=reject la referment ; BIMI convertit cette application durement acquise en un signal d'authenticité visible par le client, que les concurrents bloqués en p=none ne peuvent tout simplement pas afficher. Il vaut la peine de planifier l'étape BIMI dès le départ d'un programme DMARC — non pour l'activer en premier, mais parce que savoir que le logo est la récompense aide à justifier le travail d'application auprès des parties prenantes qui tiennent autant à la marque qu'à la sécurité.

Vérifier une banque — ou son propre domaine

Pour savoir où en est une banque donnée aujourd'hui, un passage dans notre analyseur gratuit rend un verdict instantané, et l'Observatoire permet de comparer tout un marché d'un coup d'œil. Côté institution financière, le point de départ est le domaine depuis lequel les clients reçoivent réellement du courrier.

Amener un grand parc multi-domaines à p=reject est un vrai chantier — et c'est exactement ce que Thomas, le RSSI virtuel, est conçu pour porter. Il nomme chaque source d'envoi sur chaque domaine, génère le DNS précis à publier (balises DMARCbis comprises), évalue la préparation par domaine sur des données glissantes, et indique quand chacun peut être appliqué sans risque.

Analyser un domaine gratuitement · explorer l'Observatoire · commencer avec Thomas. Pour une première approche du sujet, qu'est-ce que DMARC pose les bases.