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

> Lire les en-têtes X-Forefront-Antispam-Report et X-Microsoft-Antispam, les échelles SCL et BCL avec les actions à chaque niveau, les codes de motif compauth, l'empilement des couches de filtrage EOP/MDO et le fonctionnement de la Tenant Allow/Block List du point de vue de l'expéditeur.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/fonctionnement-interne-du-filtrage-de-microsoft

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](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/exigences-microsoft-envers-les-expediteurs). 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](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/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 :

| Champ | Signification |
|---|---|
| `ARC` | Évaluation ARC : `AAR` (Authentication-Results enregistrés), `AMS` (signature du message), `AS` (signature des en-têtes avec validation de la chaîne `cv=` : none, pass ou fail) |
| `CAT` | Catégorie de menace appliquée (voir le tableau ci-dessous) |
| `CIP:[IP]` | Adresse IP de connexion, utilisable dans les listes d'autorisation et de blocage d'IP du client |
| `CTRY` | Pays ou région source, d'après l'adresse IP de connexion (peut différer de l'adresse IP d'origine) |
| `DIR` | Direction : `INB` entrant, `OUT` sortant, `INT` interne |
| `H:[helostring]` | Chaîne HELO ou EHLO du serveur qui se connecte |
| `IPV:CAL` | Filtrage antispam ignoré, car l'adresse IP source figurait dans la liste d'autorisation d'IP du client |
| `IPV:NLI` | Adresse IP absente de toute liste de réputation d'IP |
| `LANG` | Code pays de la langue du message (par exemple `ru_RU`) |
| `PTR:[ReverseDNS]` | Enregistrement PTR (DNS inverse) de l'adresse IP source |
| `SCL` | Spam confidence level (échelle ci-dessous) |
| `SFTY` | Marqueur de conseil de sécurité anti-phishing : `9.19` usurpation de domaine, `9.20` usurpation d'utilisateur, `9.25` conseil de sécurité de premier contact |
| `SFV` | Verdict du filtrage antispam (tableau ci-dessous) |
| `SRV:BULK` | Identifié comme bulk par le seuil BCL. Avec `MarkAsSpamBulkMail` activé (par défaut), le courrier en nombre est marqué comme spam au SCL 6 |
| `X-CustomSpam:[ASFOption]` | Correspond à un réglage Advanced Spam Filter (ASF) (heuristiques de contenu comme les balises embed, JavaScript dans le HTML ou un message vide). Le champ est ajouté après l'exécution des règles de flux de messagerie, qui ne peuvent donc pas s'en servir |

### Valeurs de CAT (catégorie)

| Valeur | Signification | Valeur | Signification |
|---|---|---|---|
| `AMP` | Anti-malware | `INTOS` | Phishing interne à l'organisation |
| `BIMP` | Usurpation de marque (MDO) | `MALW` | Logiciel malveillant |
| `BULK` | Bulk | `OSPM` | Spam sortant |
| `DIMP` | Usurpation de domaine (MDO) | `PHSH` | Phishing |
| `FTBP` | Filtre anti-malware des pièces jointes courantes | `SAP` | Safe Attachments (MDO) |
| `GIMP` | Usurpation détectée par la mailbox intelligence (MDO) | `SPM` | Spam |
| `HPHSH` ou `HPHISH` | Phishing à haut niveau de confiance | `SPOOF` | Usurpation d'identité |
| `HSPM` | Spam à haut niveau de confiance | `UIMP` | Usurpation d'utilisateur (MDO) |

### Valeurs de SFV (verdict du filtrage antispam)

| Valeur | Signification |
|---|---|
| `SFV:NSPM` | Marqué comme non-spam ; livré normalement |
| `SFV:SPM` | Marqué comme spam par le filtrage du contenu |
| `SFV:BLK` | Bloqué : l'expéditeur figure dans la liste Blocked Senders de l'utilisateur destinataire (filtrage ignoré) |
| `SFV:SFE` | Autorisé : l'expéditeur figure dans la liste Safe Senders de l'utilisateur destinataire (filtrage ignoré) |
| `SFV:SKA` | Filtrage ignoré : l'expéditeur ou le domaine figure dans la liste d'autorisation de la stratégie antispam ; livré en boîte de réception |
| `SFV:SKB` | Marqué comme spam : l'expéditeur ou le domaine figure dans la liste de blocage de la stratégie antispam |
| `SFV:SKN` | Marqué comme non-spam avant le filtrage (par exemple, une règle de flux de messagerie a fixé SCL -1 ou un contournement) |
| `SFV:SKS` | Marqué comme spam avant le filtrage (par exemple, une règle de flux de messagerie a fixé SCL 5–9) |
| `SFV:SKQ` | Libéré de la quarantaine vers les destinataires prévus |

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.

| SCL | Définition | Action par défaut |
|---|---|---|
| -1 | Filtrage ignoré (expéditeur ou destinataire sûr, ou liste d'autorisation d'IP) | Boîte de réception |
| 0, 1 | Pas du spam | Boîte de réception |
| 5, 6 | **Spam** | Stratégies par défaut et personnalisées, et stratégie prédéfinie Standard : dossier Courrier indésirable. Stratégie prédéfinie Strict : quarantaine |
| 7, 8, 9 | **Spam à haut niveau de confiance** | Stratégies par défaut et personnalisées : dossier Courrier indésirable. Stratégies prédéfinies Standard et Strict : quarantaine |

## 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.

| BCL | Signification |
|---|---|
| 0 | Ne provient pas d'un expéditeur en nombre |
| 1–3 | Expéditeur en nombre qui génère **peu** de plaintes |
| 4–7 | Expéditeur en nombre qui génère un nombre **mitigé** de plaintes |
| 8–9 | Expéditeur en nombre qui génère un nombre **élevé** de plaintes |

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

| Stratégie | Seuil BCL | Action au seuil ou au-delà |
|---|---|---|
| Stratégies antispam par défaut et nouvelles stratégies personnalisées | **7** | Dossier Courrier indésirable |
| Stratégie de sécurité prédéfinie Standard | **6** | Dossier Courrier indésirable |
| Stratégie de sécurité prédéfinie Strict | **5** | Quarantaine |

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](https://emailmarketing.net/fr/apprendre/authentification/en-tete-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 :

| Code | Signification |
|---|---|
| 000 | Échec de l'authentification explicite : échec DMARC avec `p=quarantine` ou `p=reject` |
| 001 | Échec de l'authentification implicite : aucun enregistrement d'authentification, ou des enregistrements faibles (SPF `~all` ou `?all`, DMARC `p=none`) |
| 002 | La politique de l'organisation interdit explicitement l'usurpation pour ce couple d'expéditeur et de domaine |
| 010 | Échec DMARC avec reject ou quarantine, et le domaine d'envoi est l'un des domaines acceptés de l'organisation (usurpation interne à l'organisation) |
| 1xx (100–130) | Réussite : 100 SPF ou DKIM réussi avec alignement. 101 DKIM par le domaine From. 102 MAIL FROM et From alignés, et SPF réussi. 103 ou 104 le PTR est aligné sur le domaine From. 108 échec DKIM attribué à un saut antérieur légitime. 109 pas d'enregistrement DMARC, mais le message réussirait. 111 temperror ou permerror DMARC, mais SPF ou DKIM aligné. 112 délai DNS dépassé lors de la résolution DMARC. 115 envoyé depuis une organisation M365 dont le From est un domaine accepté. 116 le MX du domaine From est aligné sur le PTR de l'adresse IP de connexion. 130 un scelleur ARC de confiance a annulé l'échec DMARC |
| 2xx (201, 202) | Réussite partielle sur l'alignement du PTR ou du sous-réseau (`compauth=softpass`) |
| 3xx, 4xx, 9xx | Non vérifié, ou contourné (`compauth=none`) |
| 501, 502 | DMARC non appliqué : un NDR valide avec un contact établi, ou un NDR valide pour les messages de l'organisation elle-même |
| 6xx (601) | Échec de l'authentification implicite ; 601 signifie l'usurpation d'un domaine accepté à l'intérieur de l'organisation |
| 7xx (701–704) | DMARC non appliqué, car l'organisation a un historique de messages légitimes provenant de cette infrastructure |
| 905 | DMARC non appliqué, en raison d'un routage complexe (un saut sur site ou chez un tiers avant M365) |

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](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/exigences-microsoft-envers-les-expediteurs) 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 :

