Gmail : « Looks safe » et images masquées, pourquoi ?

Choisir l’approche

Séparez les preuves en trois couches avant de choisir une correction :

• Preuves côté expéditeur : enregistrements SPF, DKIM et DMARC publiés, configuration d’envoi, domaines authentifiés et réponses de l’hôte d’images.
• Constat Gmail : la bannière de sécurité visible, l’invite d’images et le comportement dans un compte précis.
• Logique privée du classifieur : le processus de décision interne et non publié de Gmail. Les deux premières couches s’examinent. La troisième ne se déduit pas d’un en-tête ou d’une requête DNS.

• Si la demande, les liens, la pièce jointe ou l’identité semblent dangereux, vérifiez par un numéro connu, un site en favori ou un nouveau message à une adresse connue. N’interagissez pas avec le message concerné.
• Si une image échoue une fois que le destinataire l’affiche, inspectez l’hébergement, le contrôle d’accès, la réponse TLS et la disponibilité de son URL. C’est un problème de livraison ou de rendu d’image, pas une preuve du motif de Gmail.
• Si des en-têtes fiables montrent un écart d’authentification, corrigez seulement la route qui l’a créé, puis envoyez un nouveau test.
• Si l’authentification réussit et que le même résultat Gmail se répète, conservez les preuves et examinez le contenu, les liens, le Reply-To et l’hébergement des images. Google ne publie pas de correspondance complète entre causes et bannière.

Mener une enquête côté expéditeur

1. Conservez le message et vérifiez la demande à part

Demandez au destinataire de ne pas choisir « Looks safe », ouvrir les pièces jointes, suivre les liens, répondre ou charger les images avant de confirmer la demande par un canal fiable distinct. Un nom affiché familier, un contact ou un fil existant ne prouvent pas qu’un message est sûr.

Notez l’avertissement exact, le comportement des images, l’adresse From visible, le compte destinataire et l’heure. Une capture recadrée documente ce que Gmail a affiché, mais ne conserve pas les preuves de routage et d’authentification d’un diagnostic côté expéditeur.

2. Créez une fiche expurgée du message et de son rendu

Exportez le message original livré ou ses en-têtes complets depuis le compte Gmail destinataire. Évitez une copie transférée : le transfert peut ajouter des champs de routage et changer les preuves vues par le récepteur.

Exemple de fiche expurgée :

message_id: <Message-ID value>
received_at_utc: <UTC timestamp>
visible_from: alerts@yourdomain.com
reply_to: support@yourdomain.com
return_path: bounce@mailer.yourdomain.com
trusted_authentication_results: <receiver-added SPF, DKIM, DMARC, ARC results if available>
authenticated_sender_domain: yourdomain.com
image_url_context: https://images.yourdomain.com/... <do not open suspicious content>
image_hosting_context: <public, authenticated, expired, blocked, or unknown>
gmail_banner_observation: <exact displayed wording>
gmail_image_observation: <exact prompt or hidden-image behavior>
recipient_test_account: <redacted Gmail account or controlled test account>
retest_date_utc: <UTC timestamp after any change>

Cette fiche sépare les faits côté expéditeur du constat Gmail. Ne copiez ni contenu privé, ni adresses de destinataires, paramètres de suivi, identifiants, jetons ou en-têtes non expurgés dans un ticket partagé hors de l’enquête.

Authentication-Results est un champ d’en-tête ajouté par le récepteur. La RFC 8601 définit sa syntaxe et indique de se fier aux résultats ajoutés par le système de réception, plutôt qu’à un champ similaire fourni par un expéditeur non fiable.

3. Identifiez le cas des images

Demandez si le compte Gmail est réglé pour demander avant d’afficher les images externes des messages ordinaires, ou si Gmail a retenu les images pour ce seul expéditeur ou message. Le guide de Google sur les images dans Gmail documente le réglage qui demande avant d’afficher les images externes.

Si Gmail affiche les images une fois autorisées mais qu’une image est cassée, inspectez l’hôte d’images à part. Vérifiez si l’URL exige une connexion, a expiré, renvoie une erreur ou est bloquée par un contrôle réseau. N’ouvrez pas d’URL suspecte pendant l’enquête. Passez plutôt par un accès d’administration ou d’hébergement sûr pour inspecter le fichier.

4. Comparez le message livré à l’expéditeur prévu

Comparez le domaine From visible, le domaine Reply-To, le domaine de return-path, le domaine DKIM d= et la route d’envoi à la configuration prévue pour ce flux. Google explique comment voir des détails comme « Envoyé par » (Mailed by) et « Signé par » (Signed by) dans les détails de l’expéditeur Gmail, mais les en-têtes originaux complets sont de meilleures preuves.

Pour DMARC, un identifiant SPF ou DKIM aligné doit correspondre au domaine From visible selon les règles d’alignement DMARC de la RFC 9989. Un succès SPF pour un return-path sans rapport ou DKIM pour un d= sans rapport n’établit pas à lui seul un succès DMARC aligné.

5. Ne corrigez qu’un problème d’envoi identifié

N’appliquez un changement que si le message original montre un écart ou un échec.

