You started receiving DMARC aggregate reports — gzipped XML attachments from Google, Microsoft, Yahoo and others — and the raw XML is unreadable.
A DMARC aggregate report is an XML document with three parts: <report_metadata> (who generated it and the report ID), <policy_published> (the DMARC policy that receiver saw for your domain), and one <record> per source IP — each with a message count and the SPF, DKIM and DMARC results for that source. The <date_range> begin/end are Unix epoch timestamps you have to convert to real dates. The schema is defined in the DMARC standard: aggregate reporting is now its own document, RFC 9990 (it was previously part of RFC 7489 §7.2). Source: RFC 9990 — DMARC Aggregate Reporting (RFC Editor) · verified 2026-07-18.
<policy_published> first — it shows the p=, sp= and alignment the receiver applied, which tells you what they think your policy is.<record>, match the source_ip to a sending service and check whether SPF and DKIM passed and aligned — a source that fails both is either a broken legitimate sender or a spoofer.<date_range> epoch numbers to dates so you know which week the data covers.It's about your domain's authentication, not the recipient's mailbox. A “5.7.1 rejected due to DMARC policy” message means your own From domain failed DMARC and publishes an enforcing policy — so the fix is on your DNS and sending configuration, not the recipient's side.
You can open one by hand — they're just XML — but they're designed to be machine-read. A monitoring tool that names each source IP in plain English and tracks pass rates over time is what makes them useful week to week, instead of decoding gzip XML every day.
DNS changes propagate within a few hours (up to 48h). For anything you diagnose from aggregate reports, new reports arrive daily, so allow a day or two to confirm a source now passes and aligns.