Depuis mars 2024, des messages envoyés depuis des adresses @outlook.hu – et, plus marginalement, @outlook.fr, @outlook.sk, @outlook.cz, @outlook.in – sont rejetés par Gmail/Google Workspace ou classés en spam. Voici une analyse détaillée et des actions concrètes.
Problème posé
De nombreux expéditeurs utilisant les alias régionaux d’Outlook.com signalent des retours à l’expéditeur (bounce) en provenance des serveurs mx.google.com, ou des atterrissages systématiques dans le dossier Spam chez leurs correspondants Gmail et Google Workspace. Les rapports de non‑distribution (NDR) évoquent une détection de spam et/ou une réputation dégradée. Le dysfonctionnement ne touche pas les anciens alias historiques (@msn.com) ni les alias globaux (@outlook.com) de manière équivalente, ce qui indique un problème circonscrit aux domaines régionaux.
Analyse et diagnostic au fil des signalements
La chronologie ci‑dessous synthétise les retours d’expérience et échanges utilisateurs/soutiens éditeurs.
| Période | Constat principal | Commentaires notables |
|---|---|---|
| 13 → 22 mars 2024 | Premiers signalements. Microsoft confirme un blocage côté Google et ouvre une enquête. | Les comptes basés sur le domaine d’origine @msn.com fonctionnent, signe que le problème est attaché aux alias régionaux récents. |
| 21 → 28 mars 2024 | Élargissement du phénomène aux domaines .fr, .sk, .cz, .in. | Microsoft oriente vers le support in‑app d’Outlook.com et recommande l’usage d’un alias @outlook.com comme contournement. |
| Début avril 2024 | Aucun correctif côté éditeur. Google évoque une réputation dégradée pour outlook.hu. | Google suggère d’ajouter l’expéditeur en liste verte, de limiter les éléments typiques de spam, etc., tout en reconnaissant que la cause première est côté Microsoft. |
| 24 avril 2024 | Amélioration partielle : livraison possible, mais souvent en Spam. | Indice d’une remontée progressive de réputation IP/DKIM, sans rétablissement complet. |
| mai → juin 2024 | Situation instable : la majorité des courriels arrivent encore en Spam ; certains domaines (ex. outlook.sk) restent bloqués par périodes. | Microsoft renvoie vers la page des « correctifs ou solutions de contournement » sans date ferme de résolution. |
Ce que révèle le problème côté infrastructure
Les alias @outlook.<ccTLD> (ex. @outlook.hu) n’utilisent pas nécessairement les mêmes briques d’envoi que @outlook.com. Sans entrer dans les détails internes propriétaires, trois éléments opérationnels expliquent la symptomatologie :
- Pools d’adresses IP et signatures distincts : un sous‑ensemble d’adresses IP, de clés DKIM et/ou de chemins de retour (Return‑Path) peut être spécifique à un ccTLD. Si un pool est pénalisé, la réputation négative peut frapper le ccTLD sans toucher le domaine global.
- Segmentation de réputation : les grands récepteurs (dont Gmail) notent séparément par combinaison « IP d’envoi × domaine utilisé × historique d’engagement ». Une dérive localisée (spam, phish, usurpation) peut suffire à enclencher du filtrage agressif.
- Propagation lente des réhabilitations : même après correctifs côté émetteur, les scores de réputation remontent graduellement. D’où des périodes d’amélioration partielle (messages livrés mais marqués Spam) avant retour à la normale.
Reproduire et documenter l’incident
Pour accélérer toute résolution, il est crucial de produire des éléments probants de diagnostic. Voici une procédure pas à pas à remettre au support Outlook.com et, si besoin, à l’administrateur Google du destinataire.
- Tester depuis l’alias concerné : envoyez un message court et neutre depuis @outlook.hu (ou autre ccTLD affecté) vers une boîte Gmail de test. Évitez liens, pièces jointes et formatage riche.
- Capturer le NDR ou l’atterrissage : si le message rebondit, conservez le rapport mx.google.com. S’il est livré en Spam, ouvrez l’original et exportez les en‑têtes complets.
- Relever les en‑têtes clés : Authentication‑Results, Received‑SPF, DKIM‑Signature, Return‑Path, Message‑ID, X‑Google‑Spam (le cas échéant). Notez le serveur d’envoi (Received), l’IP et l’heure exacte.
- Comparer avec un alias sain : répétez le test avec le même contenu depuis @outlook.com ou @msn.com. Si la livraison réussit en boîte de réception, ajoutez les deux jeux d’en‑têtes au ticket.
- Étiqueter clairement le sujet : « Delivery to Gmail fails from @outlook.hu, spam classification or bounce » puis joignez les pièces pour une corrélation rapide côté support.
Exemple de NDR typique
Final-Recipient: rfc822; destinataire@gmail.com Action: failed Status: 5.7.26 Diagnostic-Code: smtp; 550-5.7.26 This message does not pass authentication checks (SPF or DKIM) and may be considered spam. mx.google.com Remote-MTA: dns; gmail-smtp-in.l.google.com Received-From-MTA: dns; *.outlook.hu
Remarque : le code exact peut varier. L’important est d’isoler l’IP d’envoi, la trace d’authentification, et l’horodatage.
Solutions et contournements immédiats
- Utiliser l’adresse d’origine ou un alias global
- Envoyer depuis @msn.com lorsque disponible.
- Créer ou sélectionner un alias @outlook.com et l’utiliser comme adresse d’expéditeur (From).
- Ouvrir un ticket via l’assistance intégrée Outlook.com
- Dans Outlook.com : ? Aide ▸ Contacter le support.
- Fournir NDR, en‑têtes complets, IP d’envoi, exemples horodatés, captures de la classification Spam.
- Informer les destinataires Gmail
- Demander l’ajout de l’expéditeur au carnet d’adresses / liste verte pour réduire le classement automatique en Spam.
- Suivre les bonnes pratiques anti‑spam
- Éviter les MAJUSCULES, répétitions de ponctuation, URL raccourcies, pièces jointes lourdes ou suspectes.
- Ne pas relayer via un proxy SMTP tiers qui casserait SPF/DKIM/DMARC.
- Pour les envois critiques (jusqu’à résolution) :
- Recourir à un relais SMTP professionnel (ex. plateforme d’emailing transactionnel) configuré pour une réputation et une authentification stables.
- Surveiller les listes de blocage publiques pour détecter l’éventuelle levée d’un blocage IP ou domaine.
Bonnes pratiques anti‑spam à appliquer immédiatement
- Contenu : privilégier un texte clair, éviter les accroches « trop marketing », insérer une version texte brute (multipart/alternative), bannir les URL obfusquées.
- Pièces jointes : préférer des formats bureautiques courants plutôt que des exécutables compressés. Nommer proprement les fichiers.
- Maquette : opter pour une mise en page simple, un ratio texte‑image équilibré, des liens sortants limités et utiles.
- Réputation : envoyer régulièrement mais modérément, nettoyer les listes de contacts, supprimer les adresses en rebond dur (hard bounce).
- Authentification : vérifier que les en‑têtes indiquent SPF=pass, DKIM=pass, DMARC=pass pour l’alias utilisé, et qu’aucun intermédiaire ne réécrit les signatures.
Procédures côté expéditeur Outlook.com
Pour maximiser l’efficacité du support, structurez vos retours ainsi :
- Résumé d’impact : « Tous les envois vers Gmail/Google Workspace depuis @outlook.hu échouent ou vont en Spam depuis le JJ/MM/AAAA ».
- Exemples : 2 à 5 exemples récents (moins de 48 h) avec NDR complets et/ou en‑têtes complets.
- Comparatif : un envoi identique depuis @outlook.com ou @msn.com qui arrive en boîte de réception.
- Contexte : volume moyen d’envoi, fréquence, absence de campagnes massives, nature des destinataires (contacts connus).
Actions côté destinataire Gmail et Google Workspace
Si le destinataire a la main sur ses paramètres (compte personnel) ou si un administrateur gère un domaine Google Workspace, proposez les actions suivantes :
- Utilisateur Gmail : ajouter l’expéditeur @outlook.hu aux contacts, déplacer les messages du Spam vers la Boîte de réception en marquant « Ceci n’est pas un spam » pour entraîner le filtre.
- Administrateur Workspace : créer une règle de conformité ciblée pour autoriser temporairement un expéditeur précis lorsque c’est justifié (communication attendue). Appliquer une durée et une portée minimales.
Important : ces actions ne réparent pas la cause racine. Elles visent uniquement à assurer la continuité de service le temps que l’éditeur corrige la réputation du domaine.
Indicateurs réseau à suivre
| Indicateur | Objectif | Interprétation |
|---|---|---|
| Taux de rebond (hard) vers Gmail | < 1 % | Si > 1 %, suspicion de blocage/réputation. Archiver les NDR et remonter au support. |
| Part des messages en Spam chez Gmail | < 5 % | Une baisse continue signale une remontée de réputation. Une hausse brutale suggère une régression. |
| Authentication‑Results | spf=pass, dkim=pass, dmarc=pass | Tout échec coté Gmail renforce le risque de classement Spam. |
| Latence de remise | < 60 s | Des retards prolongés peuvent indiquer une mise en quarantaine/filtrage accru. |
État constaté au 24 juin 2024
- Blocage partiel persistant : certains messages sont rejetés, d’autres sont livrés mais classés en Spam.
- Enquête Microsoft toujours en cours, sans date de résolution ferme communiquée.
- Aucun changement de configuration côté utilisateur ne corrige définitivement le problème ; seuls les contournements ci‑dessus garantissent une délivrabilité fiable à court terme.
Pourquoi les domaines régionaux sont touchés
| Point | Détail pratique |
|---|---|
| Spécificité des @outlook.<ccTLD> | Les alias régionaux s’appuient possiblement sur des pools IP, des clés DKIM et des chemins de retour distincts. Une pénalisation ciblée peut n’affecter qu’un ccTLD. |
| Action la plus utile côté utilisateur | Multiplier les tickets via l’assistance Outlook.com pour fournir données et horodatages. Le volume et la qualité des preuves accélèrent la ré‑authentification et la négociation entre éditeurs. |
| SPF/DKIM à modifier soi‑même ? | Non pour les alias Outlook.com : Microsoft gère ces enregistrements. Exception : domaines personnalisés sous votre contrôle. |
| Indicateur d’un rétablissement complet | Les messages @outlook.hu arrivent en boîte de réception Gmail sans bannière « Pourquoi ce message est‑il dans Spam ? » et le taux de rebond redevient < 1 %. |
Plan d’action recommandé
- À très court terme : basculer l’expédition critique sur un alias @outlook.com ou un compte secondaire (Gmail, domaine pro) et prévenir les destinataires par un canal alternatif (SMS, Teams, messagerie instantanée).
- À court terme : ouvrir un ticket Outlook.com avec preuves et comparatifs, puis effectuer un envoi de vérification quotidien pour suivre la tendance.
- À moyen terme : si les échanges avec Gmail sont stratégiques, prévoir un relais SMTP professionnel, avec authentifications solides et gestion de réputation, jusqu’à confirmation de retour à la normale.
- À la clôture : supprimer les contournements, vérifier que les taux de rebond/Spam sont revenus aux seuils cibles, et documenter l’incident pour de futures postures préventives.
Modèles prêts à l’emploi
Message à envoyer à un contact Gmail
Bonjour,
Nous rencontrons actuellement un problème de délivrabilité depuis notre adresse @outlook.hu vers Gmail/Google Workspace (rejets ou classement automatique en spam).
Pouvez‑vous : (1) ajouter notre adresse à vos contacts ; (2) vérifier votre dossier Spam ; (3) répondre à ce message si vous le recevez bien en boîte de réception ?
Merci de votre aide.
Checklist pour un ticket au support Outlook.com
- Objet : Delivery to Gmail fails from @outlook.hu
- Résumé d’impact + début des symptômes
- 3 à 5 NDR complets (moins de 48 h)
- En‑têtes complets d’au moins un message livré en Spam
- Comparatif depuis @outlook.com ou @msn.com (réussi)
- Heures exactes, fuseau horaire, IP d’envoi observées
Questions fréquentes
Mes messages sont‑ils perdus ?
Non. En cas de rebond, vous recevez un NDR. En cas de Spam, le destinataire peut les récupérer.
Dois‑je changer de fournisseur d’email ?
Pas nécessairement. Utilisez les contournements recommandés pendant l’incident. Conservez un canal secondaire pour le critique.
Un texte « propre » suffit‑il à éviter le Spam ?
Le contenu influence, mais la réputation du domaine/IP et l’authentification pèsent davantage. Restez sobre et authentifié, tout en suivant les consignes ci‑dessus.
Combien de temps pour un retour à la normale ?
Les remontées de réputation sont progressives. D’où l’intérêt d’un suivi des indicateurs (rebond, Spam, latence) et d’un point régulier via le ticket ouvert.
Conclusion
Le blocage et/ou sur‑filtrage observé depuis @outlook.hu (et certains @outlook.<ccTLD>) vers Gmail/Google Workspace relève d’une réputation et d’une authentification gérées côté émetteur. Les utilisateurs ne peuvent pas corriger la cause racine par configuration locale. En revanche, ils peuvent assurer la continuité en basculant temporairement sur un alias global, accélérer la résolution en fournissant des preuves structurées via l’assistance intégrée, et sécuriser les échanges grâce à des bonnes pratiques anti‑spam et à un canal secondaire de notification.
Lorsque l’incident sera entièrement résorbé, les indicateurs redeviendront stables : SPF/DKIM/DMARC=pass, atterrissage direct en boîte de réception sans bannière d’alerte, et taux de rebond < 1 %. En attendant, privilégiez l’alias @outlook.com pour toutes les correspondances sensibles, et maintenez une surveillance périodique de vos métriques de délivrabilité.