How to Read Your Google DMARC Report — Gmail Aggregate Report Guide

If you run any domain that sends email, Google is already sending you a daily XML file detailing exactly how Gmail handled your mail. Most domain owners never open it. The ones who do can catch spoofing, fix deliverability problems, and confidently move to full email enforcement.

Why you are receiving emails from Google

When you publish a DMARC record for your domain, you include an rua= tag — the address where receiving mail servers should send aggregate reports. The format looks like this:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

Google honors this tag. Every day, Gmail sends a compressed XML file to your rua= address summarising every message it received that claimed to be from your domain in the previous 24 hours. The sender is noreply-dmarc-support@google.com.

What the Google DMARC email looks like

The email from Google arrives with a subject line in the format:

Report domain: yourdomain.com
Submitter: google.com
Report-ID: <17XXXXXXXXXXXXXXXXX>

The attachment is named in this format and is always compressed:

google.com!yourdomain.com!1751241600!1751327999.xml.gz

The filename encodes: the reporting organization (google.com), your domain (yourdomain.com), the Unix timestamp start and end of the reporting period, and the file extension. Decompress the .gz file to get the raw .xml inside.

Inside the XML: what Google reports

A Google DMARC XML file follows the standard DMARC aggregate report format (RFC 7489). Here is a real-world example of what it looks like:

<feedback>
  <report_metadata>
    <org_name>Google LLC</org_name>
    <email>noreply-dmarc-support@google.com</email>
    <report_id>17512345678901234</report_id>
    <date_range>
      <begin>1751241600</begin>
      <end>1751327999</end>
    </date_range>
  </report_metadata>

  <policy_published>
    <domain>yourdomain.com</domain>
    <adkim>r</adkim>
    <aspf>r</aspf>
    <p>none</p>
    <pct>100</pct>
  </policy_published>

  <record>
    <row>
      <source_ip>209.85.220.41</source_ip>
      <count>2847</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
    <auth_results>
      <dkim>
        <domain>yourdomain.com</domain>
        <selector>google</selector>
        <result>pass</result>
      </dkim>
      <spf>
        <domain>yourdomain.com</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
</feedback>

How to interpret the key fields

policy_published — your DMARC policy as Google saw it

The policy_published block is a snapshot of your DMARC DNS record at the time Gmail processed these messages. The critical fields:

• p: Your policy — none (monitoring only), quarantine (send to spam), or reject (block). If this says none, Google is reporting but not acting on failures.
• adkim / aspf: Alignment mode — r (relaxed) or s (strict). Most domains use r.
• pct: What percentage of failing messages the policy applies to. 100 means full enforcement.

source_ip — who is sending mail as you

The source_ip in each record is the outbound mail server that delivered the message to Gmail. Cross-reference this IP against your known senders:

count — how many messages this record represents

The count field tells you how many messages had this exact combination of source IP and authentication result during the day. Prioritize records with high counts — a failure with count=50,000 is far more urgent than one with count=3.

dkim and spf in policy_evaluated — your DMARC pass rate

These two fields are the bottom line of each record:

• dkim: pass — DKIM signature verified AND the signing domain aligned with your From: domain. This message passed DMARC via DKIM.
• spf: pass — SPF verified AND the envelope sender domain aligned with your From: domain. This message passed DMARC via SPF.
• If both are fail, the message failed DMARC entirely. With p=none this is just a report; with p=reject the message would be blocked.

Calculating your DMARC pass rate from a Google report

Your DMARC pass rate is: total messages where at least one of DKIM or SPF passes, divided by total messages. In mathematical terms:

pass_rate = (sum of count where dkim=pass OR spf=pass) 
            ÷ (sum of all count) × 100

To calculate this manually, sum the count from every record where policy_evaluated/dkim = pass or policy_evaluated/spf = pass. Divide by the total count across all records and multiply by 100.

Why is Google the most common DMARC report sender?

Gmail processes a larger volume of email than any other provider. If your domain sends newsletters, transactional emails, or business mail to users, the majority of recipients likely use Gmail. Google also has a well-maintained DMARC reporting infrastructure and sends reports reliably every 24 hours.

Other providers also send DMARC reports, including:

• Microsoft — reports from dmarcreport@microsoft.com
• Yahoo / AOL — reports from postmaster@dmarc.yahoo.com
• Apple — reports from postmaster@apple.com
• Many others — any provider that implements RFC 7489

Google typically accounts for 40–70% of the total message volume in most DMARC report sets, which is why it appears as the dominant sender.

What to do when your Google DMARC report shows failures

1. Identify the failing source IP. Look at records where dkim = fail AND spf = fail with high counts. These are your highest-priority failures.
2. Determine if the IP is a legitimate sender. Look up the IP in WHOIS or run it through the DMARC Labs analyzer, which enriches each IP automatically. If it belongs to an ESP you use (Mailchimp, HubSpot, etc.), fix their DKIM and SPF alignment. If it is unknown, it is likely spoofing.
3. Fix authentication for legitimate senders. For ESP failures, the most reliable fix is configuring DKIM signing with your own domain — most ESPs support this as a "custom domain" or "authenticated domain" setting.
4. Monitor for 2–4 weeks before tightening policy. Once your pass rate is consistently above 95%, move from p=none to p=quarantine, then to p=reject. Each step should include 2+ weeks of monitoring.

Google DMARC report FAQ

Why am I receiving emails from noreply-dmarc-support@google.com?

Your domain has a DMARC record with a rua= tag that includes your email address. Google is fulfilling its RFC 7489 obligation to send aggregate reports to that address. This is expected behavior — not spam.

How do I open a Google DMARC XML file?

Save the attachment, then decompress the .gz or .zip file. The XML inside can be read in a text editor, but it is easier to upload it directly to DMARC Labs, which accepts compressed files and renders the data as a table.

What is a good DMARC pass rate for Google reports?

Target 95%+ before moving to p=quarantine and 98%+ before p=reject. A rate below 90% signals misconfigured senders or active spoofing that needs investigation.

Google is my only report sender — is that normal?

If most of your recipients use Gmail, Google will dominate your reports. Other providers send reports too — check your spam folder, as report emails sometimes trigger spam filters, and verify that your rua= address is publicly accessible.

The fastest way to analyze your Google DMARC reports is to upload the attachment directly to DMARC Labs. Your file is processed in your browser — never sent to a server — and you get an instant breakdown of pass rates, source IPs, and authentication results.