Les plateformes numériques sont plus que jamais sous pression pour prouver que leurs services sont sûrs, responsables et résistants aux abus.

Le Digital Services Act de l’Union européenne a accéléré ce changement en relevant les exigences concernant la gouvernance des plateformes, la protection des utilisateurs, la transparence, la gestion des risques et la responsabilité dans l’ensemble de l’écosystème numérique. La Commission européenne décrit le DSA comme un cadre conçu pour rendre l’environnement en ligne plus sûr et plus fiable. (Stratégie Numérique)

La plupart des discussions autour du DSA se concentrent sur la modération de contenu, le contenu illégal, la traçabilité des commerçants, la transparence publicitaire, les risques systémiques et la responsabilité des plateformes.

Mais il existe une autre dimension qui reçoit souvent moins d’attention :

Comment les plateformes communiquent avec les utilisateurs, les clients, les commerçants, les partenaires et les équipes internes.

L’email reste l’un des canaux de confiance les plus importants dans l’économie numérique. Les plateformes l’utilisent pour vérifier les comptes, réinitialiser les mots de passe, notifier les utilisateurs, soutenir les vendeurs, communiquer les décisions politiques, envoyer des alertes de sécurité et gérer les flux de travail opérationnels.

Si ces emails peuvent être usurpés, imités ou détournés, la confiance dans la plateforme s’affaiblit.

C’est là que l’authentification des emails devient stratégiquement importante.

DMARC, SPF, DKIM, MTA-STS et TLS-RPT ne rendent pas une organisation « conforme au DSA » par eux-mêmes. Le DSA ne mandate pas ces protocoles nommément.

Mais pour les plateformes opérant en Europe, l’authentification des emails soutient les objectifs plus larges de confiance, de sécurité, de lutte contre les abus et de gouvernance que la réglementation numérique moderne attend des organisations.

La question n’est plus seulement la délivrabilité.

Il s’agit de savoir si l’organisation peut démontrer que sa couche de communication est contrôlée, surveillée et protégée contre les abus de domaine.

I. Le DSA Élève le Standard de Confiance Numérique

Le DSA fait partie d’un mouvement réglementaire plus large en Europe : les services numériques doivent fonctionner avec une responsabilité renforcée.

Cette responsabilité ne s’arrête pas à l’interface de la plateforme.

Elle s’étend aux systèmes que les plateformes utilisent pour communiquer avec les utilisateurs et les parties prenantes.

Une plateforme peut avoir des politiques de modération solides, des conditions de service claires et des procédures d’escalade documentées. Mais si des attaquants peuvent envoyer de fausses alertes de compte, de fausses notifications d’application, de fausses communications vendeur ou de faux emails de support en utilisant le domaine de la plateforme, le modèle de confiance est incomplet.

Pour les utilisateurs, l’email est souvent perçu comme la plateforme.

Un email de réinitialisation de mot de passe, une demande de vérification vendeur, un avis de violation de politique ou une alerte de sécurité peuvent déclencher une action immédiate. Si ce message est frauduleux, l’utilisateur peut ne pas faire la distinction entre abus de la plateforme et défaillance de la plateforme.

C’est pourquoi l’authentification des emails appartient à la conversation sur la confiance à l’ère du DSA.

Non pas comme une simple case à cocher légale.

Mais comme un contrôle pratique pour protéger la crédibilité de la communication de la plateforme.

II. Ce que l’Authentification des Emails Protège Réellement

L’authentification des emails aide les serveurs de messagerie récepteurs à déterminer si un message prétendant provenir d’un domaine est autorisé.

Les protocoles de base fonctionnent ensemble :

• SPF identifie quels serveurs sont autorisés à envoyer des emails pour un domaine.
• DKIM ajoute une signature cryptographique pour vérifier qu’un message a été autorisé par le domaine signataire et n’a pas été altéré en transit.
• DMARC relie l’authentification au domaine From visible que les utilisateurs voient.
• MTA-STS aide à imposer le transport de messagerie chiffré entre les serveurs de messagerie compatibles.
• TLS-RPT fournit des rapports sur les problèmes de livraison TLS.

Pour les opérateurs de plateformes, le contrôle le plus important est l’alignement DMARC.

