Join the inspector beta
Request early access to the SaaS email investigator in development. We email you when you can run investigations yourself in the product.
Join inspector beta SaaS inspector in development · Google Workspace first · submit incidents or join early access
Explain why an email arrived — or why the evidence is not enough.
One message, read-only: the sending path you can see, a timeline with sources, the gaps, and the next check. Not a phishing purge, and not a SIEM.
The French page is written first for Workspace administrators and the firms that run their mail. Lire en français · DNS reading
What you can do now
Submit a real difficulty
Outline a Google Workspace SMTP incident for the public case library—symptom, context, and frequency. No raw logs, credentials, or message bodies.
Submit a difficultyGuides and research available now. A focused inspector is being shaped with Workspace administrators.
HOW PUNCHOP WOULD EXPLAIN AN INCIDENT
INVESTIGATIONPassword reset not received
Needs evidence- Application reports “sent”
Message-ID captured from the source system.
<f82a…@app.example> - SMTP relay accepted connection
Originating IP observed in Workspace events.
198.51.100.24 - Delivery event not found
The available evidence cannot confirm recipient delivery.
Next check → verify envelope recipient and time window
app.punchop.com
Read-only investigation
Sign in with your Google Workspace account. PunchOp reads metadata logs. It does not read message bodies and it does not send mail.
- Sign-in uses your Google account: email, name and Workspace domain.
- A super admin then grants read-only Directory access: admin status, verified domains, and a count of user ids, 500 per page.
- Log reading is a separate consent for Gmail audit events. A later written summary uses Vertex AI in the EU and does not train a model.
One investigation model. Multiple evidence sources.
Google WorkspaceFirst investigation path
Microsoft 365Planned provider
Amazon SESPlanned provider
The promise
A delivery case, not a security purge.
PunchOp reconstructs one email across the application, the SMTP response and the provider logs that exist. Each fact keeps its source. A missing row stays a missing row.
- Name the sending path the evidence actually shows.
- Separate sent, accepted, logged and delivered.
- Show what is missing, and what that absence does not prove.
- Point to the next check that could close the gap.
- Remove a phishing campaign from every mailbox.
- Prove inbox placement from an SMTP 250.
- Replace Email Log Search, BigQuery or a SIEM.
- Invent an event that no system recorded.
Three operator difficulties
Recurring difficulties when operating Google Workspace email.
Each card separates the observed symptom, the facts supported by official sources, and the investigation PunchOp is designed to run. The response is a design target, not a shipped feature.
The evidence is spread across Workspace tools—and BigQuery still needs careful SQL
Why an email incident can cross Email Log Search, the investigation tool, Reports API and BigQuery before an administrator gets a defensible answer.
Problem
Read the sourced use case →Administrators often do not know which Google surface contains the needed event, which license or privilege exposes it, or how to query an export without scanning irrelevant data.
PunchOp response (step 1)Start from the incident and identify the smallest relevant evidence source.
LimitNot every query is expensive, and PunchOp cannot recover events outside provider retention or data that was never recorded.
A sending limit is not one number
Google Workspace SMTP relay limits combine organization, user, recipient and transaction dimensions—and temporary throttling is a separate signal.
Problem
Read the sourced use case →A team sees a transient SMTP error and asks whether the limit is per minute, per user, per application or global. Different Gmail and relay limits are then mixed into one explanation.
PunchOp response (step 1)Attach every observed error to the exact route, identity, time window and recipient count.
LimitThe commonly repeated “10 per minute per user” is not a supported general Workspace SMTP relay limit.
When many applications send mail, the failing identity is hard to locate
Sender attribution, authentication alignment, provider policy and MIME evidence must be separated before explaining an Outlook or Hotmail delivery failure.
Problem
Read the sourced use case →After a recipient policy change, messages from some internal applications stop arriving or land in junk. Marketing sees a brand-wide incident, while operations cannot identify the exact sending system.
PunchOp response (step 1)Build a map from application to relay, envelope sender, From domain, DKIM selector and outbound IP.
LimitAn attachment or encoding issue must be demonstrated with message-level evidence. It should not be inferred from a coincident policy change.
A focused workflow
From scattered records to a defensible next step.
PunchOp is designed around the trace—not another generic dashboard.
- 01
Collect
Start with timestamps, identities, IPs, Message-IDs and complete responses.
- 02
Contextualize
Normalize evidence from the sender and available provider sources.
- 03
Explain
Separate observed events, working hypotheses and missing evidence.
- 04
Hand off
Planned: share one case record with the team that owns the next check.
SOURCE 01Application or deviceSMTP response · local logs · configuration
+SOURCE 02Google WorkspaceBigQuery export (Enterprise / Education) · Reports API (Gmail audit load, bounce counts)
→PUNCHOP CASEEvidence timelineFacts · gaps · next checks
Public problem signals
Real incidents. No invented customer stories.
These use cases come from public discussions. We use them to define a reproducible investigation—not to claim a resolution that has not been tested.
A ZIP from Google DMARC support landed in my inbox—is that an incident?
An administrator difficulty pattern: unexpected google.com!domain.zip files, SPF fail in XML, and how to decide if email authentication needs action.
See the investigation approach →An internal system says it sent the email—but the logs are unclear
How PunchOp would structure an SMTP relay investigation when an internal application reports success and the Workspace evidence is incomplete.
See the investigation approach →Which applications are still using the Workspace SMTP relay?
A sender-inventory investigation for teams with long relay allowlists and no reliable map from public IPs to applications.
See the investigation approach →PunchOp vs. available paths
Native trace, point checks, DMARC aggregate, SIEM—then a guided investigation layer.
Each path covers part of the case. PunchOp aims to reconstruct one read-only incident with provenance and missing evidence visible—not a replacement for Google, BigQuery or a SIEM.
Compare the documented options →Google Workspace evidence
Email Log Search, Reports API and BigQuery—authoritative when the send touched Google, with different fields and retention.
Header and SMTP tools
One message or one connection at a time—useful validation, not a persistent case across application and relay logs.
RUA platforms and ZIP reports
Domain-wide authentication by source IP over a window—supporting context, not a substitute for message-level trace.
Sumo · Elastic · Splunk
Centralize exports and alerts when ingestion is configured—you still decide which sources answer this incident.
PunchOp
Read-only case reconstruction: provenance, uncertainty, missing evidence and the next defensible check.
Investigation guides
Start with the incident in front of you.
Direct answers, official sources and visible limits—written for administrators, not search engines alone.
01
Browse all guides →dmarc auth
↗02DMARC aggregate report (RUA): read the google.com!domain.zip file
What a DMARC RUA ZIP from Google means, how to read SPF fail with DKIM pass, and when it is an incident signal versus normal ESP sending.
relay logs
↗03Google Workspace SMTP relay logs: investigate a failed email
A practical evidence checklist for finding an application or device email in Google Workspace and deciding what to check next.
message trace
↗Email Log Search shows no results: what to check
Turn an empty Google Workspace Email Log Search into a structured sequence of checks instead of a delivery conclusion.
Help shape the inspector
What took too long to understand in your last SMTP incident?
Share the outline first. Do not send raw messages, credentials or complete logs.