Analyzing Gmail DMARC Aggregate Feedback Reports Effectively

Analyzing Gmail DMARC reports is essential for monitoring your domain's email authentication health, preventing spoofing, and ensuring your legitimate messages reach the inbox. Google sends daily XML aggregate reports (RUA) to domain owners who publish a valid DMARC record, detailing every message claiming to come from your domain. Because these reports arrive as compressed XML files packed with IP addresses and authentication results, making sense of them can initially feel overwhelming.

To jumpstart your DMARC journey or update your policy securely, you can use the DMARC Record Generator tool to build syntax-valid DNS records complete with reporting URIs.

Understanding the Anatomy of a Gmail DMARC Report

When Google processes email claiming to originate from your domain (such as example.com), it generates an XML file once per day. This file contains metadata about the report sender, your domain policy, and a detailed record of all traffic observed during that 24-hour window.

Report Metadata and Policy Sections

Every Gmail DMARC report begins with standard metadata that identifies who sent the report and which domain it covers. Here is a simplified snippet of what you will see:

<feedback>
  <report_metadata>
    <org_name>Google.com</org_name>
    <email>noreply-dmarc-support@google.com</email>
    <extra_contact_info>https://support.google.com/mail/answer/2451690</extra_contact_info>
    <report_id>12345678901234567890</report_id>
    <date_range>
      <begin>1700000000</begin>
      <end>1700086400</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>example.com</domain>
    <adkim>r</adkim>
    <aspf>r</aspf>
    <p>none</p>
    <sp>none</sp>
    <pct>100</pct>
  </policy_published>
</feedback>

• org_name: Identifies the reporting organization (in this case, Google).
• policy_published: Shows the DMARC policy settings active on your domain (example.com) at the time the emails were processed. Pay close attention to <p>, which shows your policy level (none, quarantine, or reject).

The Record Section (Traffic Data)

The core of the report is found within the <record> blocks. Each block aggregates traffic sharing the same source IP, evaluation results, and policy outcome.

<record>
  <row>
    <source_ip>192.0.2.1</source_ip>
    <count>150</count>
    <policy_evaluated>
      <spf>fail</spf>
      <dkim>pass</dkim>
      <disposition>none</disposition>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>example.com</header_from>
  </identifiers>
  <auth_results>
    <spf>
      <domain>mail.example.com</domain>
      <result>fail</result>
    </spf>
    <dkim>
      <domain>example.com</domain>
      <result>pass</result>
    </dkim>
  </auth_results>
</record>

• source_ip: The IP address sending the mail (e.g., 192.0.2.1).
• count: The number of messages sent from this IP during the reporting period.
• policy_evaluated: How DMARC evaluated the message based on SPF and DKIM results.
• auth_results: The granular pass/fail status of SPF and DKIM checks independently.

Step-by-Step Guide to Reading and Processing Reports

Because Gmail sends reports as gzip-compressed XML files, you cannot read them directly in a standard email client without decoding them first. Follow these steps to manually extract and review your logs.

Step 1: Extract and View the XML Files

When your monitoring mailbox receives a report, save the attachment locally. It will typically end in .xml.gz.

On a Unix-like system or PowerShell, extract the file using standard command-line tools:

gunzip dmarc-report-example.com-to-google.com-1700000000.xml.gz

Once unzipped, you can open the resulting .xml file in any modern text editor or web browser, or parse it using command-line processors like xmllint or python scripts.

Step 2: Identify Legitimate Services vs. Spoofers

Scan the source_ip entries and count values. Group your findings into three distinct categories:

1. Your Primary Infrastructure: Mail servers, corporate Google Workspace or Microsoft 365 accounts, and self-hosted MTAs.
2. Third-Party Vendors: CRM platforms, marketing tools, and ticketing systems sending email on your behalf (e.g., Salesforce, Zendesk, Mailchimp).
3. Unauthorized Senders: Unknown IP addresses attempting to spoof your domain name.

Step 3: Verify SPF and DKIM Alignment

A DMARC pass requires at least one underlying authentication mechanism (SPF or DKIM) to both pass technical validation and achieve "alignment" with your header From: domain.

• SPF Alignment: The domain in the MAIL FROM (envelope sender) address must match or be a subdomain of the header From: domain.
• DKIM Alignment: The domain found in the d= tag of the DKIM signature must match your header From: domain.

Evaluating Common Scenarios in Gmail Reports

Scenario	SPF Result	DKIM Result	DMARC Status	Likely Cause / Action Needed
Standard Outbound	Pass	Pass	Pass	Fully authenticated. Safe for policy strictness.
Forwarded Email	Fail	Pass	Pass	Normal behavior for forwards. SPF fails because the forwarder changes the IP, but DKIM survives.
Third-Party Tool	Fail	Fail	Fail	Missing SPF inclusion or missing CNAME/TXT DKIM setup for the vendor.
Malicious Spoofing	Fail	Fail	Fail	Unauthenticated spammer using your domain name. Blocked or monitored.

Common Mistakes When Analyzing DMARC Reports

• Panicking Over SPF Failures on Forwarded Mail: Email forwarding breaks SPF because the intermediate server relays the message from a new IP address. As long as DKIM passes and aligns, the overall DMARC evaluation will pass. Do not fix what isn't broken.
• Moving to p=reject Too Quickly: Skipping the p=none monitoring phase often blocks legitimate newsletters or vendor emails that have misconfigured alignments.
• Ignoring IPv6 Blocks: Ensure your analysis includes both IPv4 (192.0.2.0/24) and IPv6 (2001:db8::/32) address blocks, as Google heavily utilizes IPv6 for mail delivery.
• Parsing Manually at Scale: Relying solely on text editors for high-volume domains leads to missed insights. Use log parsers or visualization tools once your volume exceeds a few thousand messages daily.

DMARC Analysis Checklist

• Set up a dedicated reporting email address (dmarc@example.com) distinct from personal inboxes.
• Publish an initial DMARC record with p=none using the DMARC generator.
• Collect Gmail aggregate reports for a minimum of 14 days to capture weekly mailing patterns.
• Unzip and parse XML reports to inventory all sending IP addresses.
• Ensure all third-party senders have valid SPF includes and custom DKIM signing keys.
• Gradually transition your policy from p=none to p=quarantine, and finally to p=reject once 100% compliance is verified.