Routage email mal configuré : l'alerte Microsoft sur le spoofing interne (janvier 2026)

⚡TL;DR

• Microsoft a révélé en janvier 2026 que les configurations MX pointant vers des services tiers (anti-spam, archivage) créent un angle mort exploité par les attaquants pour usurper des domaines internes
• La plateforme Tycoon2FA a généré 13 millions d'emails de phishing bloqués par Defender en un seul mois (octobre 2025), en exploitant ce vecteur combiné à des attaques AiTM
• Le trio SPF ~all + DKIM absent + DMARC p=none laisse passer 100 % des tentatives d'usurpation via un routage MX indirect
• L'analyse forensique des en-têtes email révèle le mécanisme exact : sauts inattendus dans la chaîne Received, spf=softfail, dkim=none, dmarc=fail action=none
• Le plan de correction en 5 étapes : DMARC progressif vers p=reject, SPF -all, DKIM activé, connecteurs tiers audités, MX direct vers Microsoft 365

En janvier 2026, l'équipe Microsoft Defender for Office 365 a publié un avertissement qui a secoué les équipes sécurité : des milliers d'organisations utilisant Microsoft 365 étaient vulnérables à une usurpation d'identité interne, non pas à cause d'un bug logiciel, mais à cause de leur propre configuration DNS. Le mécanisme est simple et redoutable. Quand l'enregistrement MX d'un domaine pointe vers un service tiers (passerelle anti-spam, solution d'archivage, relais de filtrage) au lieu de pointer directement vers Microsoft 365, les emails entrants traversent un intermédiaire qui ne recalcule pas correctement les résultats d'authentification SPF, DKIM et DMARC. Les attaquants l'ont compris, et ils exploitent cette faille à grande échelle.

Ce n'est pas un scénario théorique. Microsoft a documenté que la plateforme de phishing-as-a-service Tycoon2FA a généré à elle seule 13 millions d'emails malveillants bloqués par Defender en octobre 2025. Ces emails exploitaient le routage MX indirect combiné à des techniques d'adversary-in-the-middle (AiTM) pour voler des identifiants et des cookies de session, même chez les utilisateurs protégés par l'authentification multi-facteurs. Les leurres utilisés imitaient des réinitialisations de mot de passe, des messages RH et des notifications de documents partagés, envoyés depuis l'adresse interne de la victime vers elle-même.

Cet article détaille le mécanisme technique de cette attaque, l'analyse forensique des en-têtes email qui permet de la détecter, un diagnostic DNS en cinq minutes pour savoir si votre domaine est vulnérable et un plan de correction complet.

Le contexte : que révèle l'avertissement Microsoft de janvier 2026 ?

Un problème de routage, pas de protocole

L'avertissement de Microsoft ne porte pas sur une vulnérabilité dans SPF, DKIM ou DMARC eux-mêmes. Ces protocoles fonctionnent exactement comme prévu. Le problème se situe dans l'architecture de routage des emails.

Dans une configuration standard, l'enregistrement MX d'un domaine pointe directement vers les serveurs Exchange Online Protection (EOP) de Microsoft 365 :

captaindns.com.  IN  MX  10  captaindns-com.mail.protection.outlook.com.

Avec cette configuration, Microsoft 365 reçoit les emails directement depuis l'émetteur. Il évalue SPF en vérifiant l'IP source contre l'enregistrement SPF du domaine de l'enveloppe. Il valide la signature DKIM. Il applique la politique DMARC. Chaque vérification se fait dans le contexte correct.

Mais des milliers d'organisations ont un MX qui pointe vers un service tiers :

captaindns.com.  IN  MX  10  mx.filtrage-tiers.com.

Le service tiers reçoit l'email, effectue son traitement (anti-spam, archivage, analyse de contenu), puis transmet le message à Microsoft 365. Le problème : quand Microsoft 365 reçoit le message, l'IP source est celle du service tiers, pas celle de l'émetteur original. Le contexte d'authentification a changé.

Le mécanisme d'attaque en détail

L'attaquant exploite cette chaîne de la manière suivante :

Étape 1 : reconnaissance. L'attaquant interroge le MX du domaine cible. Si le MX pointe vers un service tiers au lieu de *.mail.protection.outlook.com, le domaine est potentiellement vulnérable.

Étape 2 : vérification de la posture d'authentification. L'attaquant vérifie trois enregistrements DNS :

• _dmarc.captaindns.com : si la politique est p=none, les échecs DMARC ne provoquent aucune action
• captaindns.com (TXT SPF) : si le mécanisme est ~all (softfail) au lieu de -all (hardfail), l'échec SPF est toléré
• Sélecteurs DKIM courants : si aucune clé DKIM n'est publiée, le champ dkim=none ne déclenche rien

Étape 3 : envoi de l'email usurpé. L'attaquant envoie un email depuis un serveur qu'il contrôle. Il place la même adresse dans les champs From et To : par exemple, comptabilite@captaindns.com vers comptabilite@captaindns.com. Ce « self-spoofing » donne l'impression que le message provient d'un collègue interne.

Étape 4 : transit via le service tiers. Le MX du domaine route l'email vers le service tiers. Celui-ci effectue un premier niveau de filtrage. Le problème : beaucoup de services tiers ne vérifient pas SPF/DKIM/DMARC du tout, ou les vérifient mais ne propagent pas les résultats de manière exploitable par Microsoft 365.

Étape 5 : livraison dans Microsoft 365. Microsoft 365 reçoit l'email depuis l'IP du service tiers. Sans le mécanisme Enhanced Filtering for Connectors (EFC), Exchange Online voit l'IP du tiers, pas l'IP de l'attaquant. Le SPF passe (car l'IP du tiers est dans le SPF du tiers) ou échoue en softfail. Le DKIM est absent. Le DMARC échoue mais la politique p=none ne provoque aucun blocage. L'email arrive dans la boîte de réception.

