Public problem signal
Administrators have asked how to discover which IPs actively use their Google Workspace SMTP relay. The configuration shows what is allowed; it does not necessarily show what is currently observed.
How PunchOp would investigate
PunchOp would normalize observed relay events by source IP, envelope sender, frequency and last-seen time. The admin could then attach an owner and system name to evidence instead of treating the IP as a complete identity.
The inventory view
For each observed source:
- public IP and first/last observation;
- sender identities and recipient domains;
- accepted, deferred and rejected event counts;
- known owner or application;
- confidence and unresolved attribution.
Important limitation
A shared or rotating public IP cannot establish the identity of one printer, ERP or application. The final mapping may require local NAT, firewall or application logs.
Decision supported
The output should help an administrator decide which allowlist entries need more evidence before removal—not automatically remove access.
What this evidence can and cannot prove
Observed relay events prove which IPs Google logged using the relay—not every device behind NAT, and not “this IP is safe forever.” Configuration allowlists prove permission, not current usage.
If the message never appears in Google
This use case is about inventory, not one missing message. If a suspected application never generates relay events, the gap may mean it sends elsewhere (ESP, direct MX) and will stay invisible in Workspace relay telemetry until the path is confirmed.
How this differs from a point tool or a DMARC report
DMARC RUA shows domain authentication by source IP over time—useful to spot unexpected senders, but not a complete map of relay clients. Workspace operations tools may report broadly; this workflow focuses on relay evidence tied to ownership decisions. Compare DMARC aggregate platforms and Gmail logs in BigQuery.