Le fonctionnement interne du filtrage de Microsoft (EOP / Defender for Office 365)

Quand vos messages destinés à une entreprise qui utilise Microsoft 365 arrivent dans le dossier Courrier indésirable ou en quarantaine, les en-têtes du message vous disent pourquoi. Voici comment Exchange Online Protection (EOP) filtre les messages entrants destinés aux clients professionnels (tenants), et comment un expéditeur ou un consultant lit son verdict.

C’est un système différent du filtrage des boîtes Outlook.com grand public (héritier de SmartScreen et visible dans SNDS), que traite Exigences de Microsoft envers les expéditeurs. Les deux systèmes partagent toutefois des données de réputation, et les expéditeurs B2B dépendent des verdicts d’EOP.

Pour diagnostiquer un message, obtenez-en une copie telle qu’elle a été livrée (ou classée en courrier indésirable ou mise en quarantaine) auprès d’un destinataire Microsoft 365, et extrayez les en-têtes complets. Lisez trois en-têtes dans l’ordre : Authentication-Results (l’authentification a-t-elle réussi ?), X-Forefront-Antispam-Report (quel est le verdict, et pourquoi ?) et X-Microsoft-Antispam (BCL). L’analyseur de Microsoft lui-même est le Message Header Analyzer, à l’adresse https://mha.azurewebsites.net/.

L’empilement des couches

1. Le filtrage des connexions en bordure du service, fondé sur l’adresse IP. C’est là que la plupart du spam est intercepté. Les données d’entrée sont la liste des expéditeurs bloqués de Microsoft (voir Canaux d’escalade de Microsoft), les listes d’autorisation et de blocage d’adresses IP du client, et la réputation des adresses IP. Les entrées de la liste de blocage d’IP d’un client rejettent les messages en bordure.
2. Les stratégies antispam (filtrage du contenu) classent chaque message comme bulk, spam, spam à haut niveau de confiance, phishing ou phishing à haut niveau de confiance, et apposent les valeurs SCL et BCL. Il existe trois niveaux de stratégies : la stratégie par défaut, les stratégies personnalisées créées par les administrateurs, et les stratégies de sécurité prédéfinies Standard et Strict. Les stratégies prédéfinies ont des valeurs par défaut de plus en plus agressives et, pour les destinataires qu’elles incluent, leurs réglages l’emportent sur ceux des stratégies personnalisées.
3. L’anti-phishing, la spoof intelligence et l’authentification composite : la couche d’authentification implicite de Microsoft (compauth), qui juge le domaine From même en l’absence d’enregistrement DMARC.
4. Les modules complémentaires de Defender for Office 365 (MDO) : la protection contre l’usurpation d’identité (des utilisateurs, des domaines, et par la mailbox intelligence), Safe Links et Safe Attachments. Ils n’existent que chez les clients disposant de licences MDO, et produisent les valeurs CAT marquées MDO uniquement ci-dessous.

Les modifications de stratégie mettent jusqu’à 1 heure à s’appliquer. Lorsque plusieurs détections se déclenchent, les stratégies s’appliquent par ordre de priorité et le verdict le plus prioritaire l’emporte.

L’en-tête X-Forefront-Antispam-Report

L’en-tête est une liste de paires champ:valeur séparées par des points-virgules, par exemple ...CTRY:;LANG:hr;SCL:1;SRV:;IPV:NLI;SFV:NSPM;PTR:;SFTY:;.... Les champs que Microsoft ne documente pas servent au diagnostic interne. Les champs documentés sont les suivants :

Valeurs de CAT (catégorie)

Valeurs de SFV (verdict du filtrage antispam)

Comment un consultant les lit : SKA, SFE et SKN signifient que le côté destinataire vous a mis en liste blanche. C’est fragile, car le placement dépend d’une exception et non de la réputation. SKB et BLK signifient que le côté destinataire vous a bloqué explicitement. Aucun travail de réputation côté expéditeur ne corrige cela ; l’organisation destinataire doit retirer l’entrée.

SCL : Spam Confidence Level

Le SCL est apposé sous forme d’en-tête X sur chaque message entrant. Le filtrage n’appose jamais les valeurs 2, 3 ou 4. Le SCL 7 est généralement fixé non par le filtrage antispam lui-même, mais par l’évaluation d’analystes, les échecs DMARC ou les règles de flux de messagerie.