Pourquoi « skip authentication » est le point de rupture

Le problème fondamental est la configuration du connecteur entrant dans Exchange Online. Quand une organisation configure un connecteur pour recevoir les emails depuis un service tiers (Barracuda, Mimecast, Proofpoint, Sophos), l'assistant de configuration propose souvent de « faire confiance » aux résultats d'authentification du tiers, ou de « sauter l'authentification » pour les IP du connecteur. En pratique, beaucoup d'administrateurs activent cette option pour éviter les faux positifs : si le tiers a déjà vérifié SPF/DKIM/DMARC, pourquoi le refaire ?

Le problème : Exchange Online ne re-vérifie alors plus l'authentification contre la source originale. Il consomme les en-têtes Authentication-Results insérés par le tiers, ou pire, évalue SPF sur l'IP du connecteur (celle du tiers) au lieu de l'IP de l'émetteur réel. L'en-tête Authentication-Results visible dans la boîte de réception reflète les résultats vus par le tiers, pas ceux de la source réelle.

Microsoft a introduit Enhanced Filtering for Connectors (EFC) pour corriger ce problème. EFC demande à Exchange Online de remonter la chaîne Received pour identifier l'IP de l'émetteur original, en sautant les IP connues du service tiers (la « skip list »). Mais EFC n'est pas activé par défaut. Les organisations qui n'ont pas configuré EFC, ou qui l'ont configuré avec une skip list incomplète, restent vulnérables.

Le self-spoofing : l'email interne qui n'en est pas un

Le coup de grâce de cette attaque est le self-spoofing. L'attaquant place le même domaine dans les champs From et To : rh@captaindns.com envoie à jean.dupont@captaindns.com. Pour le destinataire, l'email semble provenir d'un collègue. Mais le mécanisme est plus insidieux : beaucoup d'organisations configurent des règles de transport Exchange qui traitent les emails « internes » différemment. Un email dont le domaine From est un domaine interne peut ne pas recevoir le bandeau « Cet email provient d'un expéditeur externe », ne pas être soumis aux mêmes filtres anti-phishing, et être affiché sans avertissement visuel. L'attaquant exploite non seulement la confiance humaine, mais aussi les exceptions de sécurité configurées pour les communications internes.

Le rôle critique du service tiers

Le problème central est que le service tiers agit comme un « blanchisseur » d'authentification involontaire. Quand il relaie le message vers Microsoft 365, il remplace le contexte d'authentification original :

• L'IP source change. Microsoft 365 voit l'IP du service tiers, pas celle de l'attaquant. La vérification SPF s'effectue sur la mauvaise IP.
• Les en-têtes Authentication-Results du tiers ne sont pas de confiance. Microsoft 365 n'a aucune raison de faire confiance aux résultats d'authentification insérés par le tiers.
• Le Return-Path peut être réécrit. Certains services tiers réécrivent l'enveloppe SMTP, brouillant davantage les pistes.

Microsoft a documenté que même les services tiers qui vérifient correctement SPF/DKIM/DMARC et insèrent les bons en-têtes ne résolvent pas le problème si Microsoft 365 ne sait pas regarder au-delà de l'IP du tiers pour retrouver l'IP de l'émetteur original.

C'est exactement le problème que résout Enhanced Filtering for Connectors : il permet à Exchange Online de « sauter » l'IP du tiers dans la chaîne Received et d'évaluer l'authentification sur l'IP réelle de l'émetteur.

Quelle est l'ampleur du problème ?

Le routage MX indirect n'est pas une configuration marginale. Selon les données publiées par les équipes de sécurité de Microsoft, une proportion significative des tenants Microsoft 365 utilise un service tiers devant Exchange Online. Les raisons sont multiples et souvent historiques :

• Héritage de migration : beaucoup d'organisations ont migré vers Microsoft 365 depuis un hébergement on-premise. Elles avaient déjà un service anti-spam tiers (Barracuda, Mimecast, Proofpoint, Sophos) et ont conservé le routage existant lors de la migration.
• Exigences réglementaires : certains secteurs (finance, santé, administration) imposent un archivage ou un filtrage des emails par un service tiers certifié. Le routage MX indirect est le moyen technique habituel pour satisfaire cette exigence.
• Stratégie de défense en profondeur : certaines équipes sécurité estiment qu'empiler deux couches de filtrage (tiers + Defender) offre une meilleure protection. C'est vrai pour le filtrage anti-spam, mais le coût en termes d'authentification est rarement mesuré.
• Méconnaissance du risque : avant l'avertissement de janvier 2026, le lien entre routage MX indirect et affaiblissement de l'authentification email n'était pas largement documenté. La plupart des guides de déploiement des services tiers ne mentionnent pas l'impact sur SPF/DKIM/DMARC côté Microsoft 365.

