L’email reste la vulnérabilité la plus exploitée dans les défaillances de protection des données qui conduisent aux pénalités RGPD. Les plus de 400 M€ d’amendes infligées depuis 2020 pour des violations liées aux emails partagent des schémas communs : les organisations n’ont pas mis en œuvre de contrôles d’authentification de base, surveillé les expéditeurs non autorisés ou détecté la compromission avant l’exfiltration massive de données.

La pénalité infligée à Coupang en 2024 illustre ce schéma. Le détaillant sud-coréen a écopé d’une amende de 15 M€ non pas parce que le chiffrement a échoué, mais parce que des contrôles d’accès et une surveillance inadéquats ont permis à des parties non autorisées d’accéder aux données clients via des canaux email compromis. La violation n’était pas sophistiquée—elle a exploité des lacunes d’authentification que DMARC, la validation des expéditeurs et la détection d’accès non autorisé auraient pu révéler.

Le RGPD ne mandate pas DMARC nommément. Les articles 32 et 5(1)(f) exigent des « mesures techniques et organisationnelles appropriées » et une sécurité du traitement « adaptée au risque ». Les contrôles d’authentification des emails soutiennent ces objectifs. Lorsque les autorités de contrôle enquêtent sur une violation où le phishing, l’usurpation d’identité ou l’accès par expéditeur non autorisé ont contribué à l’exposition de données, elles évaluent si l’organisation a mis en œuvre des mesures raisonnables pour le prévenir.

Ce document identifie sept failles de sécurité email qui apparaissent dans les décisions de sanction RGPD, relie chacune à des défaillances d’authentification évitables et explique comment les organisations peuvent les combler.

I. Faille 1 : Absence d’authentification au niveau du domaine → Usurpation non détectée

La défaillance de conformité :
Les organisations ne publient aucun enregistrement SPF, aucune politique DMARC, ou laissent DMARC à p=none indéfiniment. Les acteurs malveillants usurpent les domaines internes pour cibler les employés, partenaires ou clients. Lorsque l’email usurpé conduit au vol d’identifiants ou à l’exfiltration de données, les régulateurs demandent : « Avez-vous mis en œuvre des mesures pour prévenir l’usurpation de domaine ? »

Ce qui peut mal tourner :
SPF peut échouer silencieusement lorsque les recherches DNS expirent (temperror) ou lorsque l’enregistrement dépasse 10 recherches DNS (permerror). DMARC peut réussir l’authentification mais échouer l’alignement lorsque l’expéditeur d’enveloppe diffère de l’adresse From de l’en-tête. La réussite de l’authentification ne garantit pas la remise en boîte de réception, et l’échec de l’authentification ne signifie pas toujours un rejet immédiat—mais l’absence d’application supprime un contrôle de détection critique.

Prévention :
Commencez la surveillance DMARC, évoluez vers l’application p=quarantine ou p=reject, et documentez le calendrier. L’application DMARC ne garantit pas la remise en boîte de réception, mais lorsqu’elle est honorée par les serveurs de réception, p=reject leur ordonne de refuser les messages non authentifiés lors de la livraison SMTP.

Les organisations soumises au RGPD implémentent couramment l’application DMARC dans le cadre de leur programme de sécurité email. Utilisez Skysnag Protect pour identifier les expéditeurs légitimes, détecter les sources non autorisées et organiser l’application par sous-domaine, unité commerciale et groupe d’expéditeurs.

Lien avec l’article 32 du RGPD :
L’article 32 exige « un processus visant à tester, à analyser et à évaluer régulièrement l’efficacité des mesures techniques et organisationnelles ». Un domaine sans application n’a aucun mécanisme pour bloquer ou même détecter l’usurpation en temps réel.

II. Faille 2 : Expéditeurs tiers non surveillés → Email informatique fantôme

La défaillance de conformité :
Les plateformes marketing, outils CRM, systèmes de billetterie d’assistance et applications SaaS envoient des emails au nom de l’organisation. Le service informatique ne maintient pas d’inventaire. Les employés autorisent des outils sans examen informatique. Des services malveillants ou compromis envoient des messages usurpés, et l’organisation ne découvre le problème qu’après une violation.

Ce qui peut mal tourner :
Les expéditeurs tiers qui ne publient pas de signatures DKIM ou échouent l’alignement SPF échoueront DMARC même si le service est légitime. Si l’organisation applique DMARC à p=reject, le courrier légitime provenant de services non contrôlés peut être refusé. Si l’organisation n’applique pas la politique, les attaquants peuvent usurper l’identité en utilisant des services que l’organisation n’a jamais autorisés.