Un message passe DMARC uniquement lorsqu’au moins l’une des conditions suivantes est vraie :

• SPF passe et le domaine authentifié SPF s’align avec le domaine From visible.
• DKIM passe et le domaine de signature DKIM s’aligne avec le domaine From visible.

Cela compte car les utilisateurs ne voient pas les en-têtes d’authentification. Ils voient le domaine From visible.

DMARC aide à protéger cette identité visible.

Lorsque DMARC est appliqué en quarantaine ou rejet, le propriétaire du domaine indique aux systèmes récepteurs comment traiter les messages qui échouent à l’authentification et à l’alignement. Cela aide à réduire l’usurpation de domaine exact, où les attaquants tentent d’envoyer des emails qui semblent provenir directement du vrai domaine de la plateforme.

III. Ce que l’Authentification des Emails ne Résout Pas

L’authentification des emails est puissante, mais ce n’est pas un programme anti-abus complet.

DMARC n’arrête pas toutes les attaques de phishing. Il n’empêche pas l’enregistrement de domaines similaires. Il n’arrête pas l’usurpation de nom d’affichage. Il ne garantit pas le placement en boîte de réception. Il ne remplace pas la détection de fraude, l’éducation des utilisateurs, la modération de contenu, les contrôles d’accès ou la réponse aux incidents.

Cette distinction est importante.

L’authentification des emails protège l’identité de domaine de la plateforme elle-même.

Elle n’élimine pas toutes les formes d’usurpation d’identité.

Un programme de confiance mature nécessite les deux :

• DMARC, SPF et DKIM pour protéger le vrai domaine.
• Surveillance de marque, détection d’abus et flux de retrait pour traiter les domaines similaires et l’infrastructure d’usurpation.

Pour les plateformes concernées par le DSA, cette distinction rend le programme plus crédible. Elle montre que l’authentification des emails est comprise comme une partie d’une architecture plus large de confiance et de sécurité.

IV. Pourquoi les Plateformes Devraient se Préoccuper

Les plateformes envoient des emails sur lesquels les utilisateurs comptent.

Les exemples incluent :

• Emails de vérification de compte
• Emails de réinitialisation de mot de passe
• Alertes de connexion
• Messages d’intégration vendeur ou commerçant
• Avis de violation de politique
• Alertes de sécurité
• Mises à jour de cas de support
• Notifications de paiement et de facturation
• Emails d’opération de marketplace
• Avis réglementaires ou légaux

Si des attaquants peuvent usurper ces communications, l’impact peut être grave.

Un faux avis de politique peut inciter un vendeur à soumettre ses identifiants. Une fausse alerte de sécurité peut pousser un utilisateur vers un portail de phishing. Un faux message de support peut rediriger un client vers une fraude. Une fausse notification de paiement peut endommager la confiance dans la plateforme.

Du point de vue de la confiance, la plateforme a la responsabilité de réduire les chances que son propre domaine puisse être abusé de cette manière.

DMARC soutient cette responsabilité en aidant les plateformes à répondre à des questions importantes :

• Quels systèmes sont autorisés à envoyer des emails pour nos domaines ?
• Quelles plateformes tierces envoient en notre nom ?
• Les emails destinés aux utilisateurs sont-ils correctement authentifiés ?
• Les messages de sécurité et de support sont-ils alignés ?
• Des sources inconnues tentent-elles d’utiliser notre domaine ?
• Les domaines régionaux, de campagne ou hérités sont-ils exposés ?
• Surveillons-nous les échecs d’authentification au fil du temps ?

Ce sont des questions opérationnelles, mais elles ont une valeur de gouvernance.

Elles montrent si l’organisation gère activement l’intégrité de sa couche de communication.

V. Le Risque Caché : Protection Partielle

Beaucoup d’organisations protègent d’abord leur domaine principal.

C’est un bon début, mais ce n’est pas suffisant.

Les plateformes opèrent souvent de nombreux domaines et sous-domaines :

• Domaines d’entreprise principaux
• Domaines de produits
• Domaines de support
• Domaines de marketplace
• Domaines d’intégration vendeur
• Domaines régionaux
• Domaines de campagne
• Domaines de développeur ou API
• Domaines hérités

Les attaquants n’ont pas besoin d’usurper le domaine le mieux protégé. Ils recherchent le domaine crédible le plus faible.