Le résultat : des organisations qui investissent dans la sécurité email (achat d'un service anti-spam premium, déploiement de DMARC) se retrouvent paradoxalement plus vulnérables que celles qui utilisent uniquement Defender avec un MX direct.

Tycoon2FA : la plateforme PhaaS qui exploite cette faille

Un service de phishing clé en main

Tycoon2FA est une plateforme de phishing-as-a-service (PhaaS) active depuis août 2023, identifiée et documentée par Sekoia.io et par le Threat Intelligence Center de Microsoft. Elle fonctionne comme un SaaS pour cybercriminels : les opérateurs paient un abonnement (environ 120 dollars par mois sur des canaux Telegram dédiés) et reçoivent en échange une infrastructure complète de phishing avec tableaux de bord, modèles d'emails, pages de connexion clonées et récupération automatisée des credentials. La barrière d'entrée est quasi nulle : aucune compétence technique n'est requise, le kit fournit tout, du domaine de phishing à la page de collecte.

L'ampleur de l'opération est massive. Selon les estimations consolidées des équipes Threat Intelligence de Microsoft et de Sekoia.io, Tycoon2FA génère plus de 30 millions d'emails de phishing par mois à travers l'ensemble de ses opérateurs. Microsoft a rapporté avoir bloqué 62 % des emails de phishing ciblant ses utilisateurs au premier semestre 2025, mais le volume restant suffit à compromettre des milliers de comptes. En mars 2026, Europol a tenté de démanteler l'infrastructure de Tycoon2FA dans le cadre d'une opération coordonnée. La plateforme était de nouveau opérationnelle en 48 heures, ayant migré ses serveurs vers de nouvelles juridictions.

Ce qui distingue Tycoon2FA des kits de phishing classiques est sa capacité à contourner l'authentification multi-facteurs (MFA) via une technique d'adversary-in-the-middle (AiTM).

Le mécanisme AiTM en détail

Le fonctionnement technique repose sur un proxy inverse transparent. Le point crucial : le MFA ne protège pas contre cette attaque parce que le proxy n'intercepte pas le second facteur lui-même. Il intercepte le cookie de session émis par Microsoft 365 après que l'utilisateur a complété avec succès toute la chaîne d'authentification, MFA inclus. La victime s'authentifie normalement, sur la vraie infrastructure Microsoft, mais le jeton de session est capturé en transit.

Voici le déroulement complet :

1. La victime reçoit un email de phishing usurpant un domaine interne via le mécanisme de routage MX décrit plus haut.
2. Le lien dans l'email passe par une chaîne de redirections. Microsoft a documenté l'utilisation de redirections via Google Maps (maps.google.com/url?q=...) pour contourner les filtres de réputation. La technique est redoutable : les filtres email inspectent le domaine du lien, voient maps.google.com (un domaine de confiance à réputation maximale) et laissent passer. Le paramètre q= contient l'URL réelle de la page de phishing, mais les filtres ne décodent pas systématiquement les redirections imbriquées. L'URL finale mène à une page de phishing hébergée sur un domaine éphémère.
3. La page de phishing agit comme un proxy transparent vers la vraie page de connexion Microsoft 365. Le serveur Tycoon2FA se place entre le navigateur de la victime et login.microsoftonline.com. Visuellement, la victime voit une interface de connexion identique à celle de Microsoft, avec le logo de l'organisation, les couleurs personnalisées et le branding Entra ID.
4. La victime saisit son identifiant et son mot de passe. Le proxy transmet les credentials à Microsoft 365 en temps réel. Microsoft les valide normalement.
5. Microsoft 365 demande le second facteur (MFA). Le proxy relaye la demande MFA à la victime. La victime entre son code TOTP ou approuve la notification push. Du point de vue de Microsoft, l'authentification est légitime.
6. Le proxy capture le cookie de session. Une fois l'authentification complète, Microsoft 365 émet un cookie de session. Le proxy l'intercepte avant de le transmettre à la victime. La victime reçoit un cookie valide et accède à sa boîte mail normalement, sans se douter de rien.
7. L'attaquant utilise le cookie de session volé pour accéder au compte depuis un autre navigateur, sans avoir besoin de repasser la MFA. Le cookie est valide pendant la durée de la session (souvent 24 heures ou plus selon la politique de l'organisation). L'attaquant peut lire les emails, exfiltrer des fichiers OneDrive, envoyer des emails au nom de la victime et se propager latéralement dans l'organisation.

Les chiffres documentés par Microsoft

Les données publiées par Microsoft dans son bulletin de janvier 2026 révèlent l'ampleur de l'exploitation :

Métrique	Valeur
Emails malveillants bloqués par Defender (octobre 2025)	13 millions
Plateforme PhaaS principale identifiée	Tycoon2FA
Technique de contournement MFA	Adversary-in-the-middle (AiTM)
Technique d'obfuscation d'URL	Redirections Google Maps
Principaux leurres	Réinitialisation de mot de passe, messages RH, documents partagés
Vecteur d'entrée	Routage MX indirect + SPF ~all + DKIM absent + DMARC p=none

Ces 13 millions d'emails concernent uniquement les messages bloqués par Defender. Les organisations sans Defender for Office 365, ou avec des configurations de filtrage moins strictes, n'ont pas bénéficié de cette protection.

Les leurres utilisés

Les campagnes Tycoon2FA documentées par Microsoft exploitent des scénarios à forte urgence perçue :

• Réinitialisation de mot de passe : « Votre mot de passe expire dans 24 heures. Cliquez ici pour le renouveler. » Le lien mène à la page AiTM.
• Messages RH : « Nouveau document à signer pour la mise à jour de votre contrat. » La pièce jointe ou le lien redirige vers la page de phishing.
• Documents partagés : « Marie Dupont a partagé un fichier avec vous sur OneDrive. » L'email mime une notification SharePoint légitime.
• Self-spoofing : dans les cas les plus sophistiqués, l'adresse From est identique à l'adresse To. La victime reçoit un email qui semble provenir d'elle-même ou d'un collègue du même domaine.

Le self-spoofing est particulièrement efficace parce que les utilisateurs font confiance aux emails provenant de leur propre domaine. Un email de rh@captaindns.com reçu par un employé de captaindns.com ne déclenche aucune alerte humaine.

Analyse forensique des en-têtes : détecter l'attaque

Quand un email suspect arrive dans une boîte Microsoft 365, les en-têtes contiennent les preuves du routage anormal. Voici comment les lire avec un analyseur d'en-têtes email.

Exemple d'en-têtes d'un email usurpé

Voici un exemple réaliste anonymisé d'en-têtes provenant d'un email de phishing exploitant le routage MX indirect. Tous les signaux d'alerte sont présents simultanément :