Prévention :
Maintenez un inventaire des expéditeurs. Exigez l’approbation informatique avant d’autoriser tout service à envoyer au nom des domaines d’entreprise. Utilisez les rapports agrégés DMARC pour découvrir les expéditeurs non autorisés. Skysnag Protect révèle chaque source envoyant en votre nom et signale les sources absentes de votre inventaire approuvé.

Lien avec l’article 28 du RGPD :
L’article 28 exige que les organisations utilisent des sous-traitants qui « présentent des garanties suffisantes » et mettent en œuvre des « mesures techniques appropriées ». Si le service informatique ne peut pas identifier quels sous-traitants envoient des emails, il ne peut pas évaluer ces garanties.

III. Faille 3 : Enregistrement DMARC statique sans collecte de rapports → Théâtre de conformité

La défaillance de conformité :
L’organisation publie un enregistrement DMARC incluant rua=mailto:[email protected], mais personne ne surveille la boîte aux lettres. Les rapports s’accumulent non lus. L’organisation ne peut pas identifier les nouvelles menaces, les expéditeurs non autorisés ou les échecs d’authentification. Lorsqu’une violation se produit, l’organisation ne peut pas démontrer que la surveillance était active.

Ce qui peut mal tourner :
Les rapports agrégés DMARC arrivent en format XML depuis des centaines de sources quotidiennement. Sans analyse automatisée, les données des rapports sont inutilisables. Les échecs de livraison DNS, les problèmes de quota de boîte aux lettres et le mauvais routage peuvent faire cesser silencieusement l’arrivée des rapports. Un enregistrement statique sans surveillance ne fournit aucun bénéfice de sécurité.

Prévention :
Utilisez une surveillance DMARC gérée. Dans un déploiement Skysnag, la destination de rapport est générée et maintenue par Skysnag. Les rapports sont analysés, normalisés et présentés dans un tableau de bord montrant la conformité des expéditeurs, les résultats d’authentification et les nouvelles sources en temps réel.

Un enregistrement statique traditionnel tel que :

v=DMARC1; p=none; rua=mailto:[email protected]

peut fonctionner, mais seulement si les rapports sont activement reçus, analysés, examinés et traités. La meilleure approche consiste à démarrer la surveillance DMARC via Skysnag et obtenir un enregistrement géré généré pour votre domaine.

Lien avec l’article 32 du RGPD :
L’article 32 exige des « mesures visant à garantir la confidentialité, l’intégrité, la disponibilité et la résilience constantes ». Un enregistrement sans surveillance ne fournit pas de visibilité continue.

IV. Faille 4 : Absence de politique d’application → Les expéditeurs non autorisés passent

La défaillance de conformité :
L’organisation publie DMARC à p=none et l’y laisse. Les rapports DMARC montrent des sources échouant, mais aucune action d’application n’est prise. Les acteurs malveillants découvrent l’absence d’application et usurpent le domaine à grande échelle. Lorsque le phishing conduit à une violation de données, les autorités de contrôle évaluent si l’organisation a mis en œuvre des mesures de blocage raisonnables.

Ce qui peut mal tourner :
Lorsqu’elle est honorée par le serveur de réception, p=reject leur ordonne de refuser les messages non authentifiés lors de la livraison SMTP et le message ne devrait pas atteindre la boîte de réception ou le dossier spam. Cependant, l’application dépend du serveur de réception honorant la politique. Certains redirecteurs, listes de diffusion et récepteurs mal configurés ne le font pas. L’application DMARC ne garantit pas le rejet partout, mais elle réduit considérablement les taux de réussite de l’usurpation.

Les organisations restent couramment à p=none parce qu’elles craignent de bloquer le courrier légitime. Cette crainte est valide. Évitez de vous fier au déploiement basé sur le pourcentage (pct=) comme stratégie principale. Les programmes actuels compatibles DMARC devraient organiser l’application par domaine, sous-domaine, groupe d’expéditeurs et fonction commerciale.

Prévention :
Utilisez les rapports agrégés DMARC pour identifier tous les expéditeurs légitimes. Vérifiez SPF et DKIM pour chacun. Testez l’application sur des sous-domaines à faible risque d’abord. Déplacez les domaines de production vers p=quarantine, puis p=reject à mesure que la conformité des expéditeurs s’améliore. Utilisez Skysnag Protect pour suivre l’état d’authentification des expéditeurs et organiser l’application en toute sécurité.