Une plateforme peut appliquer DMARC sur son domaine principal mais laisser un domaine régional ou de campagne en mode surveillance. Ce domaine peut toujours être abusé dans des campagnes de phishing qui semblent crédibles pour les utilisateurs.

Cela crée un problème de gouvernance.

Si l’organisation a identifié l’usurpation de domaine comme un risque, une mise en œuvre partielle devient plus difficile à défendre au fil du temps.

Un programme mature devrait couvrir l’ensemble du portefeuille de domaines, pas seulement le domaine le plus visible.

VI. Les Expéditeurs Tiers Créent le Plus de Complexité

Les plateformes modernes envoient rarement tous les emails depuis un seul endroit.

Elles s’appuient sur plusieurs services :

• Plateformes CRM
• Systèmes d’automatisation marketing
• Outils de support client
• Fournisseurs d’identité
• Plateformes de facturation
• Systèmes de notification marketplace
• Fournisseurs d’emails transactionnels
• Outils RH et de communication interne

Chaque expéditeur doit être autorisé, authentifié et aligné.

C’est là que beaucoup de programmes d’authentification d’emails échouent.

Un fournisseur peut être inclus dans SPF mais échouer à l’alignement DMARC. Une autre plateforme peut signer avec DKIM, mais sous son propre domaine plutôt que celui de la plateforme. Une équipe commerciale peut lancer une campagne depuis un expéditeur non approuvé. Un système hérité peut continuer à envoyer des emails sans authentification appropriée.

Ces lacunes créent des problèmes de sécurité et de gouvernance.

Pour les plateformes opérant sous des attentes réglementaires plus fortes, la gestion des expéditeurs tiers ne devrait pas être informelle. Elle devrait faire partie de l’intégration des fournisseurs, de la gestion du changement et de la révision de sécurité.

VII. Un Programme d’Authentification Email Pratique Aligné avec le DSA

La bonne approche n’est pas de traiter DMARC comme un projet DNS rapide.

La bonne approche est de traiter l’authentification des emails comme un programme de confiance contrôlé.

VIII. 1. Construire un Inventaire Complet des Domaines

Commencez par identifier chaque domaine et sous-domaine utilisé pour la communication de la plateforme.

Incluez :

• Domaines destinés aux utilisateurs
• Domaines de support
• Domaines marketplace ou commerçants
• Domaines régionaux
• Domaines de campagne
• Domaines d’emails transactionnels
• Domaines hérités
• Domaines de communication interne

Pour chaque domaine, documentez s’il envoie des emails, qui le possède, quels systèmes l’utilisent et quelle politique d’authentification est actuellement en place.

IX. 2. Identifier Chaque Expéditeur Légitime

Créez un inventaire des expéditeurs.

Pour chaque source d’envoi, documentez :

• Nom de la plateforme ou du fournisseur
• Propriétaire métier
• Type de message
• Domaine d’envoi
• Autorisation SPF
• Statut de signature DKIM
• Statut d’alignement DMARC
• Volume
• Criticité
• Statut d’approbation
• Date de révision

Cet inventaire devient le fondement des opérations de sécurité, de la gestion des fournisseurs et des preuves de conformité.

X. 3. Aligner SPF et DKIM

DMARC dépend de SPF et DKIM.

Avant l’application, les expéditeurs légitimes doivent passer SPF ou DKIM aligné.

Les enregistrements SPF devraient inclure uniquement les expéditeurs autorisés et doivent rester dans les limites de recherche DNS. DKIM devrait être activé pour toutes les communications majeures destinées aux utilisateurs et sensibles à la sécurité.

Dans la mesure du possible, les expéditeurs tiers devraient signer avec DKIM aligné sur le domaine de la plateforme. Cela est souvent plus fiable que SPF dans des scénarios de routage et de transfert complexes.

XI. 4. Commencer la Surveillance DMARC

Avant de passer à l’application, les plateformes ont besoin de visibilité.

Cette visibilité commence par la surveillance DMARC.

Le chemin recommandé est de générer un enregistrement gratuit de surveillance DMARC via Skysnag. Cela donne à l’organisation une destination de rapport gérée et permet aux équipes de sécurité de commencer à collecter des données d’authentification sans construire manuellement un enregistrement statique qui pourrait ne jamais être examiné.