Return-Path: <bounce@malicious-relay.net>
Received: from mail-protection.captaindns.com (10.0.0.5) by
 exchange01.captaindns.com (10.0.0.10) with SMTP; Thu, 9 Jan 2026 08:15:23 +0000
Received: from gateway.thirdparty-filter.com (203.0.113.50) by
 mail-protection.captaindns.com with ESMTPS; Thu, 9 Jan 2026 08:15:21 +0000
Received: from unknown (198.51.100.77) by
 gateway.thirdparty-filter.com with SMTP; Thu, 9 Jan 2026 08:15:19 +0000
Authentication-Results: mail-protection.captaindns.com;
 spf=softfail (sender IP is 198.51.100.77) smtp.mailfrom=captaindns.com;
 dkim=none (message not signed);
 dmarc=fail action=none header.from=captaindns.com;
X-MS-Exchange-Organization-SCL: 5
From: Direction RH <rh@captaindns.com>
To: jean.dupont@captaindns.com
Subject: Document de politique RH à signer - Action requise

Analyse ligne par ligne

Return-Path: <bounce@malicious-relay.net>

Le Return-Path révèle l'adresse de rebond réelle. Le domaine malicious-relay.net n'a aucun lien avec captaindns.com. Ce décalage entre le Return-Path et le From affiché (rh@captaindns.com) est le premier signal d'alerte. Dans un email légitime envoyé depuis Microsoft 365, le Return-Path contient le domaine de l'organisation ou un sous-domaine de protection.outlook.com. Ici, c'est l'infrastructure de l'attaquant qui apparaît.

Chaîne Received (lue de bas en haut) :

Received: from unknown (198.51.100.77) by
 gateway.thirdparty-filter.com with SMTP

Premier saut : l'email part d'une IP inconnue (198.51.100.77) identifiée comme unknown par le service tiers. C'est le serveur de l'attaquant. L'absence de résolution DNS inverse (pas de nom d'hôte vérifié) est un signal fort : les serveurs email légitimes ont un PTR record configuré. L'utilisation de SMTP simple (pas ESMTPS) confirme que l'émetteur ne supporte pas le chiffrement TLS, ce qui est anormal pour un serveur d'entreprise en 2026.

Received: from gateway.thirdparty-filter.com (203.0.113.50) by
 mail-protection.captaindns.com with ESMTPS

Deuxième saut : le service tiers (gateway.thirdparty-filter.com) relaie vers Exchange Online. C'est cette IP (203.0.113.50) que Microsoft 365 voit comme source. Le contexte d'authentification est évalué sur cette IP, pas sur 198.51.100.77. Le service tiers a accepté le message et l'a transmis.

Received: from mail-protection.captaindns.com (10.0.0.5) by
 exchange01.captaindns.com (10.0.0.10) with SMTP

Troisième saut : routage interne Microsoft 365 vers la boîte de réception. Les adresses IP en 10.x.x.x confirment un routage interne. Ce saut est normal.

Authentication-Results: le triple échec

C'est la ligne la plus révélatrice, et elle contient trois échecs simultanés :

• spf=softfail (sender IP is 198.51.100.77) : l'IP source réelle (198.51.100.77, le serveur de l'attaquant) n'est pas dans le SPF de captaindns.com. Avec un mécanisme ~all, c'est un softfail, pas un reject. Le softfail est traité comme un avertissement, pas comme un blocage.
• dkim=none (message not signed) : aucune signature DKIM n'est présente. L'attaquant ne possède pas la clé privée DKIM de captaindns.com, donc il ne peut pas signer. Le service tiers n'a pas ajouté de signature non plus. L'absence de DKIM prive DMARC de son deuxième vecteur d'alignement.
• dmarc=fail action=none : DMARC échoue (ni SPF ni DKIM ne passent avec alignement de domaine). Mais action=none signifie que la politique DMARC du domaine est p=none, donc aucune action n'est prise malgré l'échec. L'email est livré normalement.

X-MS-Exchange-Organization-SCL: 5

