Inscription à la bêta inspecteur
Demandez l’accès anticipé au SaaS d’investigation email en construction. Nous vous écrirons quand vous pourrez mener l’investigation vous-même dans le produit.
Inscription bêta Inspecteur SaaS en développement · Google Workspace d’abord · incidents ou accès anticipé
Comprendre les incidents email à travers tous les systèmes impliqués.
Reconstruisez ce qui s’est passé à partir des preuves applicatives, des réponses SMTP et des événements du fournisseur. Distinguez les faits, les lacunes et la prochaine vérification utile.
Ce que vous pouvez faire
Soumettre une difficulté réelle
Décrivez un incident SMTP Workspace pour la bibliothèque publique—symptôme, contexte et fréquence. Pas de logs bruts, identifiants ni contenu de messages.
Soumettre une difficultéGuides et recherche disponibles. L’inspecteur est construit avec des administrateurs Workspace.
COMMENT PUNCHOP EXPLIQUERAIT UN INCIDENT
INVESTIGATIONRéinitialisation du mot de passe non reçue
Preuves manquantes- L’application indique « envoyé »
Message-ID collecté dans le système émetteur.
<f82a…@app.example> - Connexion acceptée par le relais SMTP
IP source observée dans les événements Workspace.
198.51.100.24 - Événement de livraison introuvable
Les preuves disponibles ne confirment pas la livraison.
Vérification suivante → destinataire d’enveloppe et fenêtre de temps
Un modèle d’investigation. Plusieurs sources de preuves.
Google WorkspacePremière intégration
Microsoft 365Prévu
Amazon SESPrévu
Trois problématiques vécues
Des incidents réels issus de l’exploitation de Google Workspace.
Ces trois cas viennent de l’expérience opérationnelle à l’origine de PunchOp. Nous séparons le symptôme observé, les faits étayés par les sources officielles et l’investigation proposée.
Les preuves sont dispersées dans Workspace — et BigQuery exige toujours un SQL maîtrisé
Les administrateurs ne savent pas toujours quelle interface Google contient l’événement recherché, quelle licence ou autorisation l’expose, ni comment interroger un export sans lire des données inutiles.
Problème
Lire le cas d’usage sourcé →Les administrateurs ne savent pas toujours quelle interface Google contient l’événement recherché, quelle licence ou autorisation l’expose, ni comment interroger un export sans lire des données inutiles.
Réponse PunchOp (étape 1)Partir de l’incident et sélectionner la plus petite source de preuve pertinente.
LimiteToutes les requêtes ne sont pas coûteuses. PunchOp ne peut récupérer ni un événement hors rétention, ni une donnée jamais enregistrée.
Une limite d’envoi n’est pas un chiffre unique
Une équipe reçoit une erreur SMTP temporaire et cherche une limite par minute, utilisateur, application ou organisation. Les limites Gmail et celles du relais sont alors mélangées.
Problème
Lire le cas d’usage sourcé →Une équipe reçoit une erreur SMTP temporaire et cherche une limite par minute, utilisateur, application ou organisation. Les limites Gmail et celles du relais sont alors mélangées.
Réponse PunchOp (étape 1)Relier chaque erreur observée à la route, l’identité, la fenêtre temporelle et au nombre de destinataires.
LimiteLa formule souvent répétée « 10 par minute et par utilisateur » n’est pas une limite générale documentée du relais SMTP Workspace.
Quand de nombreuses applications envoient, l’identité défaillante devient difficile à localiser
Après un changement de politique du destinataire, les messages de certaines applications internes ne sont plus remis ou sont classés en courrier indésirable. Le marketing voit un incident global, mais l’exploitation ne localise pas le système émetteur.
Problème
Lire le cas d’usage sourcé →Après un changement de politique du destinataire, les messages de certaines applications internes ne sont plus remis ou sont classés en courrier indésirable. Le marketing voit un incident global, mais l’exploitation ne localise pas le système émetteur.
Réponse PunchOp (étape 1)Cartographier application, relais, expéditeur d’enveloppe, domaine From, sélecteur DKIM et IP sortante.
LimiteUn problème de pièce jointe ou d’encodage doit être démontré au niveau du message. Il ne doit pas être déduit d’un changement de politique concomitant.
Un workflow ciblé
Des traces dispersées à une prochaine étape défendable.
PunchOp est organisé autour de l’incident, pas d’un tableau de bord générique.
Collecter
Heures, identités, IP, Message-ID et réponses complètes.
Contextualiser
Normaliser les preuves de l’émetteur et du fournisseur.
Expliquer
Séparer les événements observés, les hypothèses et les lacunes.
Transmettre
Partager un dossier avec l’équipe responsable de la prochaine vérification.
Signaux publics
Des incidents réels, sans inventer de clients.
Ces cas proviennent de discussions publiques. Ils servent à définir une investigation reproductible, pas à revendiquer une résolution non testée.
Cas d’usageA01
Un ZIP « Google DMARC » dans ma boîte : est-ce un incident ?
Difficulté admin : fichiers google.com!domaine.zip, lignes SPF fail dans le XML, et comment décider si l’authentification email demande une action.
Voir l’approche →Cas d’usageR01
Un système interne indique que l’email est parti, mais les logs restent ambigus
Comment PunchOp structurerait l’investigation lorsque l’application annonce un succès et que les preuves Workspace sont incomplètes.
Voir l’approche →Cas d’usageR02
Quelles applications utilisent encore le relais SMTP Workspace ?
Une investigation d’inventaire pour les équipes qui disposent de longues listes d’IP autorisées sans correspondance fiable avec les applications.
Voir l’approche →PunchOp et les solutions existantes
Trace native, contrôles ponctuels, DMARC agrégé, SIEM—puis une investigation guidée.
Chaque chemin couvre une partie du dossier. PunchOp vise à reconstruire un incident en lecture seule avec provenance et preuves manquantes visibles—not un remplacement de Google, BigQuery ou d’un SIEM.
Comparer les options documentées →Email Log Search, Reports API et BigQuery—faisant autorité si l’envoi a transité Google.
Un message ou une connexion à la fois—validation, pas dossier multi-sources.
Authentification par IP sur une fenêtre—contexte, pas trace message.
Centralisation des exports quand l’ingestion est en place.
Reconstruction de dossier en lecture seule : provenance, incertitude, preuves manquantes.
Guides d’investigation
Commencez par l’incident que vous avez devant vous.
Des réponses directes, des sources officielles et des limites visibles.
01
fr-dmarc
↗02Rapport DMARC agrégé (RUA) : lire le fichier google.com!domaine.zip
À quoi sert un ZIP RUA envoyé par Google, comment interpréter SPF fail et DKIM pass, et quand cela devient un signal d’incident.
fr-relay
↗03Logs du relais SMTP Google Workspace : diagnostiquer un email en échec
Une checklist de preuves pour retrouver l’email d’une application ou d’un équipement dans Google Workspace et choisir la vérification suivante.
fr-relay
↗Email Log Search ne retourne aucun résultat : que vérifier ?
Transformez une recherche vide dans les journaux Google Workspace en une suite de vérifications, sans tirer de conclusion hâtive sur la livraison.
Construire le pilote
Qu’est-ce qui a ralenti votre dernier diagnostic SMTP ?
Partagez d’abord le contexte, sans messages bruts, secrets ni logs complets.