PunchOp
Menu
Use casesGuidesCompareGlossaryNewsMethodParticipateJoin inspector beta →Submit a difficulty →
FR
Participate
Join inspector betaSubmit a difficulty
Use caseOct 10, 2026Checked Oct 10, 2026

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.

Observed difficulty

An admin configured _dmarc with an rua= address and now receives daily or weekly ZIP files. Opening the XML shows spf: fail next to dkim: pass and disposition: none. The first reaction is often “something is broken” or “someone is spoofing us”—even when users report no delivery problems.

What is established (official sources)

  • DMARC aggregate reports (RUA) are expected feedback when rua= is present in DNS (RFC 7489, Google DMARC reports).
  • Gmail summarizes authentication results; SPF fail at policy_evaluated can coexist with DMARC pass when DKIM aligns with the visible From domain.
  • Aggregate files do not prove a specific user-visible incident; they are statistics for a time window.

How PunchOp would structure the response

  1. Confirm the ZIP naming pattern matches an aggregate RUA (reporting-org!domain!timestamps).
  2. Read policy_published against the live _dmarc TXT record.
  3. For each suspicious record, list source IP, count, DKIM/SPF evaluated results, and envelope vs header domains in auth_results.
  4. Classify each row: authorized ESP, internal relay, or unknown source (needs blocklist / investigation).
  5. Correlate unknown sources with SMTP relay or application logs—not with guesswork from XML alone.
  6. Document whether any row triggered disposition other than none for mail the organization cares about.

See the step-by-step guide: DMARC aggregate report (RUA).

Limits

  • PunchOp has not run this workflow as a product feature; this page is a method for a common admin question, not a measured case study on your domain.
  • RUA alone cannot replace message-level traces (Email Log Search, relay logs, ESP dashboards).
  • Promoting p=reject without reviewing all legitimate senders can block real mail—policy changes belong in a controlled change window.

What this evidence can and cannot prove

The ZIP proves Gmail sent an aggregate authentication summary for your domain—not that a specific user lost mail. SPF fail lines in XML often reflect envelope misalignment while DKIM still passes; that pattern alone is not proof of abuse.

If the message never appears in Google

Administrators sometimes open RUA because of a delivery worry. RUA will not locate one missing relay send; pivot to Email Log Search or application SMTP evidence when the symptom is message-level.

How this differs from a point tool or a DMARC report

You already hold a DMARC aggregate report—distinct from SMTP and header point tools and from dmarcian-style monitoring that tracks trends across many files. PunchOp’s role would be to tie RUA rows to operational next checks, not to replace DNS or Google’s report format.