Learn · DMARC report emails

DMARC report from google.com: what it is and what to do

A message from noreply-dmarc-support@google.com with the subject Report Domain: yourdomain.com Submitter: google.com and a ZIP attachment full of XML. It is a legitimate, automated DMARC aggregate report, and it is arriving because your domain asked Google to send it. Here's how to confirm that, read it, and stop it filling your inbox.

Is this email from Google real?

Yes, in the overwhelming majority of cases — and you can prove it rather than take anyone's word for it.

Google sends these from noreply-dmarc-support@google.com. The subject names your domain as the report domain and google.com as the submitter. There is no link to click, no login page, no invoice, and nothing to approve. The attachment is a compressed XML file and nothing else.

The definitive check takes a minute:

  1. Run your domain through the free DMARC checker. If the record shows a rua= address that matches the mailbox receiving these, the mail is expected and explained.
  2. Drop the attachment into the free DMARC report analyzer. It parses in your browser — nothing is uploaded — and a genuine Google report renders as a table of sending IPs with pass/fail results. A forgery won't parse.

If your domain publishes no DMARC record at all, be suspicious: there would be nothing for anyone to report on. In that case don't open the attachment, and check the full message headers before anything else.

Why Google is sending it to you

Someone published a DMARC record for your domain containing a rua=mailto: tag with your address. Google receives an enormous share of the world's email, so it sees mail claiming to be from your domain — yours and anyone else's — and once a day it summarises what it saw and mails you the tally.

Google is usually the first reporter to arrive and the highest-volume one for most domains, for the obvious reason: Gmail and Google Workspace are where a large fraction of your mail lands. If you've just published a record, expect the first Google report within roughly 24 to 48 hours.

Reading the filename before you open anything

The attachment name is not random. The DMARC specification fixes the format, so the filename alone tells you what's inside:

google.com!yourdomain.com!1755993600!1756079999.zip

Reading left to right: the reporting organisation, the domain the report is about, then the start and end of the reporting window as Unix timestamps. Those two numbers are exactly 24 hours apart on a normal daily report. Google compresses with ZIP; other reporters use gzip and end in .xml.gz.

This is useful for triage. If the second field isn't your domain, the report isn't about you. If the timestamps overlap a report you've already read, it's a duplicate rather than new information.

What's inside a Google report

Three sections. The metadata says google.com is reporting and gives the date range. The published policy echoes back the DMARC record Google actually resolved for your domain — worth checking, because it's a receiver's live view of your DNS. Then one block per sending IP address:

<record>
  <row>
    <source_ip>203.0.113.7</source_ip>
    <count>42</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim><spf>fail</spf>
    </policy_evaluated>
  </row>
</record>

That block says: this server sent 42 messages with your domain in the From address, DKIM aligned to you, SPF didn't, and because your policy is p=none Google delivered them anyway. The full field-by-field walk is in DMARC aggregate reports explained.

Two things Google's reports do not contain: message content and recipient addresses. Aggregate reports are counts and authentication verdicts only.

The one thing worth acting on

Look for sending IPs you don't recognise with a meaningful count. Every row is a server putting your domain in a From address. Some will be yours — your mail host, your invoicing tool, a marketing platform someone signed up for two years ago. Some will not be, and those are the reason DMARC exists.

An IP on its own is hard to judge, which is why the geolocation, network owner and threat flags behind a source IP matter more than the number itself. And if a sender you recognise is failing alignment, that's the thing to fix before you tighten your policy — enforcing while your own invoicing tool fails is how a rollout ends in an outage.

How to make the reports stop

Not by deleting the DMARC record. That stops the mail and simultaneously blinds you to everyone impersonating your domain — you'd keep every risk and throw away the only instrument that measures it.

Change the rua= address instead, so Google's daily report goes somewhere that reads it. A monitoring service parses every report, resolves each source IP to a named service, tracks alignment over time and tells you when something changes. Canny Pigeons does exactly that, free for one domain, hosted DMARC included — one DNS edit and the ZIP files stop arriving in your inbox for good.

In the meantime, the free DMARC report analyzer will read the one sitting in front of you right now.

Free checks: Report analyzer DMARC checker SPF checker DKIM checker

Getting reports from other providers too? Why am I getting DMARC report emails? covers the whole set.

Stop reading XML by hand

Point your rua at Canny Pigeons and get every report parsed into a dashboard — senders named, compliance tracked, free for one domain.

Start free