RGPD et authentification des emails : deux angles à ne pas confondre

RUA contre RUF : le bon réglage côté vie privée

La conséquence pratique est claire, et elle rejoint la position de plus en plus répandue dans l'écosystème : privilégier les rapports agrégés, et traiter les rapports forensiques avec une extrême prudence, voire y renoncer par défaut. La distinction entre les deux, et pourquoi le RUF est aujourd'hui déconseillé, est développée dans rapports DMARC rua contre ruf et, sous l'angle spécifique de la vie privée, dans la confidentialité des rapports forensiques DMARC.

Le raisonnement RGPD est celui de la minimisation : ne collecter que ce qui est nécessaire à la finalité poursuivie. Or cette finalité — sécuriser le domaine et cartographier les sources d'envoi — est entièrement servie par les rapports agrégés. Le forensique ajoute peu de valeur de sécurité tout en démultipliant l'exposition en données personnelles. Le calcul penche donc massivement en faveur de l'agrégé seul.

Minimisation, conservation, sous-traitants

Dès lors que des rapports DMARC sont exploités, quelques principes RGPD s'appliquent directement :

• Base légale et finalité. Le traitement repose sur l'intérêt légitime à sécuriser le domaine et les communications de l'organisation — une base solide, à condition que la finalité reste la sécurité et non un usage détourné.
• Minimisation. Préférer l'agrégé, éviter le forensique, et ne pas exfiltrer plus de champs que nécessaire.
• Durée de conservation. Fixer une durée proportionnée et l'appliquer : les rapports vieux de plusieurs années n'ont plus d'utilité de sécurité et deviennent un passif. Un palier de conservation explicite, purgé automatiquement, est la bonne pratique.
• Sous-traitants. Confier l'analyse des rapports à un prestataire en fait un sous-traitant au sens du RGPD : la relation s'encadre contractuellement, et le lieu d'hébergement des données se vérifie. L'hébergement dans l'Union, sous droit européen, simplifie considérablement l'analyse de conformité.

Ces mêmes exigences alimentent le registre des traitements et se documentent une fois pour toutes — un travail qui rejoint directement la logique de preuve d'un SMSI ISO 27001.

Le double bénéfice : conformité et protection des personnes

Il y a une élégance dans ce croisement. Porter un domaine à p=reject, c'est répondre à l'obligation de sécurité et protéger directement les personnes concernées — clients, usagers, salariés — contre les fraudes qui exploiteraient cette identité pour leur soutirer des données. La conformité et la protection réelle pointent, ici, dans la même direction, ce qui est loin d'être toujours le cas en matière réglementaire.

C'est aussi pourquoi les entités soumises à NIS2 ou à d'autres régimes sectoriels gagnent à traiter DMARC comme un contrôle commun : le même effort satisfait l'obligation de sécurité du RGPD, l'exigence de résilience réglementaire, et la protection concrète des personnes.

Un exemple concret

Prenons une PME dont le domaine est resté en p=none. Un attaquant envoie à sa base clients un email affichant l'adresse authentique du service client, annonçant une « mise à jour de sécurité du compte » et renvoyant vers une page de collecte d'identifiants. Plusieurs clients saisissent leurs informations. Du point de vue du RGPD, l'entreprise fait face à une possible violation touchant les données de ses clients, exploitant son propre domaine comme vecteur — une situation inconfortable où elle est à la fois victime et responsable de traitement interrogé sur ses mesures de sécurité.

Le même scénario, domaine en p=reject, se termine autrement : le message falsifié est rejeté à la remise, il n'atteint jamais les boîtes, et il n'y a ni collecte, ni violation, ni notification. C'est la démonstration la plus tangible que l'authentification email est une mesure de sécurité au sens de l'article 32, et non une abstraction technique.

DMARC et la notification de violation

Le RGPD impose de notifier certaines violations de données à l'autorité de contrôle dans un délai de 72 heures, et parfois d'informer les personnes concernées. Or une campagne d'usurpation réussie d'un domaine peut être une violation, ou en déclencher une : des identifiants soutirés à des clients, des données personnelles extraites par un faux message au nom de l'organisation, c'est exactement le type d'événement qui enclenche l'obligation de notification, avec son cortège d'enquête, de communication et de tension réglementaire.

Le raisonnement rejoint celui de la résilience opérationnelle : chaque usurpation que DMARC bloque en amont est une violation qui n'a pas lieu. Réduire structurellement la capacité d'un attaquant à se faire passer pour l'organisation, c'est réduire la fréquence des incidents notifiables — un bénéfice de conformité concret, mesurable en incidents évités, pas seulement en principe.

Documenter le traitement dans le registre

Dès lors que des rapports DMARC sont exploités, l'analyse constitue un traitement à inscrire au registre au titre de l'article 30. La bonne nouvelle : c'est un traitement simple à décrire. Finalité — sécurité du domaine et cartographie des sources d'envoi légitimes. Catégories de données — essentiellement des adresses IP source et des métadonnées d'authentification pour l'agrégé, et c'est tout si l'on s'y tient. Base légale — intérêt légitime à sécuriser les communications. Durée — un palier de conservation borné, purgé automatiquement. Destinataires — l'éventuel prestataire d'analyse, encadré comme sous-traitant.

Renseigné une fois, ce registre se réutilise tel quel comme brique de preuve dans un dispositif ISO 27001, qui partage la même exigence de documentation. L'effort n'est pas dupliqué : un même traitement, décrit proprement, se présente sous les deux cadres.

Faut-il une analyse d'impact (AIPD) ?

La question revient souvent. Pour les rapports agrégés seuls, l'exposition en données personnelles est faible et la finalité de sécurité bien cadrée : une analyse d'impact relative à la protection des données n'est en général pas requise, même si une évaluation rapide du risque reste une bonne hygiène. Le calcul change dès qu'on active les rapports forensiques, qui peuvent charrier des données personnelles de tiers en volume et à une granularité bien plus intrusive. C'est une raison de plus, sur le terrain de la vie privée cette fois, de s'en tenir à l'agrégé par défaut — le principe même de minimisation qui structure tout ce raisonnement.

Mesurer l'exposition réelle

Tout commence par le diagnostic gratuit. Un passage du domaine dans notre analyseur DMARC gratuit dit s'il est actuellement usurpable, et notre politique de confidentialité montre comment nous appliquons nous-mêmes ces principes à l'analyse de domaines. La posture d'un secteur entier se compare, elle, dans l'Observatoire DMARC.

Cadrer proprement l'authentification — application de la politique côté sécurité, réglage prudent des rapports côté vie privée — est exactement ce à quoi sert Thomas, le RSSI virtuel : il identifie les sources d'envoi à partir des rapports agrégés, sans jamais dépendre du forensique, et guide la montée jusqu'à p=reject. Analyser un domaine gratuitement · explorer l'Observatoire · commencer avec Thomas.