Aller au contenu
Retour à la bibliothèqueDélivrabilité

Quel est l’équivalent Microsoft de Google Postmaster Tools ?

Johanie DupontPar Johanie Dupont3 novembre 2026Lu en 7 min

L’essentiel

Les alternatives Microsoft les plus proches de Google Postmaster sont SNDS et JMRP. Comparez leurs données Outlook.com et voyez où s’arrête leur couverture.

Quel est l’équivalent Microsoft de Google Postmaster Tools ?

Microsoft n’offre pas d’équivalent point par point à Google Postmaster Tools. Pour les e-mails vers les adresses grand public Outlook.com, les services Microsoft les plus proches sont Smart Network Data Services (SNDS), qui fournit des données d’envoi et de filtrage par IP, et le Junk Mail Reporting Program (JMRP), qui remonte les plaintes. Ils n’exposent pas de tableau de réputation universel pour chaque domaine destinataire Microsoft 365.

En bref

Points clés

  • SNDS et JMRP sont l’équivalent Microsoft le plus proche de Google Postmaster Tools pour Outlook.com grand public.
  • SNDS s’organise autour d’adresses IP d’envoi autorisées, de plages ou de numéros de système autonome.
  • JMRP signale les e-mails marqués indésirables par des usagers Outlook.com.
  • Les données SNDS ne révèlent pas les décisions privées de filtrage ou de boîte d’un tenant Microsoft 365.
  • Un rapport SNDS absent peut signifier que l’IP n’a pas atteint le seuil de Microsoft. Ce n’est pas un bon résultat.
  • Le suivi des messages Microsoft 365 relève de l’admin du tenant, pas d’un service public de réputation.

Les services postmaster de Microsoft

Microsoft Smart Network Data Services aide les expéditeurs autorisés à comprendre le trafic et les signaux de réputation liés à leurs IP d’envoi chez Outlook.com. Le même site donne accès aux réglages de boucle de rétroaction JMRP.

SNDS se rapproche le plus du rôle opérationnel de Google Postmaster Tools, mais les périmètres diffèrent. Google Postmaster Tools présente des données Gmail pour les domaines et IP vérifiés quand il y a assez de données. Microsoft SNDS se centre sur l’IP d’envoi autorisée et l’infrastructure grand public Outlook.com.

Selon la FAQ SNDS de Microsoft, l’autorisation peut partir de la responsabilité d’une adresse IP, d’une plage IP ou d’un numéro de système autonome. Microsoft utilise le DNS inverse, RDAP et le routage pour identifier les contacts d’autorisation valables.

Une fois l’accès approuvé, SNDS peut montrer l’activité quotidienne et le filtrage du trafic éligible. Microsoft documente des champs comme les nombres de commandes SMTP RCPT et DATA, le nombre de destinataires, les résultats de filtrage agrégés, les plaintes, les malwares ou virus observés, le statut de proxy ouvert et le statut actuel de l’IP.

Page d’accueil de Microsoft SNDS avec les liens données, statut IP, demande d’accès et JMRP
Source : Microsoft Smart Network Data Services, consulté le 2026-07-29.

JMRP a un rôle plus étroit. Il prévient les expéditeurs participants quand des utilisateurs Outlook.com signalent leurs messages comme indésirables. Une plainte invite à examiner la campagne, la preuve de consentement, l’IP d’envoi et le domaine authentifié. Elle doit aussi déclencher une exclusion du flux concerné si l’expéditeur peut identifier le destinataire sans risque.

Quand la réponse change

La réponse dépend de l’infrastructure du destinataire et des preuves disponibles.

Pour les destinataires outlook.com, hotmail.com, live.com et msn.com, SNDS et JMRP sont les bons services Microsoft. Ils fournissent la télémétrie de la messagerie grand public Microsoft, sous réserve d’autorisation et de données disponibles.

Pour un destinataire professionnel unique sur Microsoft 365, SNDS n’est pas l’équivalent. Cette organisation contrôle ses politiques Exchange Online, ses décisions d’autorisation ou de blocage, sa quarantaine et son suivi des messages. Un expéditeur externe a besoin des preuves de l’administrateur du destinataire, comme un suivi de message ou la réponse SMTP exacte.

Pour une audience mixte, séparez les résultats par domaine destinataire et chemin d’envoi. Un domaine d’entreprise peut utiliser Microsoft 365, une autre passerelle ou changer de fournisseur. Les MX et les en-têtes des messages livrés identifient le chemin actuel plus sûrement qu’une hypothèse fondée sur la marque.

Règle de décision :

Fiches pour choisir la télémétrie expéditeur Microsoft selon le domaine destinataire et les preuves disponibles
Source : Palisade.
  • Boîtes grand public Microsoft : consultez SNDS et JMRP, puis comparez aux réponses SMTP et aux logs de campagne.
  • Un destinataire Microsoft 365 d’entreprise : demandez les preuves du tenant (suivi, quarantaine, filtrage).
  • Question d’authentification avant l’envoi : examinez le DNS publié avec les outils e-mail gratuits de Palisade, puis testez un vrai message par le chemin de production.
  • Problème multi-fournisseurs : groupez les preuves par destinataire, IP, domaine From visible, return-path, domaine DKIM, campagne et période.