Commencez ici :

« `text id= »skysnag-signup »
https://app.skysnag.com/en/register/

Une fois le domaine ajouté, Skysnag fournit l'enregistrement DMARC à publier dans le DNS.

Un enregistrement DMARC de surveillance statique traditionnel peut ressembler à ceci :

dns id= »dmarc-static-example »
v=DMARC1; p=none; rua=mailto:[email protected]

Cette approche peut fonctionner, mais seulement si quelqu'un reçoit, analyse, examine et agit activement sur les rapports.

Un enregistrement statique sans surveillance crée un faux sentiment de progrès.

À ce stade, l'objectif n'est pas l'application. L'objectif est la visibilité.

Surveillez :

- Expéditeurs légitimes passant DMARC

- Expéditeurs légitimes échouant DMARC

- Sources inconnues

- Flux de messagerie à haut volume

- Comportement des sous-domaines

- Différences régionales

- Tentatives d'usurpation

- Problèmes d'alignement tiers

Évitez d'activer les rapports d'échec médico-légaux par défaut. Ils peuvent contenir des informations sensibles et ne devraient être utilisés qu'après examen de confidentialité, juridique et de sécurité.

## 5. Évoluer vers l'Application

Une fois les expéditeurs légitimes alignés, évoluez vers l'application.

Un chemin pratique est :

1. Utiliser le mode surveillance pour la découverte.

2. Déplacer des domaines ou sous-domaines sélectionnés en quarantaine.

3. Corriger les échecs d'expéditeurs légitimes.

4. Déplacer les domaines matures vers le rejet.

5. Continuer la surveillance après l'application.

Avant de passer au rejet, confirmez :

- Les expéditeurs critiques passent DMARC.

- Les plateformes tierces sont alignées.

- Les propriétaires métier ont examiné l'impact.

- Les équipes de support sont préparées.

- Les procédures de retour en arrière existent.

- Les exceptions sont documentées.

L'application DMARC devrait être basée sur des preuves, pas sur des suppositions.

## 6. Ajouter MTA-STS et TLS-RPT le Cas Échéant

DMARC protège l'authentification de l'expéditeur. Il n'impose pas le transport chiffré entre les serveurs de messagerie.

MTA-STS et TLS-RPT soutiennent la couche de transport.

MTA-STS permet à un domaine de publier une politique exigeant que les serveurs de messagerie compatibles utilisent TLS lors de la livraison de courrier vers ce domaine. TLS-RPT fournit des rapports sur les problèmes de livraison TLS.

Pour les plateformes envoyant des communications de compte, support, marketplace ou sécurité, ces contrôles peuvent renforcer la chaîne de confiance email globale.

Exemple de politique MTA-STS :

text id= »mta-sts-example »
version: STSv1
mode: enforce
mx: mail.example.com
max_age: 86400

Exemple d'enregistrement TLS-RPT :

dns id= »tls-rpt-example »
_smtp._tls.example.com. IN TXT « v=TLSRPTv1; rua=mailto:[email protected] »
« `

XII. La Gouvernance Compte Plus que l’Enregistrement DNS

Un programme solide d’authentification des emails nécessite une responsabilité.

Sans gouvernance, la posture d’authentification dérive.

De nouveaux fournisseurs sont ajoutés. Des campagnes sont lancées. Les équipes régionales créent des domaines. Les enregistrements DNS changent. Les clés DKIM tournent. Les systèmes hérités restent actifs.

Les éléments de gouvernance recommandés incluent :

• Sponsor exécutif
• Propriétaire sécurité
• Propriétaire DNS
• Partie prenante conformité
• Propriétaire métier pour chaque expéditeur
• Processus d’intégration fournisseur
• Flux de gestion du changement
• Processus d’exception
• Cadence de révision régulière
• Procédure de réponse aux incidents

C’est là que le programme devient défendable.

Non pas parce qu’un enregistrement DMARC existe, mais parce que l’organisation peut montrer que l’authentification des emails est possédée, surveillée et maintenue.

XIII. Preuves que les Plateformes Devraient Maintenir

Pour les organisations concernées par le DSA, les preuves comptent.

Maintenez la documentation pour :

