DMARC aggregate report (RUA): read the google.com!domain.zip file

Administrators sometimes receive a ZIP attachment named like google.com!yourdomain.com!1739059200!1739145599.zip from noreply-dmarc-support@google.com. That file is not malware and not a user complaint—it is a DMARC aggregate report (RUA) summarizing how Gmail handled messages that claimed to be from your domain.

What DMARC is checking

DMARC asks a narrow question for each message: did SPF or DKIM pass with alignment to the domain visible in the From: header (the organizational domain)?

• SPF (DMARC view): the envelope MAIL FROM domain must authorize the sending IP and align with the header From domain (strict or relaxed, per your _dmarc tags).
• DKIM: a valid signature must align with the header From domain.

If either passes with alignment, DMARC passes. Your published policy (p=none, quarantine, or reject) then tells receivers what to do when DMARC fails—not when it passes.

Decode the ZIP filename

Google and many receivers use this pattern:

<reporting-org>!<policy-domain>!<begin-unix>!<end-unix>.zip

Inside the ZIP you will find an XML file with the same basename. You do not need to open it manually forever—DMARC monitoring tools ingest these files—but reading one report once builds intuition.

Inside the XML: three blocks that matter

1. policy_published — what your public _dmarc record said at evaluation time (p=, sp=, pct=, alignment mode).
2. record → row — volume from a source IP, and policy_evaluated (dkim, spf, disposition).
3. auth_results — raw SPF/DKIM outcomes (which domain was checked for each protocol).

Important: SPF can pass for the ESP’s envelope domain while policy_evaluated → spf is fail because the envelope domain does not align with From: yourdomain.com. That is common when marketing or transactional mail uses a provider’s MAIL FROM (for example a sender subdomain) while DKIM signs your domain.

Worked example: SPF fail, DKIM pass, disposition none

A typical legitimate ESP send looks like this in aggregate data:

• header_from: your domain
• auth_results → DKIM pass on your domain (selector such as mail or s1)
• auth_results → SPF pass on the provider’s envelope domain
• policy_evaluated → spf: fail, dkim: pass
• disposition: none (message was not quarantined because DMARC still passed via DKIM)

That pattern is not, by itself, proof of spoofing. It usually means: “mail signed as you, sent through a third party whose envelope domain does not align.”

When this becomes a real difficulty (incident signal)

Treat the report as an investigation lead when you see combined signals such as:

• DKIM fail and SPF fail for mail claiming your domain, from IPs you do not recognize;
• sudden volume spikes from new sources after you did not onboard a new sender;
• disposition quarantine or reject on messages you believe are production traffic;
• your policy is p=quarantine or p=reject and legitimate mail starts failing DMARC after a DNS or ESP change.

The next checks are operational, not XML trivia: confirm authorized senders in SPF, confirm DKIM selectors at the ESP, compare source IPs to known relays, and correlate with SMTP or provider logs for the same window.

What this evidence can and cannot prove

RUA XML proves how receivers evaluated SPF/DKIM alignment for traffic claiming your domain in the report window. It does not prove a specific message was delivered, read, or quarantined for one user. disposition: none with DMARC pass means the receiver did not apply your failure policy to that aggregate row—not “every message in the row reached the inbox.”

If the message never appears in Google

DMARC aggregate data will not list individual Message-IDs from Gmail’s RUA. If the incident is “one relay send missing in Email Log Search,” RUA is supporting context (unexpected sources, auth failures), not a substitute for Workspace or application logs for that send.

How this differs from a point tool or a DMARC report

This file is a DMARC aggregate report—distinct from message-level traces (Email Log Search, relay logs, ESP dashboards) and from header-only analyzers on a single .eml. Platforms such as dmarcian or Valimail ingest and visualize many RUA files; they do not by themselves reconstruct one application relay failure. See DMARC aggregate platforms and Email Log Search.

Limits

• Aggregate RUA reports do not include message bodies, subjects, or recipients—only statistics and authentication results.
• This guide describes Gmail’s aggregate format; Microsoft, Yahoo, and others send their own RUA files with the same RFC concepts but different tooling.
• PunchOp has not measured your domain; examples follow public RFC and Google documentation, not a claim about your production mail.
• A single day with SPF misalignment and DKIM pass is often expected for ESP sending; do not treat it as an automatic security incident without corroborating evidence.