Exemple de fiche de preuves SNDS

Les données SNDS servent de preuves au niveau IP, pas de score de placement. Selon la FAQ de Microsoft, les données quotidiennes d’e-mails et de spam peuvent manquer si une IP a envoyé moins de 100 messages ce jour-là. Microsoft précise que son filtrage agrégé ne reflète pas directement le placement final (boîte de réception ou indésirables) : réglages et listes d’autorisation du destinataire peuvent jouer.

Utilisez une fiche d’incident comme celle-ci pour comparer SNDS à vos logs d’envoi :

Exemple techniquetext
Recipient service: Outlook.com consumer mail
Sending IP: 192.0.2.25
UTC send window: 2026-08-11T08:00:00Z to 2026-08-11T12:00:00Z
Visible From domain: yourdomain.com
Return-path domain: bounce.yourdomain.com
DKIM d= domain: yourdomain.com
SNDS observation: record the reported daily filter result and complaint data
Message evidence: preserve the SMTP response and redacted Authentication-Results header

Exemple illustratif. Ne publiez pas d’adresses de destinataires, d’en-têtes non expurgés, de plaintes, d’identifiants de compte ni d’autres données client.

Une couleur de filtrage peut indiquer qu’une IP demande de l’attention, mais n’identifie pas le client responsable sur un pool partagé ni ne prouve pourquoi une campagne a été filtrée. Les rapports JMRP, logs d’envoi et preuves par message affinent la question.

Que faire ensuite

Partez des preuves que vous avez.

Si vous contrôlez l’IP d’envoi, demandez l’accès SNDS et inscrivez-vous à JMRP si besoin. Exportez ou notez la période concernée avant de modifier campagnes, listes ou infrastructure. Puis comparez la vue SNDS avec l’IP exacte et la fenêtre UTC dans la plateforme d’envoi.

Si un ESP contrôle l’IP, demandez-lui s’il est autorisé pour SNDS et JMRP, quelles plaintes il transmet aux clients et comment il les relie à un compte. Le fournisseur peut être seul à accéder directement à la télémétrie de l’IP partagée.

Si le problème touche un message livré, récupérez le résultat SMTP et une copie expurgée de son en-tête Authentication-Results. La RFC 8601 définit le champ Authentication-Results, qui consigne les résultats d’un service d’authentification. Un contrôle DNS confirme un enregistrement publié, mais ne prouve pas que l’application a signé le message ni que Microsoft a pris telle décision de boîte.

Pour le contexte plus large, voyez la rubrique délivrabilité des e-mails de Palisade.

Suivez les expéditeurs des signaux Microsoft récurrents

SNDS peut montrer un signal IP, et JMRP que des destinataires ont signalé des messages comme indésirables. Aucune vue ne recense chaque expéditeur de production sous votre domaine From visible ni ne prouve l’alignement des futurs messages.

L’agent DMARC de Palisade peut analyser vos rapports agrégés, repérer les sources d’envoi et les défauts d’authentification ou d’alignement, et créer des tickets de correction priorisés. Un humain vérifie les preuves et applique tout changement de DNS ou de DMARC.

Commencez avec Palisade

Palisade ne change pas le verdict privé de réputation d’un destinataire et ne garantit ni la boîte de réception, ni que tout futur message s’authentifiera.

Pour une mise en œuvre propre à un fournisseur de ces contrôles, voyez Quelles données expéditeur fournit Yahoo Postmaster ?.

Preuve

Sources et pour aller plus loin

Questions des lecteurs

Questions fréquentes

SNDS équivaut-il à Google Postmaster Tools ?

Non. SNDS est l’équivalent Microsoft le plus proche pour le trafic grand public Outlook.com, mais il vise surtout l’IP et diffère des tableaux domaine et IP de Google, centrés sur Gmail.

SNDS couvre-t-il chaque domaine Microsoft 365 ?

Non. SNDS couvre l’infrastructure grand public Outlook.com. Il n’expose pas le filtrage privé, la quarantaine ni le suivi des messages au niveau tenant de chaque organisation sur Microsoft 365.

Un résultat SNDS vert veut-il dire boîte de réception ?

Non. Selon Microsoft, le filtrage agrégé ne reflète pas directement la livraison finale (réception ou indésirables). Les réglages et listes d’autorisation du destinataire peuvent la modifier.

Un client d’ESP peut-il accéder à SNDS ?

Seulement s’il satisfait aux exigences d’autorisation de Microsoft pour l’IP d’envoi, la plage ou le numéro de système autonome. Sur un pool d’IP partagé, l’ESP peut être la partie autorisée.

Que faire d’une plainte JMRP ?

Excluez le destinataire du flux concerné si vous pouvez l’identifier sans risque, puis examinez la campagne, le consentement, la source d’acquisition, l’heure d’envoi, l’IP d’envoi et les preuves d’authentification.

Simplifiez l’authentification e-mail

Démarrez sur Palisade.

Commencer

Partager cet article

Johanie Dupont

Rédigé par

Johanie Dupont

Marque et e-commerce

Johanie Dupont s’occupe de l’e-mail de marque et e-commerce chez Palisade : BIMI, marques vérifiées, règles d’expéditeur, e-mails marketing en boîte.

Lire Johanie →

Articles et outils liés