Lien avec l’article 5(1)(f) du RGPD :
L’article 5(1)(f) exige une « sécurité appropriée » pour protéger contre « le traitement non autorisé ou illicite ». Un domaine qui n’ordonne pas aux récepteurs de bloquer l’utilisation non autorisée fournit une protection plus faible.

V. Faille 5 : Absence de rotation DKIM → Compromission de clé non détectée

La défaillance de conformité :
L’organisation a publié une clé DKIM il y a cinq ans et ne l’a jamais renouvelée. Un développeur quitte l’entreprise avec l’accès à la clé privée. Un serveur est déclassé sans révocation de clé. Une sauvegarde de configuration contenant la clé est stockée dans un bucket S3 non sécurisé. Les acteurs malveillants trouvent la clé et signent des messages malveillants qui passent DMARC.

Ce qui peut mal tourner :
Les signatures DKIM peuvent échouer lorsque la clé est renouvelée mais que le DNS n’est pas mis à jour, lorsque le corps du message est modifié en transit, ou lorsque les en-têtes de signature sont supprimés par les redirecteurs. La réussite de DKIM ne garantit pas la réussite de DMARC—l’alignement est également requis. Cependant, une signature DKIM valide provenant d’une clé compromise peut contourner entièrement l’application DMARC.

Prévention :
Renouvelez les clés DKIM annuellement. Révoquez immédiatement les anciennes clés lorsque les serveurs sont déclassés ou que le personnel ayant accès aux clés part. Surveillez la cohérence de signature DKIM via les rapports DMARC. Utilisez Skysnag Protect pour suivre l’utilisation DKIM entre les expéditeurs et détecter les signatures provenant de sélecteurs inattendus.

Lien avec l’article 32(1)(d) du RGPD :
L’article 32(1)(d) exige des mesures « garantissant la confidentialité, l’intégrité, la disponibilité et la résilience constantes des systèmes de traitement ». Une clé statique qui n’est jamais renouvelée augmente le risque de compromission au fil du temps.

VI. Faille 6 : Absence de visibilité sur l’infrastructure source des emails → Compromission non détectée

La défaillance de conformité :
L’organisation sait qu’elle envoie des emails, mais le service informatique ne peut pas lister chaque adresse IP, domaine ou service qui envoie en son nom. Lorsque les rapports DMARC montrent une nouvelle source, personne ne sait si elle est légitime, malveillante ou compromise. Des jours ou des semaines s’écoulent avant le début de l’enquête.

Ce qui peut mal tourner :
Les rapports agrégés DMARC montrent l’expéditeur d’enveloppe (utilisé pour SPF), le domaine From de l’en-tête (utilisé pour l’alignement DMARC) et le domaine de signature DKIM. Si l’un de ceux-ci ne correspond pas aux valeurs attendues, l’authentification peut réussir mais l’usurpation reste possible. Par exemple, un service légitime pourrait réussir SPF mais échouer l’alignement DMARC parce que le domaine From de l’en-tête diffère. L’enquête est plus difficile car la surveillance montre les résultats d’authentification, mais le domaine n’ordonne pas aux récepteurs de bloquer l’utilisation non authentifiée.

Prévention :
Maintenez un inventaire complet de l’infrastructure email autorisée : adresses IP, services d’envoi, inclusions SPF, sélecteurs DKIM et modes d’alignement DMARC. Comparez quotidiennement les rapports DMARC à l’inventaire. Utilisez Skysnag Protect pour automatiser la découverte des expéditeurs, signaler les nouvelles sources et corréler les résultats d’authentification à l’infrastructure connue.

Lien avec l’article 30 du RGPD :
L’article 30 exige que les organisations « tiennent un registre des activités de traitement ». L’email est une activité de traitement. Si le service informatique ne peut pas lister les systèmes et services qui envoient des emails, le registre est incomplet.

VII. Faille 7 : Absence de preuve de surveillance → Incapacité à démontrer la conformité

La défaillance de conformité :
L’organisation prétend surveiller la sécurité des emails, mais n’a pas de journaux, pas d’enregistrements de réponse aux incidents, pas de preuve d’examen d’authentification et pas de documentation des décisions d’application. Lorsqu’une violation se produit, les autorités de contrôle demandent des preuves de surveillance proactive. L’organisation ne peut pas les fournir.

