Des expéditeurs reçoivent un NDR « Requested action not taken: mailbox unavailable (S2017062302) », alors que le message arrive bien chez le destinataire Hotmail/Outlook. Voici un guide pratico‑pratique pour identifier la cause, corriger et faire cesser ces notifications parasites.
Rejets « Requested action not taken : mailbox unavailable (S2017062302) » malgré la bonne réception des messages
Problème posé
Plusieurs correspondants écrivent à une adresse Hotmail/Outlook (compte personnel Outlook.com ou boîte Microsoft 365) : leur message est livré, mais ils reçoivent en retour un rapport de non‑remise (NDR) faisant référence à mailbox unavailable (S2017062302). Ce phénomène crée de la confusion, incite à renvoyer inutilement le même courriel et dégrade la confiance dans la messagerie. L’objectif est de comprendre pourquoi cela survient, d’assainir la configuration et d’éliminer les NDR fantômes.
Solutions et vérifications recommandées
| Étape | Action | Pourquoi / résultat attendu |
|---|---|---|
| 1 | Contrôler les règles et le transfert dans Outlook Web → Paramètres ▶ Courrier ▶ Transfert / Règles ; supprimer tout renvoi ou règle inconnue. | Des NDR « fantômes » apparaissent fréquemment après une compromission où un pirate a installé un transfert ou une règle cachée. Les supprimer coupe la source d’anomalies et de boucles de routage. |
| 2 | Sécuriser le compte : changer le mot de passe, activer la MFA, passer en revue alias et méthodes de récupération. | Empêche toute ré‑injection de règles malveillantes et verrouille l’accès non autorisé. |
| 3 | Demander aux expéditeurs de purger le cache de destinataires (supprimer l’adresse dans la saisie semi‑automatique puis la recréer). | Après une migration ou un changement d’alias, un LegacyDN obsolète en cache peut déclencher un NDR, même si le message est finalement routé via la bonne adresse. |
| 4 | Vérifier l’orthographe et l’existence des alias côté Microsoft 365 ; recréer un alias manquant si nécessaire. | Les codes de type 5.1.x « user unknown » surgissent quand un alias a été supprimé ou mal saisi. Réconcilier les alias supprime ces rejets. |
| 5 | Analyser la machine de l’utilisateur (antivirus complet, EDR si disponible). | Certains malwares injectent des règles ou envoient du spam, ce qui déclenche des réponses de protection et des NDR secondaires. |
| 6 | Ouvrir un ticket auprès du support Microsoft si le phénomène persiste ou touche plusieurs boîtes. | Le support peut purger des caches Exchange Online Protection (EOP), corriger un alias X.500 côté service ou indiquer un correctif serveur en cours de déploiement. |
Informations complémentaires utiles
- Nature du code S2017062302 : identifiant interne Exchange Online Protection pour des conditions « mailbox unavailable » diverses (alias manquant, LegacyDN obsolète, routage alternatif, cache EOP incohérent, etc.).
- Impact DMARC / SPF / DKIM : une incohérence d’authentification (enveloppe vs. en‑tête From:) peut conduire EOP à générer un NDR de façade même si la livraison s’est faite via un chemin de repli.
- Contournement temporaire : informer les expéditeurs que leurs messages sont bien reçus et qu’aucune ré‑expédition n’est nécessaire, afin d’éviter les doublons.
- Expiration automatique : une fois règles, alias et caches corrigés, les NDR disparaissent généralement sous 24–48 h, le temps que les caches se synchronisent.
Procédure pas‑à‑pas : assainir, vérifier, confirmer
1) Contrôler règles et transferts dans Outlook Web
- Connectez‑vous à Outlook sur le web (OWA) avec le compte concerné.
- Allez dans Paramètres (icône d’engrenage) → Courrier → Transfert : désactivez toute redirection ou transfert vers des adresses inconnues.
- Dans Courrier → Règles : supprimez ou désactivez toute règle inconnue (ex. « rediriger tous les messages », « supprimer si l’expéditeur est… »).
- Vérifiez aussi Courrier indésirable → Expéditeurs et domaines bloqués, au cas où des éléments auraient été ajoutés sans votre accord.
Astuce : renommez temporairement les règles légitimes ([OK] en préfixe) ; tout ce qui n’est pas préfixé ressortira immédiatement lors d’un prochain audit.
2) Sécuriser le compte (MFA, récupération, sessions)
- Changer le mot de passe et déconnecter les sessions actives sur tous les appareils (fonction « Se déconnecter partout », si disponible).
- Activer la MFA (application d’authentification ou SMS) et vérifier les méthodes de récupération (adresse secondaire, téléphone, questions).
- Passer en revue les alias de connexion et supprimer ceux qui ne servent plus.
- Dans les paramètres de sécurité, révoquer les applications héritées ou « autorisations persistantes » douteuses.
3) Purger la saisie semi‑automatique chez l’expéditeur
Le cache de destinataires (« AutoComplete ») enregistre un identifiant interne (LegacyExchangeDN) ou un chemin X.500. Après migration, renommage ou fusion de boîtes, ces marqueurs peuvent devenir obsolètes et produire des bounces même si le serveur finit par livrer via un autre alias.Outlook pour Windows : vider la saisie semi‑automatique
- Ouvrez Fichier → Options → Courrier.
- Dans Envoyer des messages, cliquez sur Vider la liste de saisie semi‑automatique.
- Dans un nouveau message, supprimez la suggestion d’adresse (touche Suppr ou icône ✕ à droite du nom), puis ressaisissez l’adresse complète.
Outlook sur Mac : nettoyer les suggestions
- Commencez un nouveau courriel et tapez les premières lettres de l’adresse.
- Survolez la suggestion → cliquez sur Supprimer la suggestion (✕).
- Dans Outlook → Préférences → Rédaction, utilisez Effacer la liste des adresses récentes si l’option est présente.
Outlook sur le web (OWA) : effacer les contacts suggérés
- Paramètres → Courrier → Rédiger et répondre (ou Général → Confidentialité et données selon la version).
- Utilisez l’option pour effacer les contacts récents/suggestions de destinataires.
iOS / Android : supprimer la suggestion
Dans l’application Outlook mobile, créez un nouveau message, tapez l’adresse, puis supprimez la suggestion via l’icône ✕. Au besoin, supprimez et recréez le contact local.
4) Vérifier l’existence des alias (M365 et Outlook.com)
Deux cas de figure :
- Microsoft 365 (entreprise/éducation) : dans le Centre d’administration, ouvrez l’utilisateur → Adresses de messagerie. Confirmez que l’adresse principale (
SMTP:) et les alias (smtp:) sont corrects. Ajoutez l’ancien X.500 si vous migrez depuis un autre tenant ou Exchange on‑prem. - Outlook.com (compte personnel) : dans la gestion du compte Microsoft, rubrique Gérer la façon dont vous vous connectez, vérifiez l’alias principal et supprimez ceux qui ne sont plus utilisés.
Bon à savoir : quand un NDR mentionne une adresse IMCEAEX, convertissez‑la en alias X.500 et ajoutez‑la à la boîte M365. Cela résout quasiment instantanément les rejets liés à l’ancien LegacyExchangeDN.
5) Analyse sécurité poste et navigation
- Lancez une analyse antivirus complète (et, si possible, un outil EDR) sur la machine de l’utilisateur.
- Vérifiez les extensions de navigateur inhabituelles et supprimez celles qui ont un comportement intrusif (lecture d’e‑mails, redirections).
- Regardez l’historique des connexions au compte : connexions depuis des pays inattendus ? Révoquez ces sessions et modifiez le mot de passe.
6) Escalade support
Si plusieurs utilisateurs sont affectés ou si le phénomène persiste après corrections locales, ouvrez un ticket. Le support Microsoft peut purger un cache EOP, diagnostiquer un incident de routage régional ou confirmer un correctif côté service.
Diagnostic avancé pour administrateurs Microsoft 365
Contrôles rapides en PowerShell Exchange Online
Connectez‑vous à Exchange Online et exécutez ces vérifications :
# Vérifier un éventuel transfert côté boîte
Get-Mailbox -Identity user@domaine.tld `
-Properties ForwardingSmtpAddress,ForwardingAddress,DeliverToMailboxAndForward |
Format-List DisplayName,ForwardingSmtpAddress,ForwardingAddress,DeliverToMailboxAndForward
# Lister les règles de boîte de réception
Get-InboxRule -Mailbox [user@domaine.tld](mailto:user@domaine.tld) |
Select-Object Name,Enabled,Priority,ForwardTo,RedirectTo,DeleteMessage,StopProcessingRules
# Chercher des règles suspectes (pattern large)
Get-InboxRule -Mailbox [user@domaine.tld](mailto:user@domaine.tld) |
Where-Object { $*.ForwardTo -or $*.RedirectTo -or $*.DeleteMessage -or $*.MarkAsJunk } |
Format-Table Priority,Name,ForwardTo,RedirectTo,DeleteMessage
# Désactiver une règle douteuse
Disable-InboxRule -Identity "NomDeLaRègle" -Mailbox [user@domaine.tld](mailto:user@domaine.tld)
# Vérifier les adresses proxy (SMTP et X.500)
Get-Mailbox -Identity [user@domaine.tld](mailto:user@domaine.tld) | Select-Object -ExpandProperty EmailAddresses Ajouter un alias X.500 depuis un NDR IMCEAEX
- Dans le NDR, repérez la ligne contenant
IMCEAEX: c’est l’ancienne identité X.500 encapsulée. - Transformez‑la en adresse X.500 (remplacement des séquences d’encodage, ou utilisez l’option « Copier en X.500 » de votre outil favori).
- Ajoutez la valeur au jeu d’adresses de la boîte :
Set-Mailbox user@domaine.tld -EmailAddresses @{add="X500:/O=ORG/OU=.../CN=RECIPIENTS/CN=UTILISATEUR"}
Une fois l’alias ajouté, les expéditeurs peuvent conserver le contact existant ; la résolution X.500 élimine les NDR liés à l’ancien LegacyDN.
Message Trace : confirmer la livraison réelle
$start = (Get-Date).AddDays(-7)
$end = Get-Date
Get-MessageTrace -StartDate $start -EndDate $end -RecipientAddress user@domaine.tld |
Where-Object {$_.Status -in @("Delivered","Expanded","Resolved")} |
Select-Object Received,SenderAddress,RecipientAddress,MessageId,Status |
Sort-Object Received -Descending
Si la trace indique Delivered alors qu’un expéditeur reçoit un NDR S2017062302, vous êtes face à un NDR parasite. Poursuivez avec le nettoyage de caches et la validation des alias.
Rétention des caches et latence
Après correction (règles supprimées, alias ajoutés), attendez 24 à 48 heures pour la dissipation complète, le temps que les caches de transport et d’annuaires se synchronisent. En environnement hybride, la réplication AD/Entra ID peut ajouter quelques heures.
Comprendre les causes typiques de S2017062302
| Cause racine | Symptômes observés | Correctif recommandé |
|---|---|---|
| Règle/Transfert malveillant | Copie silencieuse vers une adresse externe, dossiers vides, réponses étranges | Supprimer les règles, changer le mot de passe, activer MFA |
| Alias X.500 manquant (migration) | NDR mentionnant IMCEAEX, contacts « anciens » qui échouent | Ajouter l’alias X.500 à la boîte, purger AutoComplete |
| Cache AutoComplete obsolète chez l’expéditeur | Seuls certains expéditeurs reçoivent un NDR, d’autres non | Supprimer la suggestion d’adresse, recréer le contact |
| Alias supprimé ou mal orthographié | Codes 5.1.x « user unknown », mais délivrance via l’adresse principale | Recréer l’alias, corriger l’orthographe côté contact |
| Incohérences SPF/DMARC/DKIM | Livraison effective mais avertissement/NDR côté passerelle | Corriger les enregistrements DNS et l’alignement des domaines |
| Cache EOP/Transport | Phénomène transitoire affectant plusieurs expéditeurs | Attendre la propagation, ou demander une purge côté Microsoft |
Bonnes pratiques DNS et authentification (réduit les faux NDR)
Si votre domaine envoie des messages vers Outlook/Hotmail :
- SPF : un seul enregistrement TXT, incluez vos émetteurs légitimes (ex. Microsoft 365, votre routeur SMTP, votre outil marketing) et terminez par
-allsi vous maîtrisez la liste, sinon~allen phase de transition. - DKIM : activez la signature côté plateforme d’envoi. Pour M365, publiez les deux sélecteurs et activez la signature pour toutes les boîtes.
- DMARC : commencez en
p=noneavec agrégation (rua) pour observer, puis montez versp=quarantinevoirep=rejectquand l’écosystème est propre. - Alignement : alignez le domaine d’en‑tête From (visible) et le domaine d’enveloppe (retour) ou le Return‑Path, surtout si vous utilisez du routage indirect.
Un domaine correctement authentifié réduit les anomalies côté EOP et, par ricochet, les NDR de façade.
Modèles de communication prêts à l’emploi
Message au destinataire interne
Bonjour,
Nous avons identifié des NDR « mailbox unavailable (S2017062302) » envoyés à certains expéditeurs alors que vos messages arrivent bien. Nous avons nettoyé les règles/alias et le phénomène devrait cesser sous 24–48 h. Merci de nous signaler toute récidive.
Message à l’expéditeur externe
Bonjour,
Votre message du [date] a été correctement reçu malgré une notification automatique « mailbox unavailable (S2017062302) ». Cette alerte est sans action de votre part. Si vous voyez encore l’erreur, supprimez notre contact de votre saisie semi‑automatique puis retapez l’adresse.
Arbre de décision rapide
- Message livré ? Oui → passez à 2. Non → traitez un incident de non‑remise standard (DNS, boîtes pleines, blocage).
- Certains expéditeurs seulement ? Oui → purgez AutoComplete chez eux et ajoutez alias X.500 si NDR IMCEAEX. Non → passez à 3.
- Règles/transferts présents ? Oui → supprimez et sécurisez le compte. Non → passez à 4.
- Alias manquants ou renommage récent ? Oui → recréez alias + X.500. Non → passez à 5.
- Plusieurs boîtes touchées ? Oui → ouvrez un ticket Microsoft (purge EOP). Non → patientez 24–48 h après corrections.
FAQ
Pourquoi un NDR si le message est livré ?
Parce que le serveur émetteur s’appuie sur un identifiant obsolète, ou qu’un composant intermédiaire (passerelle, cache de transport) renvoie un code d’erreur transitoire alors que la plateforme Microsoft route finalement via un alias valide.
Dois‑je renvoyer mon message ?
Non, si le destinataire confirme la réception. Le renvoi crée du bruit et complique l’analyse.
Combien de temps avant la disparition des NDR ?
Après nettoyage (règles, alias, caches), comptez généralement 24–48 heures.
Comment reconnaître un alias X.500 manquant ?
Le NDR contient souvent une séquence IMCEAEX. C’est un indice clair qu’un ancien LegacyExchangeDN doit être ajouté comme alias X.500 à la boîte Microsoft 365.
Et si l’utilisateur est sur Outlook.com (compte perso) ?
Le principe est identique : supprimez les règles/transferts, sécurisez le compte, vérifiez les alias au niveau du compte Microsoft et demandez aux expéditeurs de purger leurs suggestions.
Checklist opérationnelle
- ✅ Règles de boîte et transfert vérifiés/supprimés
- ✅ Mot de passe changé et MFA activée
- ✅ Alias SMTP et X.500 validés/complétés
- ✅ Cache AutoComplete purgé chez les expéditeurs touchés
- ✅ Poste de l’utilisateur scanné (antivirus/EDR)
- ✅ Message Trace confirmant la livraison
- ✅ Ticket Microsoft ouvert si effet « cluster » ou persistance
Exemples de messages d’erreur et interprétation
| Extrait NDR | Interprétation | Action |
|---|---|---|
Requested action not taken: mailbox unavailable (S2017062302) | Signal générique côté EOP / boîte injoignable à l’instant T, souvent dû à un alias/cache | Vérifier alias, purger caches, attendre la propagation |
IMCEAEX-_O=...@domain | Ancien LegacyExchangeDN encapsulé | Ajouter un alias X.500 et purger AutoComplete |
550 5.1.10 RESOLVER.ADR.RecipientNotFound | Alias supprimé/mal saisi | Recréer l’alias et corriger les contacts |
Bonnes pratiques durables
- Gouvernance des alias : documentez les changements (renommages, consolidations) et publiez une liste officielle d’adresses par utilisateur.
- Communication IT ↔ métiers : informez en amont des migrations pour permettre aux contacts d’actualiser leurs carnets d’adresses.
- Hygiène des contacts : recommandez de recréer le contact au moindre doute (plutôt que de corriger seulement le nom).
- Surveillance : activez des alertes sur la création de règles de boîte et les changements d’alias.
Conclusion
Le code S2017062302 est un indicateur, pas une fatalité. Dans la majorité des cas, la combinaison sécurité du compte (suppression des règles et transferts, MFA), réconciliation des alias (y compris X.500) et nettoyage des caches expéditeurs suffit à faire disparaître durablement les NDR « mailbox unavailable ». En environnement Microsoft 365, un contrôle PowerShell rapide et, si besoin, une purge côté Microsoft achèvent de stabiliser la situation. Le cœur de la solution est d’éliminer les références obsolètes et de verrouiller les comptes pour éviter toute réintroduction d’anomalies.
Annexe : scripts et commandes utiles
Exporter toutes les règles d’une boîte
Get-InboxRule -Mailbox user@domaine.tld |
Select-Object DisplayName,Enabled,Description,ForwardTo,RedirectTo,DeleteMessage |
Export-Csv .\inboxrules-user.csv -NoTypeInformation -Encoding UTF8Rechercher des transferts sur toutes les boîtes
Get-Mailbox -ResultSize Unlimited |
Select-Object DisplayName,PrimarySmtpAddress,ForwardingSmtpAddress,DeliverToMailboxAndForward |
Where-Object { $_.ForwardingSmtpAddress -or $_.DeliverToMailboxAndForward } |
Format-Table -AutoSizeAjouter en masse un alias X.500 (liste CSV)
# CSV: UserPrincipalName,X500
Import-Csv .\x500.csv | ForEach-Object {
Set-Mailbox $_.UserPrincipalName -EmailAddresses @{add=$_.X500}
}Récapitulatif en une page
- Symptôme : expéditeur reçoit « mailbox unavailable (S2017062302) », le destinataire a bien le message.
- Causes probables : alias X.500 manquant, cache expéditeur obsolète, règles/transfert, cache EOP, incohérence DNS d’authentification.
- Remèdes : supprimer règles, sécuriser le compte, ajouter alias et X.500, purger AutoComplete, vérifier SPF/DKIM/DMARC, message trace.
- Délai d’arrêt des NDR : 24–48 h après correction.