Logs du relais SMTP Google Workspace : diagnostiquer un email en échec

Lorsqu’une application indique qu’elle a envoyé un email, commencez par collecter les identifiants. Ne supposez pas que Google a accepté le message. L’heure, l’IP d’envoi, les adresses et le Message-ID déterminent les preuves qu’il sera possible de relier.

Le parcours d’investigation

1. Notez l’heure avec son fuseau, l’expéditeur et le destinataire complets.
2. Conservez la réponse SMTP complète de l’application ou de l’équipement.
3. Récupérez le Message-ID si l’émetteur en a produit un.
4. Lancez une recherche dans Email Log Search avec l’identifiant le plus fiable.
5. Si aucun résultat n’apparaît, vérifiez les hypothèses de recherche avant de conclure.
6. Consultez les événements Gmail via Reports API ou un export BigQuery existant lorsque l’incident exige davantage de champs ou d’historique.

Les preuves à collecter

Un dossier solide rapproche plusieurs observations indépendantes :

• heure et résultat côté application ;
• IP publique observée par le relais ;
• expéditeur d’enveloppe et adresse From visible ;
• destinataire d’enveloppe ;
• Message-ID ;
• code et texte complets de la réponse SMTP ;
• règle de relais Workspace concernée.

Le statut « envoyé » côté application peut uniquement signifier que l’application a transmis les données à une bibliothèque ou à un serveur local. Ce n’est pas une preuve d’acceptation par Google ni de livraison au destinataire.

Si Email Log Search ne trouve rien

La fenêtre de temps ou l’identité recherchée peut être incorrecte, l’événement peut être retardé, le message peut être passé par une autre route ou l’échange SMTP peut avoir échoué avant l’enregistrement d’un événement consultable.

Le bon résultat n’est donc pas « Google l’a perdu », mais une liste d’hypothèses vérifiées et la prochaine source capable de confirmer ou d’écarter chacune d’elles.

Ce que cette preuve permet et n’autorise pas de conclure

Les journaux de relais et de remise Workspace montrent que Google a enregistré un traitement pour les identités et la fenêtre recherchées. Ils ne prouvent pas à euls l’arrivée en boîte de réception, la lecture par le destinataire, ni que le statut « envoyé » de l’application correspond à la vue Google. Traitez la réponse SMTP comme preuve transport ; croisez-la avec les événements fournisseur avant de clore le dossier.

Si le message n’apparaît jamais chez Google

Une recherche Email Log Search vide peut signifier identité ou fuseau incorrect, route hors Workspace (ESP, autre relais, MX direct), délai hors fenêtre, ou échec avant l’enregistrement d’un événement. Ce n’est pas une preuve de livraison au destinataire.

Différence avec un outil ponctuel ou un rapport DMARC

Les analyseurs d’en-têtes et tests SMTP (par ex. Messageheader ou MXToolbox) portent sur un message ou une connexion ; ils ne tiennent pas la chronologie d’un incident entre application, relais et exports. Les RUA DMARC résument l’alignement d’authentification par IP sur une journée ; ils ne remplacent pas les logs Workspace pour un envoi relais manquant. Voir l’annuaire comparatif.

Limites

La disponibilité des événements dépend de Google, de la licence et de la configuration du client. PunchOp ne peut pas reconstruire un événement qui n’a jamais été enregistré. Reports API et BigQuery doivent être comparés selon les champs nécessaires à l’incident.

Sources

• G01 : documentation Google Workspace sur Email Log Search.
• G02 : messages d’erreur du relais SMTP Google Workspace.
• G04 : schéma BigQuery des logs Gmail.
• G05 : événements Gmail disponibles dans Reports API.
• R01 : témoignage public utilisé comme signal de problème, pas comme documentation technique.