Les exigences expéditeurs de Microsoft (Outlook, Hotmail) en 2025

IP partagées ou dédiées : quelle réputation appartient vraiment à l'expéditeur ?

Pour un envoi via une plateforme de routage plutôt que des serveurs en propre, Microsoft tient deux registres distincts : la réputation de l'IP d'envoi et celle du domaine. Sur un pool d'IP partagées, la première est collective — le comportement des autres clients de la plateforme déteint, en bien ou en mal, et la visibilité SNDS sur ces IP revient généralement à la plateforme, pas à son client. La réputation de domaine, en revanche, n'appartient qu'à l'expéditeur : elle se nourrit de ses résultats d'authentification et de la réaction des destinataires au courrier qui porte son nom. C'est précisément pour ça qu'un DKIM aligné compte autant dans cette configuration — c'est le levier qui reste entièrement sous contrôle quand la couche IP échappe.

Le filtrage Microsoft : Junk Email Reporting et SCL

Microsoft utilise son propre système de score, le SCL (Spam Confidence Level), qui détermine où un message atterrit : boîte de réception, dossier indésirable, ou blocage pur. Ce score s'appuie sur l'authentification (SPF/DKIM/DMARC), la réputation IP/domaine (visible en partie via SNDS), et l'analyse de contenu — une logique proche de celle de Gmail, mais avec ses propres pondérations internes, non publiées en détail.

Un signal spécifique à surveiller : le Junk Email Reporting Program (JMRP), le programme par lequel les utilisateurs Outlook signalent un message comme indésirable. Comme chez Gmail, un taux de plainte élevé dégrade rapidement la réputation — mais l'inscription à JMRP (distincte de SNDS) donne accès à une copie directe des signalements visant ses propres emails, un signal d'alerte précoce que peu d'expéditeurs exploitent.

Alignement DMARC : les mêmes règles, un comportement parfois plus strict

DMARC fonctionne selon le même standard chez Microsoft que partout ailleurs — l'alignement SPF/DKIM avec le From: n'a rien de spécifique à cet écosystème. Ce qui diffère, en pratique, c'est que certains administrateurs rapportent un traitement légèrement plus strict des échecs d'alignement chez Outlook comparé à Gmail, notamment sur les cas limites. La leçon pratique : une configuration DMARC « qui passe chez Gmail » n'est pas automatiquement suffisante chez Microsoft — l'alignement de chaque source se vérifie spécifiquement dans les rapports agrégés DMARC, avec un œil sur les destinataires outlook.com/hotmail.com en particulier.

Microsoft 365 côté entreprise : une autre couche

Quand une partie des destinataires utilise Microsoft 365 en environnement professionnel plutôt que les domaines grand public, un étage s'ajoute : les administrateurs d'entreprise disposent de couches de filtrage supplémentaires (Exchange Online Protection, règles de transport personnalisées, listes de blocage internes) qui viennent après le filtrage Microsoft standard. Une authentification impeccable ne garantit pas de passer une règle de blocage interne agressive posée par l'administrateur d'un destinataire — un facteur hors de tout contrôle côté expéditeur, mais utile à connaître pour ne pas chercher un bug côté DMARC là où il n'y en a pas.

Checklist de conformité Microsoft

• SPF et DKIM alignés, vérifiés spécifiquement sur du trafic vers outlook.com/hotmail.com dans les rapports.
• DMARC publié, avec un objectif de montée vers quarantine puis reject selon la même méthode que pour tout autre destinataire — voir atteindre p=reject sans casser ses emails.
• Inscription à SNDS pour la visibilité de réputation IP, quand les IP d'envoi sont maîtrisées.
• Inscription au programme JMRP pour recevoir directement les signalements spam visant ses propres envois.
• Hygiène de liste identique à celle recommandée pour Gmail — Microsoft observe les mêmes signaux comportementaux (plaintes, rebonds, engagement).
• Un-subscribe fonctionnel et visible, réduisant le recours au bouton « signaler comme indésirable ».

