Sur 32 entreprises et organismes français touchés par une fuite de données rendue publique entre septembre et début novembre 2026, 21 ne protègent pas leur domaine contre l'usurpation par email. 16 publient un DMARC en p=none, qui ne demande aucune action aux messageries, et 5 n'ont aucun DMARC. Concrètement, un fraudeur qui a récupéré le fichier clients peut écrire à ces clients avec l'adresse exacte de l'entreprise. Rien dans le DNS ne demande à leur messagerie de refuser le message. Seules 11 organisations sur 32 sont réellement protégées.
Après une fuite, le risque immédiat pour les clients est l'hameçonnage ciblé : le pirate connaît leur nom, leur email et parfois leur historique de commandes. Nous avons voulu savoir si les domaines des organisations touchées bloquaient au moins l'usurpation directe de leur adresse.
L'essentiel
- 11 sur 32 (34 %) sont protégés : 9 en
p=reject, 2 en p=quarantine appliqué à 100 % des messages.
- 16 sur 32 (50 %) publient un DMARC en
p=none : le domaine est surveillé, mais pas protégé.
- 5 sur 32 (16 %) n'ont aucun enregistrement DMARC. Pour 4 d'entre eux, ni SPF ni DMARC n'indiquent de refuser un faux message.
- 3 sur 32 ont activé DNSSEC avec une chaîne de confiance complète.
Pourquoi cette étude
Une fuite de données ne s'arrête pas au jour de l'annonce. Les fichiers circulent, sont revendus et servent ensuite à des campagnes d'hameçonnage. Les messages d'information envoyés aux victimes le disent presque tous : méfiez-vous des emails, SMS et appels inattendus.
Le faux mail le plus crédible est celui qui semble venir de l'entreprise elle-même, avec son adresse exacte. C'est précisément ce que DMARC permet d'empêcher. Un domaine en p=reject demande aux messageries de rejeter tout message qui prétend venir de lui sans être authentifié. Un domaine en p=none ou sans DMARC ne demande rien.
Nous avons donc posé une question simple : les organisations dont les clients sont aujourd'hui exposés ont-elles fermé cette porte ?
La méthode
La liste
La liste a été établie à partir des fuites de données et cyberattaques rendues publiques entre le 1er septembre et le 4 novembre 2026, telles que rapportées par la presse et les sites de veille spécialisés. Nous avons retenu les organisations françaises qui ont une relation directe avec des clients, des usagers ou des adhérents, et dont le domaine principal est identifiable. Les fuites confirmées par l'organisation (24) comme les fuites seulement revendiquées par un pirate (8) sont incluses : dans les deux cas, les clients reçoivent des alertes et deviennent des cibles.
Nous ne publions pas cette liste. L'étude porte sur un phénomène. Elle ne cherche pas à désigner des entreprises qui viennent déjà de subir une attaque.
Les mesures
Les mesures ont été faites le 5 novembre 2026, entre 1 h 30 et 1 h 40 (heure de Paris), avec dig et le résolveur public 1.1.1.1. Les réponses vides ont été vérifiées sur deux autres résolveurs (8.8.8.8 et 9.9.9.9). Une seconde série complète a été lancée environ cinq minutes plus tard pour écarter les réponses ambiguës.
Pour chaque domaine, nous avons relevé :
- l'enregistrement DMARC (
_dmarc.domaine) : politique p=, politique des sous-domaines sp=, pourcentage pct=, présence d'une adresse de rapports rua= ;
- l'enregistrement SPF : présence, mécanisme final (
-all, ~all, ?all), nombre d'include, doublons éventuels ;
- la présence d'un enregistrement MX ;
- DNSSEC : présence d'un enregistrement DS chez le registre, de signatures RRSIG, et du drapeau
ad renvoyé par un résolveur validant.
dig +short TXT _dmarc.exemple.fr @1.1.1.1
dig +short TXT exemple.fr @1.1.1.1
dig +short MX exemple.fr @1.1.1.1
dig +dnssec SOA exemple.fr @1.1.1.1
Ce qui compte comme « protégé »
Nous considérons un domaine comme protégé s'il publie p=reject, ou p=quarantine appliqué à 100 % des messages. Sans balise pct, la norme applique la politique à 100 % des messages (RFC 7489). Un domaine en p=none est compté comme non protégé, même s'il reçoit des rapports : p=none demande explicitement aux messageries de ne rien faire.
Les résultats en un tableau
| Constat | Organisations | Ce que ça signifie |
|---|
DMARC p=reject | 9 / 32 | Les faux messages à l'adresse exacte sont rejetés |
DMARC p=quarantine à 100 % | 2 / 32 | Les faux messages vont en courrier indésirable |
DMARC p=none | 16 / 32 | Aucune consigne : la messagerie décide seule |
| Pas de DMARC | 5 / 32 | Aucune consigne |
| SPF absent | 2 / 32 | Aucun serveur autorisé déclaré |
SPF en -all | 16 / 32 | Les serveurs non listés sont déclarés non autorisés |
SPF en ~all | 11 / 32 | Échec « doux » : le message est généralement accepté |
SPF en ?all | 3 / 32 | Neutre : n'importe quel serveur est toléré |
| Double enregistrement SPF | 0 / 32 | Aucun cas |
| DNSSEC actif (DS + signatures) | 3 / 32 | Réponses DNS signées et vérifiables |
Par grand secteur
Pour éviter toute identification, les secteurs sont regroupés en quatre ensembles.
| Secteur | Organisations | Protégées | p=none | Sans DMARC |
|---|
| Commerce en ligne et restauration | 11 | 3 | 5 | 3 |
| Énergie, banque, assurance, mutuelle | 7 | 4 | 2 | 1 |
| Secteur public et parapublic | 5 | 2 | 3 | 0 |
| Services, automobile, santé, immobilier, loisirs | 9 | 2 | 6 | 1 |
| Total | 32 | 11 | 16 | 5 |
L'énergie et la finance s'en sortent le mieux : 4 organisations sur 7 sont en p=reject, dont les deux fournisseurs d'énergie de l'échantillon. Le commerce en ligne est le secteur le plus exposé : 8 enseignes sur 11 ne sont pas protégées, alors que leurs clients reçoivent chaque semaine des emails de commande, de livraison et de promotion. Un faux mail de « remboursement » s'y glisse facilement.
p=none : la surveillance sans la protection
La moitié de l'échantillon publie p=none. C'est l'étape normale d'un déploiement : on observe les rapports, on recense les services qui envoient des emails au nom du domaine, puis on passe à quarantine et reject. Le problème, c'est de rester à cette étape.
Sur les 16 domaines en p=none, 11 reçoivent des rapports agrégés (rua). Ces organisations ont donc les données pour savoir qui envoie des emails en leur nom. Les 5 autres n'ont même pas d'adresse de rapports : elles publient un DMARC qui ne protège rien et ne leur apprend rien. Pour exploiter ces rapports, voir notre guide pour lire un rapport DMARC.
Le SPF montre le même relâchement. 14 domaines terminent leur SPF par ~all ou ?all, qui ne demandent pas de rejeter un serveur inconnu. Sans DMARC strict, ces mécanismes laissent le dernier mot aux filtres anti-spam du destinataire.
Ce que ça permet concrètement à un fraudeur
Prenons un scénario type. Une enseigne de vente en ligne annonce une fuite : noms, emails, adresses et historiques de commandes. Son domaine, exemple.fr, publie :
_dmarc.exemple.fr. TXT "v=DMARC1; p=none; rua=mailto:dmarc@exemple.fr"
exemple.fr. TXT "v=spf1 include:_spf.prestataire.com ~all"
Le fraudeur envoie depuis son propre serveur un message signé service-client@exemple.fr : « Suite à l'incident de sécurité, un remboursement de 39,90 € est disponible sur votre commande du 12 octobre. Confirmez votre carte bancaire ici. » Le message échoue à SPF et à DKIM. Mais le domaine dit aux messageries de ne rien faire. Le message peut arriver dans la boîte de réception, avec la bonne adresse d'expéditeur et des détails exacts tirés du fichier volé.
Avec p=reject, ce même message est rejeté par les messageries qui appliquent DMARC, ce que font les grands fournisseurs. Le fraudeur doit alors passer à un domaine ressemblant, ce qui rend l'arnaque plus facile à repérer. Les gestes à transmettre aux clients après une fuite sont détaillés dans notre article sur les faux mails au nom de votre entreprise après une fuite.
Les bons réflexes observés
Plusieurs organisations de l'échantillon montrent ce qu'une configuration solide donne en pratique :
- Un domaine qui n'envoie pas de mail est verrouillé. Une organisation publie un MX nul (
0 .), un SPF réduit à v=spf1 -all et un DMARC en p=reject. Personne ne peut envoyer de message valide en son nom depuis ce domaine.
- Les sous-domaines sont couverts. Deux organisations ajoutent
sp=reject. Sans balise sp, les sous-domaines héritent de la politique du domaine principal, ce qui suffit si elle est stricte.
- L'alignement est strict. Deux domaines exigent
adkim=s et aspf=s : la signature doit correspondre au domaine exact, pas seulement au domaine parent.
Méthode et limites
- DMARC ne bloque pas les domaines cousins. Un fraudeur peut enregistrer
exemple-remboursement.fr ou exemple.fr-client.com. DMARC protège uniquement le domaine exact et ses sous-domaines. Aucune configuration DNS ne protège contre un domaine que vous ne possédez pas.
- Nous avons mesuré le domaine principal. Certaines organisations envoient leurs emails clients depuis un sous-domaine ou un autre domaine. Si ce sous-domaine publie son propre DMARC, il peut être plus strict ou plus souple que le domaine principal. Le fraudeur, lui, choisira l'adresse la plus crédible, souvent celle du domaine principal.
- Une photographie à une date. Les mesures datent du 5 novembre 2026. Une organisation a pu durcir sa politique depuis. Les deux séries de mesures, à cinq minutes d'écart, ont donné des résultats identiques.
- Un petit échantillon. 32 organisations ne représentent pas toutes les entreprises françaises. L'échantillon reflète les fuites devenues publiques, avec une forte part de commerce en ligne.
- Une protection côté réception. DMARC n'agit que si la messagerie du destinataire l'applique. Les grandes messageries le font, mais toutes ne le font pas.
- Pas de lecture de DKIM. Les sélecteurs DKIM ne sont pas publics. Nous ne pouvons pas vérifier de l'extérieur si chaque service d'envoi signe correctement.
Ce qu'une entreprise devrait faire avant la prochaine fuite
- Vérifiez votre DMARC avec notre outil de vérification SPF, DKIM et DMARC. Notez la politique, la présence de
rua et le mécanisme final du SPF.
- Activez les rapports s'ils sont absents, puis laissez-les tourner deux à quatre semaines pour recenser tous vos services d'envoi : messagerie, CRM, outil d'emailing, facturation, support.
- Passez à
p=quarantine, éventuellement avec un pct progressif, puis à p=reject une fois les rapports propres.
- Verrouillez les domaines qui n'envoient pas de mail : SPF
v=spf1 -all et DMARC p=reject.
Les exigences des grandes messageries sont résumées dans notre article sur les règles DMARC de Google, Yahoo et Microsoft. Pour la liste des incidents du mois, voir le baromètre des fuites de données d'octobre 2026.
Domains Defender surveille la configuration email de vos domaines (SPF, DKIM, DMARC) ainsi que DNSSEC et le verrou de transfert, et vous alerte si elle se dégrade, par exemple si un DMARC repasse en p=none ou disparaît. Vous pouvez lancer un audit gratuit de votre domaine.
Questions fréquentes
Pourquoi ne pas nommer les entreprises mal protégées ?
Ces organisations viennent de subir une attaque et leurs clients sont déjà ciblés. Publier la liste des domaines usurpables désignerait des cibles aux fraudeurs. L'étude porte sur une pratique répandue, pas sur une entreprise en particulier.
Un DMARC en p=none protège-t-il contre l'usurpation ?
Non. p=none sert à recevoir des rapports pendant la mise en place. Il demande explicitement aux messageries de ne prendre aucune mesure contre un message non authentifié. Seuls p=quarantine et p=reject protègent.
J'ai reçu un mail d'une entreprise victime d'une fuite : comment savoir s'il est vrai ?
Ne cliquez sur aucun lien. Connectez-vous à votre compte en tapant vous-même l'adresse du site, ou contactez le service client par un numéro que vous connaissez. Une entreprise ne vous demandera pas vos coordonnées bancaires complètes par email, même après un incident.
Comment vérifier le DMARC d'un domaine ?
Avec la commande dig +short TXT _dmarc.exemple.fr, ou avec notre outil de vérification email. Cherchez la valeur de p= : reject ou quarantine protègent, none ne protège pas. Une réponse vide signifie qu'il n'y a pas de DMARC.
DMARC suffit-il à protéger les clients après une fuite ?
Non. DMARC bloque l'usurpation de l'adresse exacte de l'entreprise. Il n'empêche ni les domaines ressemblants, ni les SMS, ni les appels. Il ferme la porte la plus crédible, ce qui oblige le fraudeur à des messages plus faciles à repérer.