BCL : Bulk Complaint Level

Le BCL est apposé dans l’en-tête X-Microsoft-Antispam (par exemple X-Microsoft-Antispam: BCL:5;). Microsoft l’attribue, en fonction du comportement de plaintes, aux messages des expéditeurs en nombre reconnus (« gray mail »), que leurs sources soient internes ou externes à Microsoft. C’est l’en-tête qui compte le plus pour les ESP, car c’est en pratique le score de réputation de plaintes par expéditeur que publie Microsoft.

Seuils et actions (un message est traité comme Bulk lorsque son BCL atteint ou dépasse le seuil) :

Ce que cela signifie pour un expéditeur : un message au BCL ≤ 3 arrive en boîte de réception partout. Un BCL 4 est classé en courrier indésirable par les clients qui utilisent la stratégie prédéfinie Strict (le minimum recommandé pour adhérer à la fonction de dossier Promotions est 5). Un BCL 5–6 est classé en courrier indésirable ou mis en quarantaine par les clients qui utilisent des stratégies prédéfinies. Un BCL ≥ 7 est classé en courrier indésirable par défaut chez tous les clients. Les administrateurs des destinataires peuvent ajuster le seuil, et voir le volume en nombre de chaque expéditeur dans le « bulk senders insight » du portail Defender.

Dossier Promotions (préversion, 2026) : les clients peuvent choisir de livrer le courrier en nombre sous le seuil BCL (même le courrier en nombre au BCL 0) dans un dossier Promotions plutôt qu’en boîte de réception. Ils le font avec une règle de flux de messagerie qui appose X-MS-Exchange-Organization-BulkStamping: 1, et le réglage « Bulk moves enabled » de la stratégie antispam. Microsoft 365 apprend des utilisateurs qui déplacent des messages vers ce dossier ou hors de celui-ci. Le message arrive tout de même en boîte de réception si l’expéditeur figure dans la liste Safe Senders de l’utilisateur. Pour les expéditeurs, cela signifie que même un courrier en nombre sans plaintes peut cesser d’arriver dans les boîtes de réception Microsoft 365 à cause de son classement, un peu comme avec les onglets de Gmail.

Authentication-Results et authentification composite

Microsoft appose les résultats standard spf=, dkim= et dmarc= (voir L’en-tête Authentication-Results), ainsi que des champs propres à Microsoft :

• Les valeurs de dmarc= comprennent la valeur non standard bestguesspass : aucun enregistrement DMARC n’existe, mais le message aurait réussi s’il en existait un.
• action= pour DMARC : oreject (rejeté selon la politique) ; pct.quarantine ou pct.reject (échec DMARC, mais livré parce que pct < 100 l’a exempté au hasard) ; permerror ; temperror.
• compauth est l’authentification composite : le verdict combiné de Microsoft à partir de SPF, DKIM, DMARC et de signaux du message, évalué par rapport au domaine From (5322.From). Un résultat compauth=fail ne garantit pas le classement en courrier indésirable si les autres signaux sont bons.
• reason est un code à trois chiffres qui explique le résultat de compauth :

Le motif 001 est le code que les consultants d’ESP voient le plus souvent. Il signifie que l’expéditeur n’avait aucune authentification, ou une authentification faible, et que Microsoft a classé le message en courrier indésirable sur un soupçon issu de l’authentification implicite. La correction consiste à aligner SPF et DKIM, et à publier un enregistrement DMARC. C’est la même correction que pour l’obligation de mai 2025 d’Outlook.com.

Tenant Allow/Block List (TABL) : ce que contrôlent les clients destinataires

La TABL est une liste d’exceptions propre à chaque client, à l’adresse https://security.microsoft.com/tenantAllowBlockList. Elle s’applique pendant le flux de messagerie et au moment du clic. Les types d’entrées sont : les domaines et adresses email (comparés à l’adresse From (5322.From), pas au MAIL FROM), les expéditeurs usurpés, les URL, les fichiers, les adresses IP et les domaines Teams. Les entrées de blocage l’emportent sur les entrées d’autorisation. Les entrées prennent effet en environ 5 minutes.

Ce que fait un blocage :