• Pour SPF, n’autorisez que le service légitime qui envoie avec le domaine d’enveloppe concerné. Gardez les mécanismes existants : un domaine n’a qu’un enregistrement de politique SPF.
• Pour DKIM, publiez l’enregistrement généré par l’expéditeur pour le sélecteur et le domaine de signature de la route. N’inventez pas de sélecteur, ne copiez pas la clé d’un autre compte.
• Pour DMARC, gardez une seule politique valide pour le domaine From visible. Consultez les rapports agrégés avant de changer l’application.
• Pour l’hébergement d’images, corrigez le problème d’accès, d’expiration, de TLS ou de disponibilité vu lors de l’inspection contrôlée.

Ne remplacez pas un enregistrement SPF ou DMARC existant par un exemple. Un remplacement à l’aveugle peut casser l’autorisation ou les rapports d’autres flux légitimes.

Exemple d’enregistrement DMARC :

_dmarc.yourdomain.com TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com"

Ce n’est qu’un exemple. Partez de l’enregistrement existant et gardez ses balises et destinations de rapports légitimes. Un déploiement DMARC commence par la surveillance, puis passe à quarantine et reject seulement quand les rapports agrégés montrent que les sources légitimes s’authentifient et s’alignent.

Valider la configuration

Validez la route corrigée sur quatre couches distinctes :

• DNS : interrogez le domaine sur son serveur DNS faisant autorité et au moins un résolveur public. Confirmez que l’enregistrement SPF, DKIM ou DMARC voulu répond, sans retirer d’enregistrements valides. Le test DMARC de Palisade aide à confirmer l’enregistrement publié.
• Expéditeur : vérifiez le statut d’authentification de l’application, de l’ESP ou de la passerelle pour le domaine et le sélecteur exacts. Un voyant vert ne prouve pas qu’un message livré a utilisé ce réglage.
• Message : envoyez un nouveau test par les mêmes application, compte et passerelle. Inspectez les Authentication-Results du récepteur, le From visible, le return-path, le Reply-To et le d= DKIM.
• DMARC : une fois les rapports accumulés, vérifiez que les IP sources et identifiants de la route corrigée réussissent et s’alignent.

Si le message corrigé affiche encore un avertissement ou des images masquées malgré une authentification réussie, notez-le sans conclure que la correction a échoué. Le problème restant peut venir du contenu, des liens, de l’hébergement des images, des réglages du destinataire ou de la décision non publiée de Gmail.

Dépannage

Gmail masque les images de tous les messages

Vérifiez d’abord le réglage d’affichage des images du compte. Les instructions de Google sur les images distinguent une préférence du compte, qui demande avant d’afficher les images externes, d’une décision de sécurité propre au message. C’est un réglage du destinataire : le DNS de l’expéditeur n’y change rien.

Images masquées pour un seul expéditeur ou message

Conservez l’avertissement exact et comparez le message à un message sain du même expéditeur. Vérifiez les en-têtes fiables, l’identité visible, le Reply-To, les liens et l’accès à l’hôte d’images. Toute conclusion sur le classifieur privé de Gmail reste une déduction : Google ne publie pas de correspondance complète entre traits du message et avertissements.

SPF ou DKIM réussit, mais DMARC échoue

Comparez les identifiants authentifiés au domaine From visible. DMARC exige un succès SPF ou DKIM aligné, pas seulement un succès. Examinez la valeur smtp.mailfrom pour SPF et la valeur DKIM header.d quand le récepteur les indique.

L’image s’affiche pour un administrateur, pas un destinataire

Vérifiez si l’hôte d’images exige un cookie de session, une URL signée, un accès réseau privé ou un jeton non expiré. Testez dans le contexte du destinataire contrôlé sans ouvrir d’URL d’un message suspect. Corrigez l’hôte d’images à part de l’enquête sur la sécurité Gmail.

Un test DNS réussit, mais Gmail affiche encore la bannière

Un résultat DNS ne confirme que ce que le DNS public a renvoyé au moment du test. Il ne montre ni l’application qui a envoyé le message, ni si elle l’a signé, ni la décision privée de Gmail ou l’affichage futur. Revenez au message original livré et comparez-le au message de test de la route de production exacte.

Inspecter les en-têtes de l’avertissement Gmail

Inspectez l’identité et l’authentification dans les en-têtes originaux avant de changer le DNS. L’analyseur d’en-têtes e-mail de Palisade convient si vous avez un en-tête brut expurgé du message concerné.

Inspectez les en-têtes e-mail

Une analyse d’en-têtes ne prouve pas la cause de l’avertissement Gmail, ne teste pas le réglage d’images, ne répare pas l’hébergement et ne prédit pas une décision future.

Si le domaine a des sources récurrentes en échec d’authentification ou d’alignement une fois le problème immédiat compris, Palisade est un logiciel DMARC agentique qui analyse les rapports agrégés DMARC, identifie les sources et problèmes d’authentification ou d’alignement, et crée des tickets de correction priorisés. Il peut proposer l’étape de politique suivante si les preuves le justifient ; un humain examine les preuves et applique tout changement DNS ou DMARC.

Commencez avec Palisade

Palisade ne change pas la décision privée de Gmail, ne modifie pas seul une politique DMARC, ne prouve pas que tout futur message s’authentifiera, ni ne garantit la boîte de réception.