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é
Expliquez pourquoi un email est arrivé — ou pourquoi les preuves ne suffisent pas.
Un message, en lecture seule : le chemin d’envoi visible, une chronologie sourcée, les lacunes et le prochain contrôle. Pas une purge de phishing, ni un SIEM.
Cette page est la version de travail, pour les administrateurs Workspace et les infogérants qui tiennent leur courrier. Lecture DNS publique : les enregistrements publiés, sans accès au tenant, pas une remise.
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
app.punchop.com
Enquête en lecture seule
Connexion avec votre compte Google Workspace. PunchOp lit des journaux de métadonnées. Il ne lit pas les corps et il n’envoie pas de courrier.
- La connexion utilise le compte Google : adresse, nom et domaine Workspace.
- Un super-administrateur accorde ensuite l’annuaire en lecture seule : statut admin, domaines vérifiés, et un compte des identifiants, par pages de 500.
- La lecture des journaux est un consentement séparé pour l’audit Gmail. Une synthèse ultérieure passe par Vertex AI dans l’UE, sans entraînement de modèle.
Un modèle d’investigation. Plusieurs sources de preuves.
Google WorkspacePremière intégration
Microsoft 365Prévu
Amazon SESPrévu
La promesse
Un dossier de remise, pas une purge de sécurité.
PunchOp reconstitue un email à travers l’application, la réponse SMTP et les journaux fournisseur qui existent. Chaque fait garde sa source. Une ligne absente reste une ligne absente.
- Nommer le chemin d’envoi que les preuves montrent vraiment.
- Séparer envoyé, accepté, journalisé et remis.
- Montrer ce qui manque, et ce que cette absence ne prouve pas.
- Indiquer le prochain contrôle qui peut combler la lacune.
- Retirer une campagne de phishing de toutes les boîtes.
- Prouver la boîte de réception avec un SMTP 250.
- Remplacer Email Log Search, BigQuery ou un SIEM.
- Inventer un événement qu’aucun système n’a enregistré.
Trois difficultés d’exploitation
Des difficultés récurrentes dans l’exploitation de Google Workspace.
Chaque carte sépare le symptôme observé, les faits étayés par les sources officielles et l’investigation que PunchOp est conçu pour mener. La réponse décrit une cible, pas une fonctionnalité livrée.
Les preuves sont dispersées dans Workspace — et BigQuery exige toujours un SQL maîtrisé
Pourquoi un incident de messagerie peut traverser la recherche dans les journaux, l’outil d’investigation, Reports API et BigQuery avant d’obtenir une réponse défendable.
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
Les limites du relais SMTP Google Workspace combinent organisation, utilisateur, destinataire et transaction ; le bridage temporaire constitue un signal distinct.
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
La cartographie des systèmes émetteurs, l’alignement d’authentification, la politique du fournisseur et les preuves MIME doivent être séparés avant d’expliquer un échec Outlook ou Hotmail.
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
Prévu : partager un dossier avec l’équipe responsable de la prochaine vérification.
Export BigQuery (Enterprise / Education). Reports API : chargement de l’audit Gmail et comptes de rebonds. La lecture mesurée ne contient pas de code de réponse SMTP.
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 — pas 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.