Courriels Microsoft 365 dans les indésirables : trouver la cause

Commencer par le sens du message

Un courriel « dans les indésirables » peut décrire deux incidents différents. Un message entrant vers Microsoft 365 a été classé par Exchange Online Protection ou Defender for Office 365; un message sortant a été accepté par Gmail, Outlook.com ou un autre fournisseur, puis classé par ce destinataire. Les preuves et les leviers ne sont pas les mêmes.

Déterminez d'abord si le problème touche les messages reçus ou envoyés. Conservez ensuite un exemple original avec ses en-têtes complets, l'expéditeur, le destinataire, l'heure UTC et le Message-ID. Une capture du dossier Indésirables ne permet pas d'établir la cause.

Collecter un exemple exploitable avant de modifier la configuration

N'ajoutez pas immédiatement tout un domaine à une liste d'autorisation. Une exception large masque le signal, peut contourner l'authentification et augmente le risque d'usurpation.

• Télécharger le message original en .eml ou copier tous les en-têtes Internet; ne pas simplement le transférer.
• Noter les adresses exactes, l'heure UTC, l'objet, le Message-ID et la source : Exchange Online, CRM, ERP, photocopieur ou plateforme marketing.
• Définir la portée : un message, une campagne, un expéditeur, une boîte, un domaine destinataire ou tous les destinataires.
• Distinguer Junk, quarantaine, rejet par NDR et message absent : ces résultats n'ont pas la même cause.
• Conserver un exemple qui fonctionne et un qui échoue pour comparer une seule variable à la fois.

1. Suivre le message dans Exchange Online

Dans le Centre d'administration Exchange, Mail flow > Message trace suit les messages qui traversent l'organisation. La recherche moderne couvre jusqu'à 90 jours, avec des limites de détail selon l'ancienneté. Get-MessageTraceV2 remplace progressivement l'ancien Get-MessageTrace.

Pour un message entrant, recherchez l'action finale, les règles, les redirections et la livraison en boîte ou en quarantaine. Pour un message sortant, Delivered signifie généralement que le système distant a accepté le message; il ne garantit pas la boîte de réception. Obtenez alors les en-têtes chez le destinataire.

$Start = (Get-Date).AddHours(-24)
$End = Get-Date
Connect-ExchangeOnline -ShowBanner:$false

$trace = Get-MessageTraceV2 -StartDate $Start -EndDate $End `
  -SenderAddress 'facturation@contoso.com' `
  -RecipientAddress 'client@example.net' -ResultSize 5000

