Canaux d’escalade de Microsoft

Microsoft exploite deux univers de filtrage distincts, avec des voies de correction distinctes. Escalader auprès du mauvais fait perdre des jours. Commencez par classer le blocage :

Signification complète des codes : Exigences de Microsoft envers les expéditeurs ; diagnostic par les en-têtes pour les messages vers des clients Microsoft 365 : Le fonctionnement interne du filtrage de Microsoft.

Canal 1 : Office 365 Anti-Spam IP Delist Portal (sender.office.com)

Pour les IP figurant sur la liste des expéditeurs bloqués d’EOP (plage de NDR 5.7.606–649, qui renvoie elle-même vers le portail). En libre-service, IP par IP.

Procédure :

1. Rendez-vous sur https://sender.office.com.
2. Saisissez l’adresse email qui a reçu le NDR et l’adresse IP indiquée dans le message d’erreur (une adresse email et une IP par visite), puis passez le CAPTCHA.
3. Microsoft envoie un email de vérification à cette adresse ; cliquez sur le lien de confirmation pour revenir au portail.
4. Sélectionnez Delist IP.

Ce qu’il faut : le texte exact du NDR (IP + code) et une boîte fonctionnelle à l’adresse saisie. Délai : Microsoft indique que les résultats varient et que le retrait complet peut prendre jusqu’à 24 heures, voire plus. Réserves : le retrait ne lève que le blocage en bordure ; les messages doivent encore passer le filtrage EOP/MDO, y compris l’authentification composite ; si le trafic reste abusif, l’IP est de nouveau bloquée. Corrigez la cause profonde (compromission, qualité de la liste, authentification) avant de demander le retrait, comme pour tout retrait d’une liste de blocage.

Canal 2 : delist@microsoft.com (erreur 5.7.511)

550 5.7.511 Access denied, banned sender signifie que l’IP figure sur une liste qui exige une enquête supplémentaire de Microsoft : le portail en libre-service ne peut explicitement pas régler le problème. Transférez le rebond à delist@microsoft.com en incluant le texte intégral du NDR et l’adresse IP. Microsoft indique répondre sous 48 heures avec la marche à suivre. Attendez-vous à des questions sur le trafic ; ayez sous la main des preuves sur le volume, le consentement et les corrections.

Canal 3 : formulaire d’assistance aux expéditeurs d’Outlook.com (boîtes grand public)

Pour les problèmes de délivrabilité vers Outlook.com grand public uniquement : « any address @msn.com, @Outlook.com, @hotmail.com, or @live.com ». C’est le canal pour le classement en courrier indésirable, les blocages pour plaintes SC-004 après correction, les limitations de débit (RP-00x) qui ne se résorbent pas et les demandes de levée des restrictions pendant la chauffe.

Conditions préalables que Microsoft attend avant toute demande (les demandes qui ne les remplissent pas reçoivent généralement des refus types) :

1. Vérifier la conformité avec la page des politiques d’Outlook.com (authentification, PTR, limites de connexions ; voir Exigences de Microsoft envers les expéditeurs).
2. Inscrire ou mettre à jour les IP dans SNDS et JMRP : les nouvelles IP doivent être ajoutées à votre compte JMRP. Voir Microsoft SNDS et JMRP. Les données SNDS (couleur du filtre, taux de plaintes, proportion d’échecs RCPT) sont aussi les preuves que vous citerez dans le ticket.
3. Consulter d’abord la FAQ de dépannage pour votre code d’erreur exact.

