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
Investigate email incidents across the systems that send them.
Reconstruct what happened from application evidence, SMTP responses and provider events. See the facts, the gaps and the next useful check.
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
One investigation model. Multiple evidence sources.
Google WorkspaceFirst investigation path
Microsoft 365Planned provider
Amazon SESPlanned provider
Three first-party pain points
Real incidents from operating Google Workspace email.
These three cases come from direct operational experience. PunchOp separates the observed symptom, the facts supported by official sources, and the proposed investigation.
The evidence is spread across Workspace tools—and BigQuery still needs careful SQL
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.
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
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.
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
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.
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
Share one case record with the team that owns the next check.
SOURCE 01Application or deviceSMTP response · local logs · configuration
+SOURCE 02Google WorkspaceEmail Log Search · Reports API · BigQuery
→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.