Expiration des entrées de blocage : pour les domaines et adresses, les fichiers et les URL, les entrées expirent après 30 jours par défaut (réglable à 90 jours ou à jamais). Les entrées des expéditeurs usurpés, des adresses IP et de Teams n’expirent jamais.

Comment fonctionnent les entrées d’autorisation, et pourquoi « il suffit qu’ils nous mettent en liste blanche » a ses limites :

• Les administrateurs ne peuvent pas créer directement d’entrées d’autorisation pour des verdicts de logiciel malveillant ou de phishing à haut niveau de confiance. Pour ceux-ci, le message, l’URL ou le fichier doit être soumis à Microsoft via la page Submissions (https://security.microsoft.com/reportsubmission) et confirmé sain ; ce n’est qu’ensuite qu’une entrée d’autorisation peut être créée. Les messages identifiés comme logiciels malveillants ou phishing à haut niveau de confiance sont toujours filtrés, quelles que soient les entrées d’autorisation.
• Les entrées d’autorisation directes pour les domaines et adresses, et pour les URL, ne peuvent l’emporter que sur ces verdicts : bulk, spam, spam à haut niveau de confiance, et phishing qui n’est pas à haut niveau de confiance.
• Les entrées d’autorisation pour les domaines et adresses, les fichiers et les URL sont conservées 45 jours après que le système de filtrage a jugé l’entité saine pour la dernière fois, puis retirées automatiquement (ou l’administrateur les règle pour expirer au plus 30 jours après leur création). Les entrées d’autorisation des expéditeurs usurpés n’expirent jamais. Microsoft peut retirer automatiquement les entrées d’autorisation qu’il juge inutiles, et envoie alors une alerte.
• Un expéditeur autorisé reste soumis au reste de la pile. Le message doit aussi réussir les contrôles d’authentification, d’URL et de fichiers, car une entrée d’autorisation ne dispense que des filtres liés à l’entité autorisée.
• Les autorisations d’URL créées par une soumission couvrent automatiquement les variantes et les sous-chemins de l’URL signalée.

Ce que cela signifie pour un expéditeur : si vos messages reçoivent un verdict de phishing à haut niveau de confiance chez le client d’un de vos clients, l’administrateur du destinataire ne peut pas simplement vous mettre en liste blanche. Les causes habituelles sont une URL ou un domaine bloqué dans sa TABL, ou une détection d’usurpation. La voie passe par une soumission de l’administrateur à Microsoft. Demandez à l’administrateur du destinataire de soumettre le message comme faux positif ; l’examen de Microsoft peut créer l’entrée d’autorisation.

Éléments de la FAQ utiles aux expéditeurs externes

La FAQ antispam de Microsoft documente ces causes lorsque des messages légitimes sont classés en courrier indésirable chez Microsoft 365, ainsi que leurs corrections :

La liste de Microsoft elle-même des meilleures pratiques d’envoi pour atteindre Microsoft 365 :

• Le domaine d’envoi se résout dans le DNS. (Sans enregistrement A ou MX, les messages passent par le pool à haut risque de Microsoft, quel que soit leur contenu.)
• L’adresse IP source a un enregistrement PTR.
• HELO ou EHLO et MAIL FROM sont cohérents et fondés sur un domaine, et le HELO correspond à l’enregistrement PTR.
• SPF est correct.
• Les messages sont signés avec DKIM avec une canonicalisation souple (relaxed), car une canonicalisation stricte des en-têtes peut casser lors du transit par le service.
• Les enregistrements WHOIS sont exacts.
• Les rebonds utilisent le format de la RFC 3464.
• Les adresses qui renvoient un NDR pour inexistence sont retirées.
• SNDS est surveillé.

La limitation des envois sortants à l’intérieur du service compte lorsqu’un client compromis envoie par Microsoft. Un utilisateur qui envoie plus de 50 % de spam sur une période donnée se voit interdire l’envoi, et le spam sortant passe par le pool de livraison à haut risque (des adresses IP distinctes) pour protéger le pool normal.

Voir aussi

• Exigences de Microsoft envers les expéditeurs, sur les politiques d’Outlook.com grand public, les codes d’erreur et l’obligation d’authentification de 2025
• Canaux d’escalade de Microsoft
• Microsoft SNDS et JMRP
• L’en-tête Authentication-Results, la base RFC 8601 que Microsoft étend