Le calendrier de durcissement, côté Microsoft

Un point à connaître au moment de bâtir une feuille de route : le rythme d'application de Microsoft n'a pas toujours suivi celui de Gmail et Yahoo. Là où Google a communiqué un calendrier précis et daté dès l'annonce initiale de 2024, Microsoft a longtemps procédé par ajustements progressifs de son filtrage sans annonce publique aussi structurée. La conséquence pratique : « la date limite de Google est passée, donc tout est réglé partout » est un raisonnement à bannir. Le filtrage Microsoft continue d'évoluer indépendamment, et un domaine qui passait sans souci il y a six mois peut voir sa délivrabilité Outlook se dégrader sans qu'aucun changement côté expéditeur n'en soit la cause — simplement parce que le seuil de tolérance côté Microsoft a bougé.

C'est un argument de plus pour traiter la surveillance de la réputation (via SNDS) comme un exercice continu, et non comme une case à cocher une fois lors de la mise en conformité initiale.

Cas pratique : un expéditeur B2B français

Prenons un exemple concret pour ancrer ces notions. Une PME française qui envoie ses factures et relances par email touche un mélange de destinataires professionnels — souvent sur des domaines Microsoft 365 d'entreprise — et de particuliers, plus répartis entre Gmail, Outlook.com/Hotmail et les fournisseurs français (Orange, Free, SFR). Pour cette PME, ignorer la couche Microsoft n'est pas une option marginale : c'est potentiellement la moitié de son trafic professionnel qui transite par cet écosystème.

Le réflexe correct est de traiter la configuration DMARC comme universelle (un seul enregistrement, valable pour tous les destinataires) mais la surveillance de réputation comme spécifique à chaque écosystème : Postmaster Tools pour la part Gmail, SNDS pour la part Microsoft, et une vigilance sur les rapports agrégés DMARC pour repérer si un destinataire particulier montre un taux d'échec anormalement élevé par rapport aux autres. Cette vigilance différenciée coûte peu de temps une fois mise en place, et elle évite l'angle mort le plus courant chez les expéditeurs français : une délivrabilité Gmail excellente qui masque une délivrabilité Outlook médiocre, simplement parce que personne ne regardait de ce côté.

Pourquoi ne pas se contenter de la conformité Gmail

L'erreur de raisonnement la plus fréquente : « conforme pour Gmail, donc conforme partout ». Techniquement, l'authentification (SPF/DKIM/DMARC) est effectivement la même configuration DNS pour tous les destinataires — pas de duplication à faire côté enregistrements. Mais la réputation est spécifique à chaque écosystème : la réputation d'un domaine chez Google et sa réputation chez Microsoft sont deux historiques indépendants, construits sur des signaux observés séparément par chacun. Une excellente délivrabilité chez Gmail ne garantit rien chez Outlook, et inversement — les deux filtres tirent leurs conclusions de leurs propres utilisateurs, pas d'un référentiel partagé entre fournisseurs. D'où l'intérêt de surveiller les deux (via Postmaster Tools et SNDS) plutôt que de supposer qu'un bon score chez l'un vaut pour l'autre.

En résumé

Les fondations DMARC/SPF/DKIM sont universelles et ne se configurent qu'une fois. Ce qui change chez Microsoft, ce sont les outils de visibilité (SNDS, JMRP) et le fait que la réputation s'y construit indépendamment de celle acquise chez Gmail. Un déploiement DMARC sérieux couvre les deux écosystèmes dès le départ, sans attendre un incident de délivrabilité spécifique à l'un d'eux pour s'en préoccuper.

Pour contrôler une authentification correctement configurée — le préalable identique quel que soit le destinataire — un passage du domaine dans l'analyseur DMARC gratuit suffit. C'est le point de départ commun aux deux écosystèmes ; la surveillance de réputation, elle, se joue ensuite séparément chez chacun.