Où se trouve le formulaire : l’article d’assistance de Microsoft « Sender Support in Outlook.com » (https://support.microsoft.com/en-us/outlook/sender-support-in-outlook-com) et la page de dépannage postmaster renvoient vers le formulaire (historiquement https://sendersupport.olc.protection.outlook.com/pm/Troubleshooting, également accessible via le redirecteur https://go.microsoft.com/fwlink/?LinkID=614866). Notez que les pages postmaster et SNDS ont migré vers https://substrate.office.com/ip-domain-management-snds/, l’ancien domaine sendersupport.olc.protection.outlook.com étant obsolète depuis le 22 juin 2026 : attendez-vous à ce que le lien du formulaire mène à son emplacement actuel via le fwlink ; suivez la page Troubleshooting postmaster (https://substrate.office.com/ip-domain-management-snds/Postmaster/Troubleshooting) pour le lien en vigueur.

Ce qu’il faut inclure : la ou les IP d’envoi concernées, le texte ou code exact de l’erreur SMTP, le ou les domaines d’envoi, une description du flux de messages (volume, méthode d’opt-in) et les corrections déjà effectuées (suppression des plaignants JMRP, nettoyage de la liste, corrections de l’authentification).

Déroulement et délais réalistes (largement rapportés par les praticiens ; pas un engagement officiel de niveau de service) : le formulaire produit une réponse automatique, qui indique souvent « no problem detected » ou une levée des restrictions générique sous conditions. Répondez à cet email automatique pour faire remonter la demande à un agent humain (les réponses arrivent depuis des adresses olcsupport.office.com) ; une réponse humaine prend généralement d’un à plusieurs jours ouvrés. Lorsqu’elle est accordée, la levée des restrictions est généralement temporaire ou conditionnelle : la réputation doit être reconstruite par le comportement d’envoi, d’abord à faible volume. Les nouvelles IP ont besoin d’environ 2 semaines ou plus de construction de la réputation chez Outlook.com ; SPF sur un domaine qui a déjà une bonne réputation accélère la montée en charge.

Il existe aussi un formulaire distinct de retrait de liste pour Outlook.com grand public à l’adresse https://support.microsoft.com/supportrequestform/8ad563e3-288e-2a61-8122-3ba03d6b8d75 (cité dans l’article sur le retrait EOP pour les blocages côté grand public) ; lisez la FAQ de dépannage avant de le soumettre.

Canal 4 : problèmes propres au client destinataire (aucun canal Microsoft)

Lorsque les en-têtes montrent SFV:SKB/SFV:BLK (listes de blocage du destinataire), un blocage de la Tenant Allow/Block List (5.7.703) ou une mise en quarantaine pour phishing à haut niveau de confiance provoquée par une entrée d’URL ou de domaine bloqué chez un client, il n’existe aucun canal Microsoft destiné aux expéditeurs. L’administrateur de l’organisation destinataire doit retirer l’entrée ou soumettre le message à Microsoft comme faux positif via la page Submissions de Defender (https://security.microsoft.com/reportsubmission), qui est aussi la seule voie pour obtenir une autorisation face à un verdict de logiciel malveillant ou de phishing à haut niveau de confiance. Fournissez à l’administrateur du destinataire les en-têtes complets et le guide de terrain Le fonctionnement interne du filtrage de Microsoft.

Liste de contrôle de l’escalade (procédure de consultant)

1. Classez le blocage à partir du code SMTP exact ou du verdict de l’en-tête (tableau en haut de page).
2. Corrigez d’abord la cause profonde : alignement de l’authentification, hôtes compromis, sources de plaintes, hygiène de base de données. Microsoft bloque de nouveau les expéditeurs qui ne se sont corrigés qu’en apparence.
3. Inscrivez-vous à SNDS et JMRP avant tout contact côté grand public ; récupérez la vue SNDS des jours de l’incident.
4. Utilisez le canal le plus ciblé : le portail pour les 606–649 ; delist@microsoft.com pour le 5.7.511 ; le formulaire d’assistance aux expéditeurs pour les problèmes d’Outlook.com grand public ; l’administrateur du destinataire pour les blocages locaux à un client.
5. Gardez une trace écrite : identifiants de tickets et réponses automatiques ; ce sont les réponses à l’email automatique qui atteignent des humains.
6. Vérifiez après la levée des restrictions : surveillez les résultats du filtre dans SNDS et testez des boîtes grand public avec une liste de test ; augmentez le volume progressivement, comme après une chauffe.

Voir aussi

• Exigences de Microsoft envers les expéditeurs : catalogue des codes d’erreur et politiques
• Le fonctionnement interne du filtrage de Microsoft : lire les en-têtes de verdict
• Microsoft SNDS et JMRP : les conditions préalables obligatoires
• Listes de blocage DNS et zones Spamhaus : les blocages OU-001 sont liés à Spamhaus