Le Spam Confidence Level (SCL) est à 5 sur une échelle de 0 à 9. Un SCL de 5 indique un niveau de suspicion modéré. Par défaut, Exchange Online place en quarantaine les messages avec un SCL de 6 ou plus. Un SCL de 5 passe juste sous le seuil de blocage par défaut. Defender a détecté des signaux suspects (échecs d'authentification, Return-Path incohérent), mais pas assez pour bloquer catégoriquement avec la configuration actuelle.

From et To sur le même domaine : self-spoofing

Le From affiche Direction RH <rh@captaindns.com> et le To est jean.dupont@captaindns.com. Même domaine. Dans Outlook, l'utilisateur voit un email de « Direction RH » avec la photo et le titre de poste associés à rh@captaindns.com dans le carnet d'adresses. Le bandeau « Cet email provient d'un expéditeur externe » peut être absent si l'organisation a configuré des exceptions pour les domaines internes.

Subject: Document de politique RH à signer - Action requise

Le sujet combine deux leviers psychologiques : l'autorité (« Direction RH », « politique RH ») et l'urgence (« Action requise »). Ce type de leurre est documenté par Microsoft comme l'un des plus efficaces dans les campagnes Tycoon2FA.

Comparaison avec un email légitime

Pour contraster, voici les en-têtes d'un email légitime envoyé depuis la même organisation :

Return-Path: <rh@captaindns.com>
Authentication-Results: mail-protection.captaindns.com;
 spf=pass (sender IP is 40.107.22.83) smtp.mailfrom=captaindns.com;
 dkim=pass (signature was verified) header.d=captaindns.com;
 dmarc=pass action=none header.from=captaindns.com;
X-MS-Exchange-Organization-SCL: 1
From: Direction RH <rh@captaindns.com>
To: jean.dupont@captaindns.com

Les différences sont nettes : le Return-Path correspond au domaine From, SPF passe avec une IP Microsoft (40.107.x.x), DKIM passe avec une signature vérifiée, DMARC passe, et le SCL est à 1 (confiance élevée). C'est le profil type d'un email légitime.

Ce que révèle l'ensemble

En combinant ces éléments, le diagnostic est clair :

1. L'email ne provient pas de l'infrastructure de captaindns.com (Return-Path sur malicious-relay.net)
2. Il a transité par un service tiers qui n'a pas bloqué l'usurpation
3. Triple échec d'authentification : SPF softfail, DKIM absent, DMARC fail sans conséquence
4. Le SCL modéré indique que Defender a des doutes, mais la configuration actuelle ne permet pas le blocage
5. Le self-spoofing (même domaine dans From et To) exploite la confiance dans les communications internes

Pour détecter systématiquement ce type d'email, analysez vos en-têtes avec un analyseur d'en-têtes et cherchez ces quatre marqueurs : chaîne Received avec saut inattendu depuis une IP inconnue, spf=softfail, dkim=none, et dmarc=fail action=none.

Diagnostic en 5 minutes : votre domaine est-il vulnérable ?

Trois commandes DNS suffisent pour évaluer votre exposition. Ouvrez un terminal et exécutez les vérifications suivantes.

Vérification 1 : où pointe votre MX ?

dig MX captaindns.com +short

Résultat sûr :

10 captaindns-com.mail.protection.outlook.com.

Le MX pointe directement vers Microsoft 365. Les emails arrivent sans intermédiaire. L'authentification est évaluée sur l'IP de l'émetteur original.

Résultat à risque :

10 mx.filtrage-tiers.com.
20 mx2.filtrage-tiers.com.

Le MX pointe vers un service tiers. Tous les emails entrants transitent par cet intermédiaire avant d'atteindre Microsoft 365. Si Enhanced Filtering for Connectors n'est pas activé, l'authentification est évaluée sur l'IP du tiers.

Résultat mixte (à vérifier) :

10 mx.filtrage-tiers.com.
20 captaindns-com.mail.protection.outlook.com.

Le MX prioritaire est le service tiers, mais Microsoft 365 est en backup. En fonctionnement normal, tout le trafic passe par le tiers. Le risque est identique au scénario précédent.

Vérification 2 : quelle est votre politique DMARC ?

dig TXT _dmarc.captaindns.com +short

Résultat vulnérable :

"v=DMARC1; p=none; rua=mailto:dmarc@captaindns.com"

La politique p=none signifie que les échecs DMARC sont rapportés mais qu'aucune action n'est prise sur les emails. Combinée à un routage MX indirect, c'est une porte ouverte.

Résultat partiellement protégé :

"v=DMARC1; p=quarantine; pct=50; rua=mailto:dmarc@captaindns.com"

La politique p=quarantine place les emails échouant DMARC en spam, mais pct=50 signifie que seulement la moitié des emails sont soumis à cette politique. L'autre moitié est traitée comme si la politique était p=none.

Résultat protégé :

"v=DMARC1; p=reject; rua=mailto:dmarc@captaindns.com; ruf=mailto:dmarc-forensic@captaindns.com"

La politique p=reject demande aux serveurs de réception de rejeter les emails qui échouent DMARC. C'est la protection maximale.

Vérification 3 : quel est votre mécanisme SPF terminal ?

dig TXT captaindns.com +short | grep spf

Résultat vulnérable :

"v=spf1 include:spf.protection.outlook.com ~all"

Le mécanisme ~all (softfail) indique que les IP non listées ne devraient probablement pas envoyer pour ce domaine, mais le résultat est un softfail, pas un reject. Les serveurs de réception sont libres de l'ignorer.

Résultat protégé :

"v=spf1 include:spf.protection.outlook.com -all"

Le mécanisme -all (hardfail) indique que toute IP non listée est explicitement non autorisée. Les serveurs de réception qui respectent SPF rejetteront ces emails.

Matrice de vulnérabilité

MX	DMARC	SPF	DKIM	Niveau de risque
Tiers	p=none	~all	Absent	Critique
Tiers	p=none	-all	Absent	Élevé
Tiers	p=quarantine	~all	Absent	Élevé
Tiers	p=quarantine	-all	Actif	Modéré
Tiers	p=reject	-all	Actif	Faible (si EFC activé)
Direct M365	p=reject	-all	Actif	Minimal

Si votre domaine se situe dans les lignes « Critique » ou « Élevé », la correction est urgente. Passez à la section suivante.

Plan de correction en 5 étapes

Étape 1 : DMARC progressif vers p=reject

Ne passez jamais directement de p=none à p=reject. La montée en puissance progressive évite de bloquer des emails légitimes dont vous ignorez l'existence (newsletters, SaaS, CRM qui envoient au nom de votre domaine).

Phase 1 : monitoring (2 semaines minimum)

_dmarc.captaindns.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@captaindns.com; ruf=mailto:dmarc-forensic@captaindns.com; fo=1"

L'option fo=1 demande un rapport forensique pour chaque échec individuel (SPF ou DKIM), pas seulement quand les deux échouent. Analysez les rapports agrégés (rua) pour identifier toutes les sources d'envoi légitimes.

Phase 2 : quarantine progressif (2 semaines)

_dmarc.captaindns.com.  IN  TXT  "v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc-reports@captaindns.com"

Seulement 10 % des emails échouant DMARC sont placés en quarantaine. Surveillez les rapports et les plaintes utilisateurs.

Phase 3 : quarantine complet (2 semaines)

_dmarc.captaindns.com.  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@captaindns.com"

100 % des échecs sont mis en quarantaine. Si aucun faux positif n'est remonté, passez à l'étape suivante.

Phase 4 : reject progressif (1 semaine)

_dmarc.captaindns.com.  IN  TXT  "v=DMARC1; p=reject; pct=10; rua=mailto:dmarc-reports@captaindns.com"

10 % des échecs sont rejetés, le reste reste en quarantaine.

Phase 5 : reject complet

_dmarc.captaindns.com.  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@captaindns.com; ruf=mailto:dmarc-forensic@captaindns.com"

Protection maximale. Tout email qui échoue DMARC est rejeté par le serveur de réception.

Le processus complet prend environ 7 à 9 semaines. Ne raccourcissez pas les phases : chaque période d'observation révèle des sources d'envoi que vous aviez oubliées. Un service de facturation SaaS, un ancien outil marketing, un formulaire de contact qui envoie via un ESP non configuré dans votre SPF.

Étape 2 : SPF en hardfail (-all)

Remplacez ~all par -all dans votre enregistrement SPF :

captaindns.com.  IN  TXT  "v=spf1 include:spf.protection.outlook.com include:_spf.google.com -all"

Avant de modifier, vérifiez que toutes vos sources d'envoi légitimes sont incluses dans l'enregistrement SPF. Un hardfail combiné à une source oubliée bloquera des emails légitimes.

Points de vigilance :

• Nombre de lookups DNS : SPF autorise un maximum de 10 lookups DNS récursifs. Chaque include: compte comme un lookup, plus ceux imbriqués. Au-delà de 10, le résultat est un permerror et l'évaluation échoue.
• Incluez toutes vos sources : Microsoft 365, Google Workspace, ESP (Mailgun, SendGrid, Amazon SES), CRM (HubSpot, Salesforce), outils de ticketing.
• Testez avant de publier : utilisez notre outil de vérification DMARC pour valider votre configuration avant de la mettre en production.

Étape 3 : activer DKIM

DKIM est la pièce manquante dans la plupart des configurations vulnérables. Sans DKIM, DMARC ne peut s'appuyer que sur SPF pour l'alignement. Si SPF échoue (ce qui arrive systématiquement dans un scénario de routage indirect), DMARC échoue aussi.

Dans Microsoft 365 :

1. Accédez au portail Defender (security.microsoft.com)
2. Naviguez vers Email & collaboration > Policies & rules > Threat policies > Email Authentication Settings > DKIM
3. Sélectionnez votre domaine
4. Activez « Sign messages for this domain with DKIM signatures »
5. Microsoft génère deux enregistrements CNAME à publier dans votre DNS :

selector1._domainkey.captaindns.com.  CNAME  selector1-captaindns-com._domainkey.captaindns.onmicrosoft.com.
selector2._domainkey.captaindns.com.  CNAME  selector2-captaindns-com._domainkey.captaindns.onmicrosoft.com.

6. Publiez les CNAME, attendez la propagation DNS (généralement 15 à 30 minutes), puis validez dans le portail Defender.

Avec DKIM actif, même si le SPF échoue à cause du routage indirect, DMARC peut réussir via l'alignement DKIM, à condition que le service tiers ne modifie pas le corps du message ni les en-têtes signés.

Étape 4 : auditer les connecteurs et activer le filtrage amélioré

Enhanced Filtering for Connectors (EFC) est la solution technique que Microsoft recommande pour les organisations qui doivent conserver un routage MX indirect. EFC permet à Exchange Online de « regarder au-delà » de l'IP du service tiers pour retrouver l'IP de l'émetteur original dans la chaîne Received.

Activation dans Exchange Online :

1. Accédez au Exchange Admin Center (admin.exchange.microsoft.com)
2. Naviguez vers Mail flow > Connectors
3. Identifiez le connecteur entrant depuis votre service tiers
4. Dans les propriétés du connecteur, activez « Enhanced Filtering for Connectors »
5. Configurez les IP du service tiers à « sauter » (skip listing)

Une fois EFC activé, Exchange Online remonte la chaîne Received pour trouver la dernière IP externe avant le service tiers. L'évaluation SPF, DKIM et DMARC se fait sur cette IP, restaurant le contexte d'authentification correct.

Points de vigilance :

• Testez EFC en mode audit avant de l'appliquer en production
• Assurez-vous que les IP du service tiers dans la skip list sont à jour
• Vérifiez que le service tiers ne réécrit pas les en-têtes Received de manière à empêcher EFC de retrouver l'IP source

Étape 5 : envisager un MX direct vers Microsoft 365

La solution la plus radicale et la plus efficace est de supprimer l'intermédiaire. Si votre service tiers est utilisé pour le filtrage anti-spam, Microsoft Defender for Office 365 (plan 1 ou plan 2) offre des capacités équivalentes ou supérieures :

• Exchange Online Protection (EOP) : inclus dans toutes les licences Microsoft 365, fournit un filtrage anti-spam et anti-malware de base.
• Defender for Office 365 Plan 1 : ajoute Safe Links (réécriture et analyse des URLs en temps réel), Safe Attachments (détonation en sandbox) et anti-phishing.
• Defender for Office 365 Plan 2 : ajoute Threat Explorer, Automated Investigation and Response (AIR), Attack Simulation Training et Threat Trackers.

Si le service tiers est utilisé pour l'archivage ou la conformité, des solutions d'archivage fonctionnent aussi en aval (journal rules) sans nécessiter un routage MX indirect.

Pour passer en MX direct :

captaindns.com.  IN  MX  10  captaindns-com.mail.protection.outlook.com.

Supprimez les anciennes entrées MX pointant vers le service tiers. Mettez à jour votre SPF si nécessaire. Vérifiez que vos connecteurs Exchange Online sont correctement configurés.

Au-delà de l'authentification email : la question du MFA

Le routage MX indirect ouvre la porte au phishing. Mais l'avertissement Microsoft rappelle que Tycoon2FA ne se contente pas de voler des mots de passe. La plateforme vole des sessions authentifiées, contournant le MFA. La correction du routage email ne suffit donc pas si votre MFA reste vulnérable aux attaques AiTM.

Pourquoi le MFA classique ne protège plus

Le MFA basé sur les codes TOTP (applications d'authentification comme Microsoft Authenticator en mode code, Google Authenticator) ou les notifications push est vulnérable aux proxys AiTM. Le mécanisme est structurel : le code TOTP est un secret partagé entre l'utilisateur et le serveur. Si un proxy se place entre les deux, il capture le code en transit et le rejoue immédiatement. La notification push est encore plus facile à exploiter : le proxy déclenche la demande d'authentification sur le vrai serveur, l'utilisateur approuve sur son téléphone et le proxy capture le cookie de session résultant.

Cela ne signifie pas que le MFA est inutile. Il protège toujours contre le credential stuffing, les attaques par dictionnaire et les fuites de bases de données. Mais contre le phishing AiTM, il faut une solution résistante au phishing.

FIDO2 et passkeys : la seule solution résistante au phishing

Les clés FIDO2 (YubiKey, Feitian, Google Titan) et les passkeys (implémentées dans Windows Hello, Apple iCloud Keychain, Android) offrent une résistance native au phishing. Le mécanisme repose sur la liaison à l'origine (origin binding) :

1. Lors de l'enregistrement, la clé FIDO2 ou la passkey est liée à un domaine précis (par exemple, login.microsoftonline.com).
2. Lors de l'authentification, le navigateur vérifie automatiquement que le domaine de la page correspond au domaine enregistré. Si la page est un proxy de phishing sur login-microsoftonline.attacker.com, le navigateur refuse d'envoyer les credentials.
3. Pas de secret partagé à intercepter. L'authentification utilise un mécanisme challenge-response basé sur une paire de clés asymétriques. Même si l'attaquant intercepte l'échange, il ne peut pas le rejouer.

Un proxy AiTM ne peut pas contourner ce mécanisme : le navigateur vérifie l'origine à un niveau que le proxy ne peut pas falsifier. C'est la raison pour laquelle Microsoft, Google et Apple poussent collectivement l'adoption des passkeys depuis 2024.

MFA number matching comme solution intermédiaire

Si le déploiement de FIDO2/passkeys n'est pas immédiat, activez au minimum le number matching dans Microsoft Authenticator. Au lieu d'un simple « Approuver / Refuser », l'utilisateur doit saisir un nombre à deux chiffres affiché sur l'écran de connexion. Cette mesure ne protège pas contre un proxy AiTM sophistiqué (le proxy peut afficher le nombre), mais elle bloque les attaques MFA fatigue (bombardement de notifications push) et ajoute une friction qui réduit le taux de succès des attaques.

Activation dans Entra ID :

1. Accédez au Microsoft Entra Admin Center (entra.microsoft.com)
2. Naviguez vers Protection > Authentication methods > Microsoft Authenticator
3. Dans l'onglet Configure, activez « Require number matching for push notifications »
4. Appliquez à tous les utilisateurs ou à un groupe pilote

La priorité reste le déploiement de FIDO2/passkeys pour les comptes à privilèges élevés (administrateurs, cadres dirigeants, équipes financières), puis l'extension progressive à l'ensemble des utilisateurs.

Le rôle d'ARC dans les chaînes de relais

Le protocole ARC (Authenticated Received Chain) a été conçu précisément pour résoudre le problème de perte de contexte d'authentification lors du transit via des intermédiaires. ARC permet à chaque relais de signer les résultats d'authentification qu'il a observés, créant une chaîne de confiance vérifiable.

En théorie, si le service tiers implémente ARC correctement :

1. Le service tiers reçoit l'email et évalue SPF/DKIM/DMARC
2. Il ajoute un jeu d'en-têtes ARC (ARC-Authentication-Results, ARC-Message-Signature, ARC-Seal) documentant les résultats observés
3. Microsoft 365 reçoit l'email et vérifie la chaîne ARC
4. Si la chaîne ARC est valide et provient d'un expéditeur ARC de confiance, Microsoft 365 peut utiliser les résultats d'authentification d'origine au lieu de ses propres résultats (qui sont faussés par le routage indirect)

En pratique, l'efficacité d'ARC dépend de deux conditions : le service tiers doit implémenter ARC (ce qui n'est pas systématique), et Microsoft 365 doit faire confiance à l'expéditeur ARC (configurable dans le portail Defender). Sans ces deux conditions, ARC ne change rien.

Microsoft recommande ARC comme solution complémentaire, mais pas comme substitut à Enhanced Filtering for Connectors ou au passage en MX direct.

Surveillance et réponse en cas d'incident

La sécurisation du routage email n'est pas un projet ponctuel. Les attaquants adaptent leurs techniques, les configurations évoluent et de nouveaux services d'envoi sont ajoutés régulièrement. Une surveillance active est nécessaire pour détecter rapidement toute régression ou tentative d'exploitation.

Configurer les alertes dans Microsoft Defender

Microsoft Defender for Office 365 permet de créer des alertes personnalisées qui détectent les schémas d'attaque décrits dans cet article :

Alerte sur les échecs DMARC récurrents : Dans le portail Defender (security.microsoft.com), accédez à Email & collaboration > Explorer. Filtrez sur DMARC = fail et action = none pour votre domaine. Si vous observez un volume anormal d'échecs DMARC sans action, c'est le signe que votre politique p=none est exploitée. Configurez une alerte automatisée pour être notifié quand le volume dépasse un seuil (par exemple, plus de 50 échecs DMARC par jour pour un domaine interne).

Alerte sur le self-spoofing : Recherchez les emails où le champ From contient un domaine interne mais où le Return-Path contient un domaine externe. Ce pattern est caractéristique du self-spoofing. Dans Exchange Online, une règle de flux de courrier (transport rule) peut détecter cette condition et ajouter un avertissement visuel au message ou le placer en quarantaine.

Surveillance des rapports DMARC agrégés : Les rapports DMARC agrégés (envoyés à l'adresse rua) contiennent les résultats d'authentification de tous les emails envoyés au nom de votre domaine. Analysez-les au moins une fois par semaine. Un pic soudain d'échecs depuis des IP inconnues indique une campagne d'usurpation en cours. Des outils gratuits comme DMARC Analyzer, Postmark DMARC, ou les rapports agrégés de Microsoft permettent de visualiser ces données sans traitement manuel.

Que faire si vous détectez une attaque en cours ?

Si vous identifiez des emails de phishing exploitant le routage MX indirect contre votre domaine :

1. Activez immédiatement EFC si ce n'est pas déjà fait. C'est la mesure la plus rapide pour restaurer le contexte d'authentification correct.
2. Passez DMARC en p=quarantine au minimum, même sans la montée progressive recommandée. En situation d'attaque active, le risque de faux positifs est secondaire par rapport au risque de compromission.
3. Bloquez les IP sources identifiées dans les en-têtes Received via les règles de flux de courrier Exchange Online ou via le service tiers.
4. Informez les utilisateurs ciblés. Si des emails de self-spoofing ont été livrés, les utilisateurs doivent savoir qu'ils ne doivent pas cliquer sur les liens ni ouvrir les pièces jointes.
5. Vérifiez les connexions suspectes dans les journaux d'audit Entra ID. Si l'attaque AiTM a réussi à capturer des cookies de session, vous verrez des connexions depuis des IP inhabituelles peu après la livraison des emails de phishing.
6. Révoquez les sessions actives des comptes potentiellement compromis via Entra ID (Revoke Sessions). Forcez un changement de mot de passe et une réauthentification MFA.

Automatiser la détection à long terme

Pour les organisations avec un volume d'emails significatif, l'automatisation de la détection est indispensable. Microsoft Sentinel (le SIEM cloud de Microsoft) peut ingérer les journaux Exchange Online et déclencher des playbooks automatisés sur les conditions suivantes :

• Volume anormal d'emails avec dmarc=fail action=none pour un domaine interne
• Emails entrants où le domaine From est un domaine interne mais l'IP source n'est pas dans la liste des IP autorisées
• Connexions Entra ID depuis une IP géographiquement incohérente dans les minutes suivant la livraison d'un email suspect

Ces automatisations transforment une détection réactive (« on a trouvé un email suspect ») en une détection proactive (« le système a isolé l'email et verrouillé le compte avant que l'utilisateur ne clique »).

Checklist de sécurisation complète

Voici la checklist consolidée pour sécuriser votre domaine contre le vecteur d'attaque documenté par Microsoft. Chaque item est classé par priorité.

Priorité critique (semaine 1)

• Vérifier votre MX : dig MX captaindns.com +short
• Vérifier votre politique DMARC : dig TXT _dmarc.captaindns.com +short
• Vérifier votre mécanisme SPF terminal : dig TXT captaindns.com +short
• Si MX indirect + DMARC p=none : activer Enhanced Filtering for Connectors immédiatement
• Activer DKIM pour votre domaine dans Microsoft 365

Priorité haute (semaines 2 à 4)

• Commencer la montée progressive de DMARC vers p=quarantine
• Remplacer SPF ~all par -all après inventaire des sources d'envoi
• Auditer les connecteurs entrants dans Exchange Online
• Vérifier la configuration IP de la skip list pour EFC
• Activer le number matching dans Microsoft Authenticator

Priorité moyenne (mois 2 à 3)

• Continuer la montée DMARC vers p=reject
• Évaluer la migration vers un MX direct vers Microsoft 365
• Commencer le déploiement FIDO2/passkeys pour les comptes à privilèges
• Configurer les expéditeurs ARC de confiance si le routage indirect est maintenu
• Mettre en place un suivi régulier des rapports DMARC agrégés

Priorité basse (trimestre suivant)

• Étendre FIDO2/passkeys à l'ensemble des utilisateurs
• Supprimer le routage MX indirect si non nécessaire
• Automatiser l'analyse des rapports DMARC avec un outil dédié
• Former les utilisateurs à reconnaître les emails de phishing

Ce que l'avertissement Microsoft change pour votre organisation

L'avertissement de janvier 2026 n'a pas révélé un bug. Il a mis en lumière un angle mort architectural que les attaquants exploitent à grande échelle. La combinaison routage MX indirect + SPF softfail + DKIM absent + DMARC p=none est une configuration que des milliers d'organisations utilisent sans savoir qu'elle est vulnérable.

Le correctif n'est pas un patch logiciel. C'est un travail de configuration DNS et d'architecture email. Certaines organisations corrigeront en une journée (activer DKIM, passer le SPF en hardfail, activer EFC). D'autres auront besoin de plusieurs mois pour migrer leur MX et déployer FIDO2.

Les trois actions immédiates :

1. Diagnostiquez maintenant. Les trois commandes dig de la section diagnostic prennent 30 secondes. Vous saurez immédiatement si votre domaine est dans la zone critique.
2. Activez Enhanced Filtering for Connectors si votre MX pointe vers un tiers. C'est la correction la plus rapide avec le meilleur ratio impact/effort.
3. Activez DKIM. C'est la pièce qui manque à la plupart des configurations vulnérables. Avec DKIM actif, DMARC peut passer même quand SPF échoue à cause du routage indirect.

L'objectif final est simple : votre domaine doit être protégé par SPF -all, DKIM actif et DMARC p=reject. Ce n'est pas un idéal théorique, c'est la baseline que Google, Yahoo et Microsoft exigent des expéditeurs depuis 2024. L'avertissement de janvier 2026 rappelle que les emails finissent en spam quand cette baseline n'est pas atteinte, et pire, que les attaquants exploitent activement les domaines qui ne l'atteignent pas.