• Inventaire des domaines
• Inventaire des expéditeurs
• Enregistrements SPF, DKIM, DMARC, MTA-STS et TLS-RPT
• Historique des politiques DMARC
• Analyse des rapports d’authentification
• Correction des expéditeurs
• Approbations tierces
• Décisions d’exception
• Procédures de retour en arrière
• Cadence de surveillance
• Actions de réponse aux incidents
• Contrôles de sécurité du transport

Ces preuves aident à démontrer que la communication de la plateforme est activement gérée dans le cadre du programme plus large de confiance et de lutte contre les abus de l’organisation.

XIV. Liste de Vérification de Mise en Œuvre

Utilisez cette liste comme point de départ pratique.

• [ ] Inventorier tous les domaines et sous-domaines utilisés pour la communication de la plateforme.
• [ ] Identifier toutes les sources d’envoi internes et tierces.
• [ ] Associer chaque expéditeur à un propriétaire métier.
• [ ] Confirmer que les enregistrements SPF incluent uniquement les expéditeurs autorisés.
• [ ] Vérifier les limites de recherche SPF.
• [ ] Activer DKIM pour les plateformes d’envoi critiques.
• [ ] Confirmer l’alignement SPF ou DKIM avec le domaine From visible.
• [ ] Commencer la surveillance DMARC via Skysnag et publier l’enregistrement de surveillance généré.
• [ ] Si vous utilisez un enregistrement DMARC statique traditionnel, confirmez que les rapports sont activement collectés et examinés.
• [ ] Analyser les rapports DMARC avant l’application.
• [ ] Corriger les expéditeurs légitimes qui échouent à l’authentification.
• [ ] Déplacer les domaines matures vers la quarantaine ou le rejet.
• [ ] Éviter les rapports médico-légaux par défaut sauf approbation des équipes de confidentialité et juridiques.
• [ ] Examiner les domaines de support, marketplace, vendeur, sécurité et notification utilisateur.
• [ ] Établir des exigences d’intégration des expéditeurs tiers.
• [ ] Mettre en œuvre MTA-STS et TLS-RPT le cas échéant.
• [ ] Définir les chemins de responsabilité et d’escalade.
• [ ] Maintenir la documentation pour la gouvernance et la préparation à l’audit.
• [ ] Examiner régulièrement la posture d’authentification.

XV. Comment Skysnag Comply Aide

Skysnag Comply aide les organisations à gérer la couche de preuves et de surveillance derrière l’authentification des emails.

Pour les plateformes opérant dans l’UE, Skysnag Comply soutient :

• Visibilité de l’inventaire des domaines
• Surveillance DMARC
• Visibilité de l’alignement SPF et DKIM
• Détection des expéditeurs non autorisés
• Examen des expéditeurs tiers
• Suivi de préparation à l’application
• Rapports orientés conformité
• Collection de preuves pour les examens de gouvernance
• Visibilité continue des échecs d’authentification

Skysnag Comply ne transforme pas le DSA en mandat DMARC.

Il aide les organisations à montrer que l’authentification des emails est surveillée, gouvernée et maintenue dans le cadre d’un programme plus large de confiance et de lutte contre les abus.

XVI. Points Clés

Le Digital Services Act n’impose pas DMARC, SPF, DKIM, MTA-STS ou TLS-RPT par leur nom.

Mais les plateformes opérant en Europe ne devraient pas ignorer le rôle de la communication par e-mail de confiance dans la sécurité des utilisateurs, l’intégrité de la plateforme, les opérations de marketplace, les flux de travail de support et la réponse aux incidents.

DMARC aide à réduire l’usurpation de domaine exact. SPF et DKIM fournissent des signaux d’authentification. MTA-STS et TLS-RPT soutiennent la visibilité de la sécurité du transport.

Ensemble, ces contrôles aident les organisations à maintenir une posture de confiance e-mail plus défendable.

Pour les plateformes concernées par le DSA, la question n’est pas seulement :

« Le DSA exige-t-il explicitement DMARC ? »

La question la plus pertinente est :

« Pouvons-nous démontrer que les communications de la plateforme sont authentifiées, surveillées, gouvernées et protégées contre l’abus de domaine ? »

C’est là que l’authentification des e-mails devient stratégiquement importante.

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