Outlook et Microsoft 365 mettent tout en indésirables

Indésirables n'est pas un rejet SMTP

Le message est accepté, puis classé. Votre file d'envoi est verte, le client ne vous répond pas. Ce n'est pas le même dossier qu'un 550 Gmail. Confondre les deux pousse à « changer d'IP » alors qu'il faut une réputation et un contenu stables.

Demandez une capture du ruban Outlook (indésirables vs quarantaine 365) et les en-têtes. Un administrateur Microsoft 365 peut avoir une règle transport qui n'a rien à voir avec votre piratage. On élimine ça avant de crier au blacklistage mondial.

Le cadre reste le même que pour le domaine en spam : source coupée, authentification, puis patience. Microsoft est simplement plus lent à défaire ce qu'un pic de spam a construit.

SNDS et listes Microsoft

Smart Network Data Services montre, pour une IP que vous contrôlez, des plaintes et un statut. Sur un mutualisé, vous ne contrôlez souvent pas l'IP. Le levier est alors le domaine, le volume, et le ticket hébergeur — pas un tableau SNDS vide.

Les listes internes Microsoft ne se « consultent » pas comme Spamhaus. On infère : DSN, en-têtes, délais après coupure. Joindre un constat (date de fin d'envoi frauduleux, correctif) dans un recours officiel évite le copier-coller « we are not spammers ».

Si l'IP du mutualisé est brûlée par un voisin, le nettoyage de votre seul WordPress ne suffit pas. C'est un sujet d'isolation et de réputation d'IP, parfois de migration après site propre — jamais avant.

• IP dédiée : SNDS + journaux d'envoi.
• Mutualisé : domaine, file, ticket hébergeur.
• 365 côté destinataire : éliminer une règle locale.

Ce que voient Outlook.com et Microsoft 365

Outlook.com (grand public) et un tenant 365 d'entreprise n'ont pas les mêmes seuils ni les mêmes admin. Un client en 365 peut déplacer votre domaine hors indésirables pour son organisation : ça ne lave pas Outlook.com, ni le voisin de bureau qui a un autre tenant.

Les campagnes marketing et le transactionnel sont jugés ensemble si le From et l'IP sont les mêmes. Séparer les flux (ESP pour la newsletter, hébergeur pour la commande) se décide à froid, après l'incident, pas en créant `news.` dans la précipitation.

Si le mail contient un lien vers une page encore classée trompeuse, Microsoft aggrave. Site propre, alerte navigateur levée n'est pas le sujet ici, mais le même ordre s'applique : pas de lien sale dans le devis.

Recours : après la coupure, pas avant

Les formulaires Microsoft (déliste, SNDS mitigation, support 365 si vous êtes client) demandent une date et une cause. « On a changé le mot de passe » sans journal d'envoi à zéro se fait éconduire. Attendez que la pompe soit arrêtée : script, cron, clé SMTP, webmail.

Un recours trop tôt, pendant que le volume pirate continue, ancre l'idée que vous n'avez pas le contrôle. Le suivant est plus long. Même logique que le réexamen Safe Browsing trop tôt.

Ne multipliez pas les tickets identiques depuis trois adresses. Un dossier, des pièces, une relance espacée.

Le piège du nouveau sous-domaine

Créer `secure-mail.votre-domaine.fr` ou `pro.` pour « passer Outlook » le temps que ça se calme est un réflexe fréquent. Microsoft relie souvent au domaine parent. Vous entraînez le racine dans une nouvelle identité mal réchauffée, et vous cassez SPF/DKIM si la zone est bricolée à la hâte.

Un domaine entièrement neuf a le même problème plus le SEO et les carnets d'adresses clients. On le réserve aux cas où le racine est irrécupérable à moyen terme — rare — et on le réchauffe comme un domaine après spam, pas comme un interrupteur.

Si un sous-domaine existait déjà (boutique, factures), vérifiez qu'il n'a pas été utilisé par le script. Les rapports DMARC montrent qui envoie encore avec quel hostname.

• Pas de sous-domaine de contournement le jour J.
• Pas de From qui change tous les matins.
• Un plan d'envoi unique, volume bas, vrais fils.

En-têtes et SCL

Les en-têtes Microsoft peuvent inclure un SCL (spam confidence). Un chiffre haut avec authentification verte oriente vers le contenu, le volume récent ou une URL. Un échec d'alignement oriente vers le DNS. Copiez le bloc : c'est plus utile qu'une capture du dossier Indésirables.

Demandez au destinataire 365 de ne pas « autoriser l'expéditeur » comme seule mesure : ça le débloque lui, pas le marché. Ça peut toutefois débloquer un contrat urgent pendant que vous traitez la réputation.

Si plusieurs destinataires 365 ont le même SCL élevé la même heure, c'est vous. S'il n'y en a qu'un, cherchez une règle ou une adresse déjà signalée chez lui.

Aligner le DNS sans bricolage

SPF trop large (`+all`) invite à l'usurpation et n'aide pas Outlook. Un SPF qui oublie l'ESP légitime produit des fails et des indésirables. Inventaire des relais, puis durcissement, pas l'inverse.

DKIM cassé pendant l'incident (sélecteur réécrit, clé absente) se voit dans les en-têtes. Remettez la config du prestataire, testez un message, puis seulement augmentez le volume.

Un MX encore douteux (zone détournée) rend tout le reste anecdotique. Vérifiez la zone avant de parler réputation.

Suivi sur deux semaines

Microsoft défait plus lentement qu'il ne construit. Comptez des jours ouvrés après une coupure réelle, parfois plus. Tenez un tableau : date, type de message (devis / reset / newsletter), résultat. C'est le seul moyen de voir une pente, pas une angoisse quotidienne.

Pas de campagne « on est de retour » tant que le transactionnel n'est pas stable. Le réchauffement est un ordre, pas un sentiment.

Si vous déléguez le site, joignez les DSN Microsoft au dossier. Créer un espace ne demande pas les accès tout de suite ; les en-têtes, si.