Votre campagne d'e-mailing ne peut pas atteindre ses destinataires si elle ne peut pas prouver son expéditeur

Aperçu

À la fin août, un courriel non sollicité est arrivé dans l'une de nos boîtes de réception pour annoncer une gamme de produits de contre-surveillance. L'expéditeur se présentait comme le PDG de Global TSCM Group, un fournisseur spécialisé qui vend des systèmes de détection d'écoute clandestine, des contre-mesures contre les microphones laser et des écouteurs Bluetooth chiffrés.

La campagne avait manifestement demandé un certain travail. Elle comprenait de la documentation produit à jour, deux catalogues, un suivi de campagne et un mécanisme de désabonnement. Microsoft Defender l'a envoyée dans le courrier indésirable, l'a classée comme usurpée et a marqué les liens visibles vers les catalogues comme malveillants.

Nous avons examiné le message parce que les détails ne correspondaient pas vraiment à une campagne d'hameçonnage classique. L'expéditeur, l'entreprise, les produits et les documents étaient cohérents d'une source publique à l'autre. Les deux liens de catalogue que nous avons examinés renvoyaient des PDF ordinaires exportés depuis PowerPoint, et notre analyse statique n'a relevé ni JavaScript, ni fichier intégré, ni action de lancement, ni formulaire, ni aucune autre fonction PDF active.

Le problème le plus évident n'était pas le contenu : la plateforme de courriel de l'entreprise s'authentifiait sous le nom de DirectSend, alors que le message demandait au destinataire de faire confiance à Global TSCM Group.

C'est là que le DMARC cesse d'être un contrôle de sécurité abstrait pour devenir un problème de communication d'affaires. Une organisation légitime peut rédiger le bon message, l'envoyer au bon public et quand même avoir l'air d'une usurpation.

Pourquoi le message méritait un examen plus attentif

Global TSCM Group œuvre dans le domaine des contre-mesures de surveillance technique (TSCM) : la détection et la prévention des microphones dissimulés, des émetteurs RF, de la surveillance audio par laser, des appareils mobiles non autorisés et d'autres formes d'écoute électronique.

L'empreinte publique de l'entreprise est inhabituelle, mais cohérente. Un registre des sociétés de l'État de New York fait état d'une inscription de Global TSCM Group, Inc. en 2007, avec Gyo Seung An comme contact pour la signification des actes. C'est le même nom que celui utilisé dans le courriel, affiché dans la documentation publique de l'entreprise et intégré comme auteur dans l'un des catalogues. L'adresse du PDG utilisée dans la campagne est également publiée sur le site Web de l'entreprise.

Ses sites annoncent les mêmes produits que ceux décrits dans le message, dont le système de surveillance RF 24/7 The Stealth, le système de localisation d'émetteurs The Stealth TEAM, des contre-mesures de surveillance par laser et les écouteurs chiffrés nouvellement promus. Les documents et les sites Web reprennent les mêmes noms de produits, allégations, personnes et coordonnées.

Un destinataire avait tout de même des raisons d'hésiter. La présence de l'entreprise est répartie entre un domaine principal, des sites distincts pour les États-Unis et la Corée, The Stealth Lab, The Stealth Mall et d'autres sites de produits. Certaines pages contiennent du contenu de 2026, alors que des éléments du design et du pied de page indiquent encore 2021. Le catalogue mentionne à la fois une adresse d'entreprise et un compte Gmail. Cela ressemble davantage à la présence Web accumulée d'un petit fabricant spécialisé qu'à une identité d'entreprise gérée de façon centralisée.

Ce n'est pas une preuve d'activité malveillante, mais cela signifie que le courriel n'avait guère de marge pour un autre manquement à la confiance.

SPF et DKIM ont réussi. Le DMARC a quand même échoué.

L'infrastructure de DirectSend apparaît dans les en-têtes d'envoi, le chemin de retour, la signature DKIM, le lien de désabonnement et les URL de téléchargement des catalogues.

SPF et DKIM ont chacun fait leur travail. SPF a confirmé que le serveur d'envoi était autorisé à envoyer pour le domaine d'enveloppe de DirectSend. DKIM a confirmé que DirectSend avait signé le message et que le contenu signé n'avait pas été modifié en transit.

Aucun de ces résultats ne répondait à la question qui importait au destinataire : Global TSCM Group a-t-il autorisé ce courriel?

Le DMARC relie ces vérifications à l'adresse affichée dans le champ De. Au moins un domaine authentifié doit être aligné sur le domaine de l'expéditeur visible. Dans ce cas, les deux résultats positifs appartenaient à DirectSend, et non à Global TSCM Group.

Microsoft a donc classé le message comme usurpé et lui a attribué un SCL de 5, ce qui l'a envoyé dans le courrier indésirable. Du point de vue du destinataire, c'était une décision raisonnable. Le message revendiquait une identité et en authentifiait une autre.

Le coût d'une configuration incomplète sur la délivrabilité

Le DMARC est habituellement présenté comme un moyen d'empêcher les attaquants d'usurper le domaine d'une entreprise. C'est une raison importante de le déployer, mais cela peut donner l'impression que ce contrôle n'est pertinent qu'en cas d'activité malveillante.

La plupart des organisations ont aussi un problème plus ordinaire : de nombreux systèmes envoient du courrier en leur nom.

