When an application reports that it sent an email, start by collecting identifiers—not by assuming that Google accepted the message. A timestamp, sending IP, sender, recipient and Message-ID determine which evidence can be connected.
The short investigation path
- Record the time with timezone and the full sender and recipient addresses.
- Capture the complete SMTP response from the application or device.
- Preserve the Message-ID when the sender generated one.
- Search Google Workspace Email Log Search with the narrowest reliable identifiers.
- If nothing appears, test the search assumptions before concluding that the message reached Google.
- Move to Gmail events through Reports API or an existing BigQuery export when the incident requires fields or history unavailable in the first search.
Evidence worth collecting
The strongest incident record combines independent observations:
- application timestamp and result;
- public source IP observed by the relay;
- envelope sender and visible
Fromaddress; - envelope recipient;
- Message-ID;
- complete SMTP response code and text;
- relevant Workspace relay rule.
An application-side “sent” result may mean that the application handed data to a local library or server. It is not, by itself, proof of acceptance by Google or delivery to the recipient.
When Email Log Search returns nothing
A missing result has several possible explanations: the search window or identity may be wrong, the event may be delayed, the message may have used another route, or the SMTP exchange may have failed before a searchable event was recorded.
The useful outcome is therefore not “Google lost it.” The useful outcome is a list of checked assumptions and the next source that could confirm or reject each one.
What this evidence can and cannot prove
Workspace relay and delivery logs can show that Google recorded handling for identities and times that match your search. They do not, by themselves, prove inbox placement, recipient read state, or that an application’s internal “sent” flag matches Google’s view. Treat SMTP response text as transport-level evidence; pair it with provider events before you close the case.
If the message never appears in Google
An empty Email Log Search or missing relay event usually means one of: wrong sender, recipient or timezone; a path that bypasses Workspace (third-party ESP, another relay, direct MX); delay outside the window; or failure before Google logged an event. It is not proof the message was delivered to the recipient.
How this differs from a point tool or a DMARC report
Header analyzers and SMTP testers (for example Google Admin Toolbox Messageheader or MXToolbox diagnostics) inspect one message or one connection; they do not maintain a case timeline across application, relay and exports. DMARC aggregate (RUA) reports summarize authentication alignment by source IP over a day; they do not replace message-level Workspace logs for a single missing relay send. See the comparison directory for documented scope notes.
Limits
Event availability depends on Google, licensing and the customer’s configuration. PunchOp cannot reconstruct an event that was never recorded. Reports API and BigQuery should be compared against the fields needed for the incident, not treated as automatically interchangeable.
Sources
- G01: Google Workspace, Email Log Search troubleshooting.
- G02: Google Workspace SMTP relay error messages.
- G04: Google Workspace Gmail logs schema for BigQuery.
- G05: Google Workspace Gmail activity events in Reports API.
- R01: Public administrator discussion describing limited relay visibility; used as a problem signal, not technical documentation.