Ce qui peut mal tourner :
Les pénalités RGPD évoluent en fonction de l’intention, de la négligence et de la réactivité de la remédiation. Les organisations qui démontrent une surveillance proactive, une application fondée sur des preuves et une réponse aux incidents documentée reçoivent un traitement plus favorable. Les organisations qui ne peuvent démontrer aucun de ces éléments font face à des pénalités plus élevées.

Prévention :
Journalisez les rapports DMARC, les décisions d’authentification, les changements d’expéditeurs et les actions d’application. Conservez les journaux conformément à la politique de protection des données (évitez la conservation indéfinie). Documentez les décisions d’organisation de l’application. Utilisez Skysnag Comply pour maintenir des preuves de contrôles d’authentification email sur les domaines et expéditeurs, avec des pistes d’audit pour l’examen de conformité.

Lien avec les articles 5(2) et 24 du RGPD :
L’article 5(2) exige que les organisations « soient en mesure de démontrer la conformité ». L’article 24 exige des « mesures techniques et organisationnelles appropriées » et « la capacité de démontrer » celles-ci. La surveillance de l’authentification email fournit cette preuve.

VIII. Ce que le RGPD exige réellement (et n’exige pas)

Le RGPD ne mandate pas DMARC nommément. Il ne spécifie pas SPF, DKIM, BIMI ou un quelconque protocole d’authentification email particulier. Ce qu’il exige :

• Article 32 : « Des mesures techniques et organisationnelles appropriées afin de garantir un niveau de sécurité adapté au risque. »
• Article 5(1)(f) : Le traitement doit garantir une « sécurité appropriée » contre « le traitement non autorisé ou illicite ».
• Article 24 : Le responsable du traitement « met en œuvre des mesures techniques et organisationnelles appropriées » et « est en mesure de démontrer que le traitement est effectué conformément au présent règlement ».

Les contrôles d’authentification email soutiennent ces objectifs. Lorsque les autorités de contrôle enquêtent sur une violation où l’usurpation, l’accès par expéditeur non autorisé ou l’exfiltration de données basée sur l’email ont contribué au préjudice, elles évaluent si l’organisation a mis en œuvre des mesures préventives raisonnables. Un domaine sans application DMARC, sans surveillance des expéditeurs et sans journalisation d’authentification présente des preuves plus faibles de mesures raisonnables.

Les organisations qui peuvent démontrer une surveillance proactive, une application organisée, une maintenance de l’inventaire des expéditeurs et une réponse aux incidents documentée montrent une posture de conformité plus forte. Utilisez Skysnag Comply pour maintenir cette preuve sur les domaines, unités commerciales et expéditeurs tiers.

IX. Points Clés

• Le RGPD n’impose pas DMARC, mais les contrôles d’authentification des e-mails soutiennent les objectifs de sécurité des Articles 32, 5(1)(f) et 24.
• Plus de 400 millions d’euros d’amendes RGPD concernaient des violations où des lacunes en matière de sécurité des e-mails ont contribué à des accès non autorisés ou à des exfiltrations de données.
• Les sept lacunes de sécurité des e-mails les plus courantes qui apparaissent dans les décisions de sanctions RGPD sont : (1) absence d’authentification de domaine, (2) expéditeurs tiers non surveillés, (3) DMARC statique sans collecte de rapports, (4) absence de politique d’application, (5) absence de rotation DKIM, (6) aucune visibilité sur l’infrastructure de messagerie, et (7) aucune preuve de surveillance.
• La réussite de l’authentification ne garantit pas la livraison en boîte de réception. L’échec de l’authentification ne signifie pas toujours un rejet. Mais l’application fournit un contrôle mesurable que les régulateurs peuvent évaluer.
• Les organisations qui démontrent une surveillance proactive, une application progressive et une réponse aux incidents documentée reçoivent un traitement plus favorable lors des enquêtes sur les violations.
• Utilisez Skysnag Protect pour identifier les expéditeurs légitimes, détecter les sources non autorisées et mettre en place une application DMARC par sous-domaine et groupe d’expéditeurs.
• Utilisez Skysnag Comply pour conserver les preuves des contrôles d’authentification des e-mails, de l’inventaire des expéditeurs et des décisions d’application pour l’examen de conformité.

Commencez la surveillance DMARC avec Skysnag et obtenez votre enregistrement DMARC gratuit :