Chaque plateforme peut produire un message qui semble correct pour l'expéditeur tout en authentifiant une autre identité technique en arrière-plan. Lorsque cette identité n'est pas alignée, les conséquences sont bien concrètes :

• Une campagne de vente est placée dans le courrier indésirable avant qu'un prospect la voie.
• Un client rate une facture ou un avis de paiement.
• Une notification de réinitialisation de mot de passe ou de compte ressemble à de l'hameçonnage.
• Une alerte opérationnelle est retardée parce que le système destinataire s'en méfie.
• Le personnel commence à demander aux clients d'ajouter le courrier à une liste d'autorisation au lieu de corriger la configuration.

Le courriel que nous avons examiné est un exemple utile, car ce décalage coûte particulièrement cher. Une entreprise présentait des produits de sécurité à un destinataire qui ne la connaissait pas. Elle avait besoin que le premier message établisse sa crédibilité, mais sa configuration de courriel a éliminé l'un des signaux techniques les plus forts pour y parvenir.

L'infrastructure partagée ajoute un autre problème de réputation

Les liens vers les catalogues ne pointaient pas vers des fichiers hébergés sur globaltscmgroup.com. Ils utilisaient le chemin partagé mail_report_api/filedownload de DirectSend, avec des identifiants propres à la campagne.

Defender a affiché onze URL dans le message et marqué les liens visibles de téléchargement des catalogues comme malveillants. Nous avons récupéré ces deux fichiers dans un environnement isolé le 11 septembre 2026.

Les fichiers correspondaient aux produits et aux identités publiés sur les sites Web de l'entreprise. Au moment de publier cet article, nous n'avions trouvé aucune preuve que les deux PDF récupérés étaient malveillants.

Nous ne pouvons pas non plus dire exactement pourquoi Microsoft a attribué ce verdict aux URL. Il pourrait être lié au chemin de téléchargement partagé, à une réputation héritée d'autres activités sur la plateforme, aux fichiers récupérés ou à d'autres signaux du message. Une URL hébergée par un fournisseur d'envoi massif repose sur une infrastructure partagée avec des clients que l'expéditeur ne connaît pas et ne contrôle pas.

C'est une deuxième raison de considérer la délivrabilité dans le choix d'une plateforme. L'authentification peut être correctement configurée et un expéditeur peut tout de même hériter d'un risque provenant de domaines partagés de suivi, de redirection, d'images ou d'hébergement de fichiers. Dans la mesure du possible, les organisations devraient utiliser des domaines de marque alignés et héberger la documentation client importante sur une infrastructure clairement associée à leur propre identité.

Ce que les praticiens devraient vérifier

La configuration d'un expéditeur tiers n'est pas terminée lorsque la plateforme indique que l'enregistrement DNS a été accepté ou qu'un message de test arrive dans votre propre boîte de réception. La vérification finale doit se faire du côté du destinataire.

Répertoriez tous les services qui envoient au nom de votre domaine

Commencez par les plateformes auxquelles on pense naturellement — Microsoft 365, Google Workspace et le service de marketing principal — mais incluez aussi les systèmes plus discrets. Les plateformes de facturation, les outils de soutien, les flux de travail CRM, les formulaires de site Web, les numériseurs, les systèmes RH, les produits de sécurité et les applications métier envoient tous du courrier qui influe sur la réputation du domaine.

Vérifiez l'alignement, pas seulement la réussite ou l'échec

Examinez le domaine qui a réussi la vérification SPF et le domaine d= de la signature DKIM. Au moins l'un des deux doit être aligné sur le domaine affiché dans l'adresse d'expédition. Un résultat SPF positif pour le domaine du fournisseur n'authentifie pas votre marque.

Confirmez le DMARC à destination

Envoyez des tests contrôlés vers les principaux environnements utilisés par vos clients et inspectez les en-têtes reçus. Microsoft 365 et Gmail sont de bons points de départ. Confirmez que le DMARC réussit au terme du parcours de livraison complet, et pas seulement dans l'assistant de configuration de la plateforme d'envoi.

Examinez les liens insérés par la plateforme

Les outils de campagne peuvent remplacer des URL autrement propres par des redirections de suivi, des points de désabonnement, des hébergeurs d'images et des services de téléchargement. Vérifiez leur réputation et déterminez si des domaines de suivi ou d'hébergement de fichiers à votre marque sont offerts.

Surveillez avant d'appliquer

Les rapports agrégés DMARC peuvent montrer quels services envoient au nom du domaine et lesquels échouent à l'alignement. Servez-vous de cette visibilité pour corriger les expéditeurs légitimes avant de passer de façon réfléchie à p=quarantine puis à p=reject. Laisser indéfiniment la politique à p=none fournit des rapports, mais n'indique pas aux destinataires de bloquer les utilisations non autorisées.

Ne réglez pas les problèmes de configuration avec de larges listes d'autorisation

Ajouter un service d'envoi partagé à une liste d'autorisation peut masquer le symptôme tout en accordant votre confiance à du trafic sans lien provenant du même fournisseur. Corrigez d'abord le parcours d'authentification. N'utilisez des exceptions ciblées qu'en cas de besoin opérationnel clair, avec un responsable chargé de les réviser.

Sources

1. OpenGovNY New York corporation record for Global TSCM Group, Inc.
2. Microsoft Security Operations guide for email authentication in Microsoft 365
3. Microsoft Set up DMARC to validate email
4. Microsoft Email security with Threat Explorer and Real-time detections