$trace | Select Received,SenderAddress,RecipientAddress,Subject,Status,MessageTraceId
$trace | ForEach-Object {
  Get-MessageTraceDetailV2 -MessageTraceId $_.MessageTraceId `
    -RecipientAddress $_.RecipientAddress
} | Select Date,Event,Action,Detail

• Microsoft — Message trace dans le nouveau Centre d'administration Exchange ↗
• Microsoft — Get-MessageTraceV2 ↗

2. Lire les en-têtes qui expliquent le verdict

Pour un message reçu dans Microsoft 365, examinez Authentication-Results, X-Forefront-Antispam-Report, X-Microsoft-Antispam et les en-têtes ARC. Le Message Header Analyzer les rend plus lisibles, mais conservez la copie brute.

SCL représente le niveau de confiance de pourriel; BCL mesure la ressemblance avec du courrier en vrac indésirable. SFV décrit le verdict du filtre et CAT la catégorie, par exemple bulk, spam, spoof ou phishing. Lisez toujours le verdict, la politique, les remplacements et l'action ensemble.

• Microsoft — Dépanner les politiques anti-spam ↗
• Microsoft — Spam Confidence Level ↗
• Microsoft — Bulk Complaint Level ↗

3. Vérifier SPF, DKIM, DMARC et l'alignement

SPF valide l'adresse d'enveloppe 5321.MailFrom; DKIM valide une signature et son domaine d=; DMARC exige que SPF ou DKIM réussisse avec un domaine aligné sur l'adresse visible 5322.From. Un spf=pass peut donc coexister avec dmarc=fail lorsque les domaines ne sont pas alignés.

Inventoriez toutes les sources qui utilisent votre domaine : Microsoft 365, SaaS, campagnes, ERP, sites Web et appareils. Favorisez une signature DKIM alignée pour les services tiers. Le transfert peut casser SPF; DKIM peut survivre si le message n'est pas modifié, et ARC peut préserver les résultats à travers un intermédiaire de confiance.

Ne publiez pas un deuxième enregistrement SPF et ne dépassez pas sa limite de dix recherches DNS. Une politique DMARC p=reject mal préparée peut bloquer des sources légitimes; le déploiement progressif et l'analyse des rapports restent essentiels.

$Domain = 'contoso.com'
Resolve-DnsName -Type TXT $Domain
Resolve-DnsName -Type TXT "_dmarc.$Domain"
Resolve-DnsName -Type CNAME "selector1._domainkey.$Domain"
Resolve-DnsName -Type CNAME "selector2._domainkey.$Domain"

Connect-ExchangeOnline -ShowBanner:$false
Get-DkimSigningConfig -Identity $Domain |
  Format-List Domain,Enabled,Status,Selector1CNAME,Selector2CNAME

• Article — Configurer DMARC, SPF et DKIM sans bloquer les courriels →
• Microsoft — Guide SecOps de l'authentification des courriels ↗

4. Si les messages entrants vont dans Junk ou en quarantaine

Secure by default empêche certains contournements pour les menaces graves. Une règle SCL -1 ou une IP autorisée ne doit pas devenir un correctif général : elle réduit la visibilité et peut contourner l'authentification.

• Identifier la politique anti-spam, anti-hameçonnage, Safe Attachments ou Safe Links qui a réellement agi, sa priorité et ses destinataires.
• Chercher une règle de transport qui définit SCL, redirige, modifie les en-têtes ou contourne le filtrage.
• Vérifier spoof intelligence, les protections d'usurpation et les domaines acceptés.
• Comparer les paramètres de boîte et les expéditeurs bloqués si un seul utilisateur est touché.
• Vérifier les connecteurs et Enhanced Filtering lorsqu'une passerelle tierce précède Microsoft 365.
• Dans Explorer, corréler la technologie de détection, l'action, les overrides et la politique.

$Mailbox = 'utilisateur@contoso.com'
Get-MailboxJunkEmailConfiguration -Identity $Mailbox |
  Format-List Enabled,TrustedSendersAndDomains,BlockedSendersAndDomains
Get-HostedContentFilterPolicy |
  Select Name,SpamAction,HighConfidenceSpamAction,BulkSpamAction,BulkThreshold
Get-HostedContentFilterRule |
  Select Name,State,Priority,HostedContentFilterPolicy,SentTo,SentToMemberOf
Get-TransportRule | Select Name,State,Mode,Priority,SetSCL,FromScope,SentTo

• Microsoft — Ordre et priorité des protections ↗
• Microsoft — Secure by default ↗

5. Si vos messages sortants vont dans les indésirables externes

Après avoir confirmé que Microsoft 365 a remis le message, demandez au destinataire l'original ou ses en-têtes complets. Le fournisseur distant décide du placement selon ses propres signaux : authentification, réputation de domaine et d'IP, plaintes, volume, régularité, contenu, liens et comportement des destinataires.

Séparez le trafic transactionnel, humain et marketing lorsque les volumes diffèrent. Une plateforme de masse devrait utiliser un domaine ou sous-domaine géré, DKIM aligné, un désabonnement approprié et des listes entretenues. Les appareils ne devraient pas envoyer directement vers Internet sans PTR, HELO cohérent, authentification et surveillance.

Changer quelques mots ou renvoyer le même message en boucle ne répare pas une réputation. Testez vers plusieurs fournisseurs, une variable à la fois. Aucune configuration Microsoft 365 ne garantit le placement en boîte de réception chez un tiers.

6. Contrôler les sources tierces et les connecteurs

Les CRM, ERP, formulaires Web, photocopieurs et plateformes de notification sont souvent la véritable source. Documentez pour chacun le domaine d'enveloppe, le domaine From, DKIM, l'IP ou le connecteur, le propriétaire et le volume attendu.

Si une passerelle tierce précède Microsoft 365, le dernier saut peut masquer l'IP d'origine. Configurez Enhanced Filtering for Connectors selon l'architecture prise en charge au lieu d'autoriser largement l'IP de la passerelle.

• Microsoft — Enhanced Filtering for Connectors ↗
• Microsoft — Configurer les sealers ARC de confiance ↗

7. Corriger un faux positif sans créer une brèche durable

Pour un message légitime mal classé par Microsoft, utilisez Submissions dans Defender et fournissez l'original. Selon le verdict, Microsoft peut créer une autorisation temporaire et réévaluer la détection. Documentez le propriétaire, le motif, la portée et l'échéance de toute exception.

La Tenant Allow/Block List n'est pas une liste blanche universelle. Une autorisation ne corrige pas SPF, DKIM, DMARC, la réputation ou une application compromise. Corrigez la source et gardez l'exception aussi étroite et courte que possible.

• Microsoft — Soumettre des messages pour analyse ↗
• Microsoft — Tenant Allow/Block List ↗

8. Vérifier l'envoi anormal et les comptes restreints

Un compte compromis ou une application mal configurée peut déclencher les politiques anti-spam sortantes. Vérifiez Restricted entities, les alertes, les règles de boîte, les transferts, les consentements OAuth et les sources applicatives.

Ne retirez pas un utilisateur de Restricted entities avant d'avoir contenu le compte et identifié la source. Sinon, l'activité et le blocage peuvent revenir.

• Article — Que faire lorsqu'un compte Microsoft 365 est compromis? →
• Microsoft — Politiques anti-spam sortantes ↗

Plan de diagnostic réutilisable

Quand demander une analyse Microsoft 365 complète

Escaladez lorsque plusieurs domaines sont touchés, que la source reste inconnue, qu'un compte peut être compromis, que des connecteurs modifient le chemin ou que les journaux limitent l'analyse. Une revue structurée relie DNS, Exchange Online, Defender, applications et preuves côté destinataire sans remplacer le problème par une liste blanche fragile.

Un audit Microsoft 365 peut aussi repérer les politiques qui se chevauchent, les sources non inventoriées et les exceptions historiques, puis produire un plan priorisé avec responsables, tests et retour arrière.

• Service — Audit de sécurité Microsoft 365 et Entra ID →