Google Postmaster : tableaux de réputation domaine et IP

Quand la réponse change

La réponse pratique dépend de la version de Postmaster Tools accessible à votre compte.

Si le compte affiche encore une ancienne vue de réputation, lisez les notes de domaine et d’IP séparément. Une note d’IP porte sur l’adresse d’envoi observée par Google. Une note de domaine porte sur le domaine exact authentifié par DKIM ou SPF. Un mauvais résultat dans une vue ne documente pas, à lui seul, la cause d’un résultat dans l’autre.

Si le compte utilise Postmaster Tools v2 et que les anciennes cartes de réputation manquent, ne supposez pas qu’une carte de remplacement a les mêmes libellés ou le même sens. L’avis d’abandon de Google dit que les nouveaux tableaux donneront des informations plus exploitables, sans documenter de remplacement direct des anciens tableaux Domain Reputation ou IP Reputation. Utilisez les tableaux et les erreurs disponibles dans le compte, puis comparez-les aux données réelles d’authentification et de livraison de l’expéditeur.

Les consignes aux expéditeurs de Google traitent à part les IP partagées. L’activité d’autres expéditeurs sur une IP partagée peut nuire à sa réputation. Cela ne veut pas dire qu’un client sur IP partagée peut voir ou contrôler le comportement de chaque expéditeur.

Une règle de décision pratique face à un résultat

Partez des preuves que Google rapporte vraiment, puis réunissez celles du même chemin d’envoi. Cette règle évite de prendre une couleur de tableau pour un diagnostic de cause.

Illustrative decision rule
If a legacy Domain Reputation or IP Reputation result is available:
  Record the date, the exact authenticated domain, and the sending IP.
  Compare the result with the Spam Rate, Authentication, and Delivery Errors views.
  Inspect a delivered message from the same production sender.
If the old reputation views are unavailable in Postmaster Tools v2:
  Do not infer an old-style reputation rating.
  Use available Gmail dashboards, delivery errors, and message authentication evidence.
  Check public IP signals separately when the sending IP is known.

Pour un message livré, examinez l’en-tête Authentication-Results ajouté par le destinataire plutôt qu’un écran de configuration d’ESP. La RFC 8601 définit ce champ d’en-tête pour rapporter les résultats d’authentification. Un succès DKIM ou SPF aide à établir ce que Google associe au trafic, mais ne prouve pas une réputation élevée.

Si le problème touche l’identité du domaine plutôt que l’adresse d’infrastructure, revoyez la distinction dans qu’est-ce que la réputation de domaine. Si l’enjeu est la confiance plus large envers l’expéditeur, la réputation d’expéditeur couvre ce concept sans ériger un tableau de fournisseur en norme universelle.

Que vérifier après un résultat

Servez-vous de vos preuves :

• Si vous avez accès à l’ancien Postmaster Tools, comparez la réputation affichée aux données Spam Rate, Authentication et Delivery Errors de Google sur la même période.
• Si vous avez une erreur de livraison Gmail, conservez l’erreur exacte et examinez un message du chemin de production touché. Google classe la faible réputation de l’IP et du domaine d’envoi en catégories d’erreur distinctes dans ses conseils sur les tableaux Postmaster Tools.
• Si vous connaissez l’IP d’envoi, vérifiez à part ses signaux publics, et testez le domaine sur les listes de blocage publiques. Cela peut révéler un problème de liste externe, sans reproduire le calcul privé de réputation de Google.
• Si l’e-mail passe par un expéditeur tiers, identifiez le domaine authentifié et l’IP réelle avant de changer le DNS ou le routage. La documentation de Google ne fait pas d’un écran de configuration fournisseur la preuve du chemin d’envoi réel.

Vérifiez les signaux publics de l’IP d’envoi

Si l’ancienne note IP de Google manque, ou s’il vous faut une seconde source pour une adresse d’envoi connue, examinez cette IP avant de juger si le problème se limite à Gmail.

Vérifier l’IP d’envoi

Un test d’IP public ne peut pas montrer la note actuelle de Google, prouver pourquoi Gmail a filtré un message ni garantir le placement futur chez Gmail.

Si les rapports agrégés montrent plusieurs sources légitimes sur le même domaine, il faut repérer en continu les chemins qui réussissent l’authentification alignée et ceux à corriger. Palisade analyse seul les rapports agrégés DMARC, repère les problèmes d’authentification ou d’alignement et crée des tickets de correction priorisés. Il ne change pas la décision de réputation de Google ni ne garantit la livraison.

Commencez avec Palisade