| Entité bloquée | Effet |
|---|---|
| Domaine ou adresse email | Le message est traité comme **phishing à haut niveau de confiance** et mis en quarantaine (et pas seulement traité comme spam). Les utilisateurs du client ne peuvent pas non plus lui écrire (`550 5.7.703 ... blocked by your organization using Tenant Allow Block List`) |
| URL ou fichier | Le message est mis en quarantaine comme phishing à haut niveau de confiance ou comme logiciel malveillant, respectivement |
| Adresse IP | Rejeté en bordure du service |
| Expéditeur usurpé | Annulation manuelle d'une autorisation de la spoof intelligence |

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 :

| Cause | Correction |
|---|---|
| Échec d'authentification (SPF, DKIM ou DMARC, qui entraîne un échec compauth) | Corriger SPF, DKIM et DMARC pour le domaine d'envoi |
| Réputation de l'expéditeur (historique de l'adresse IP ou du domaine, listes de blocage, faible volume) | Vérifier les listes de blocage tierces et la présence d'un enregistrement PTR valide, et examiner [SNDS](https://emailmarketing.net/fr/apprendre/outils-postmaster/microsoft-snds-et-jmrp) |
| Déclencheurs de contenu (liens trop nombreux, raccourcisseurs d'URL, balises de formulaire, scripts intégrés, messages composés uniquement d'images) | Revoir le contenu ; le destinataire a peut-être activé des options ASF |
| Le BCL a atteint le seuil du client | Pas du spam, mais un classement en bulk ; réduire les plaintes, ou le destinataire ajuste son seuil ou ses expéditeurs sûrs |
| Exceptions du destinataire (règle de flux de messagerie, liste de blocage d'une stratégie, Blocked Senders de l'utilisateur) | Seul le destinataire peut les retirer |
| Un service de filtrage intermédiaire masque la véritable adresse IP source | Le destinataire active Enhanced Filtering for Connectors (« skip listing ») |

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](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/exigences-microsoft-envers-les-expediteurs), sur les politiques d'Outlook.com grand public, les codes d'erreur et l'obligation d'authentification de 2025
- [Canaux d'escalade de Microsoft](https://emailmarketing.net/fr/apprendre/fournisseurs-de-messagerie/canaux-d-escalade-de-microsoft)
- [Microsoft SNDS et JMRP](https://emailmarketing.net/fr/apprendre/outils-postmaster/microsoft-snds-et-jmrp)
- [L'en-tête Authentication-Results](https://emailmarketing.net/fr/apprendre/authentification/en-tete-authentication-results), la base RFC 8601 que Microsoft étend