How to read DMARC aggregate reports
DMARC aggregate reports are XML files from Gmail, Microsoft, Yahoo and others telling you who sent mail using your domain and whether it passed. Read properly, they show you every forgotten sender and every spoofing attempt. Here is how to read one.
Reviewed by the ITRS security team · Last updated
What aggregate reports contain
When your DMARC record includes a rua= address, receiving mail providers send you aggregate reports, usually once a day, as compressed XML attachments. RFC 7489 defines the format. Each report covers one reporting organization, one domain and one time window. It doesn't contain message content or subject lines; it contains counts grouped by sending IP address and authentication result.
The main elements, in the order they appear:
| XML element | What it tells you |
|---|---|
report_metadata | Who sent the report (for example google.com), report ID and the date range covered |
policy_published | Your DMARC record as the receiver saw it: domain, adkim, aspf, p, sp, pct |
record > row > source_ip | The IP address that sent the mail |
record > row > count | How many messages from that IP in this window |
record > row > policy_evaluated | The disposition applied (none, quarantine, reject) and the DMARC-level dkim and spf results, which include alignment |
record > identifiers | header_from (the visible From domain) and, from some reporters, envelope_from |
record > auth_results | The raw DKIM result with the signing domain (d=) and the raw SPF result with the domain checked |
Identifying legitimate senders
Group by source IP and look it up
Reverse DNS and IP ownership usually reveal the service: Microsoft's outbound protection ranges, Google's mail servers, Mailchimp, Salesforce, your payroll provider.
Match against your sender inventory
Every service on your list should appear. Anything you recognize but hadn't listed goes on the list now.
Check the auth_results domains
A legitimate service signing with its own domain (d=vendor-mail.com) rather than yours will pass DKIM but fail alignment. That sender needs custom DKIM set up with your domain.
Look at volume and timing
Regular volumes from a known provider are business as usual. A provider you recognize sending suddenly large volumes deserves a question to the department that owns it.
Spotting spoofing
Spoofing in aggregate reports usually looks like this:
- Source IPs from residential ISPs, hosting providers or countries you don't do business in.
- Both SPF and DKIM failing, with no DKIM signature at all or one from an unrelated domain.
- Bursts of volume over a day or two, then nothing.
- Your domain, or a subdomain you don't use, in header_from with no business reason.
Alignment failures and fixes
| Pattern in the report | Likely cause | Fix |
|---|---|---|
SPF pass in auth_results, spf fail in policy_evaluated | Service uses its own bounce (envelope) domain | Rely on DKIM with your domain, or set a custom return-path domain if the service supports it |
DKIM pass for vendor domain, dkim fail in policy_evaluated | Service signs with its own domain | Set up custom DKIM with your domain (CNAME or TXT records the vendor provides) |
SPF permerror | SPF record exceeds 10 DNS lookups (RFC 7208) or has a syntax error | Remove unused includes; move bulk senders to subdomains |
Legitimate IP, both fail, small counts, varied receivers | Mail forwarded by a recipient's system or a mailing list | Usually acceptable; DKIM aligned at the original sender survives most forwarding |
Microsoft 365 or Google Workspace itself failing DKIM | Custom-domain DKIM never enabled on the tenant | Enable DKIM signing for your domain in the admin centre |
Tools and report processing
A small domain might get a handful of reports a day; a busy one can get dozens. Reading raw XML is fine for learning, not for routine work. Google's DMARC documentation suggests that if you receive many reports, a third-party DMARC service can collect, store and analyze them, and otherwise recommends a dedicated group or mailbox for them rather than a person's inbox.
When choosing a service, check where report data is stored (reports contain IP addresses and counts, not message content, but some services also handle failure reports, which can contain more), whether it can group sources by provider automatically, whether it alerts on new failing sources, and whether you can export data if you leave.
Point rua at an address on your own domain, or at the service's address. If the reporting address is on a different domain, RFC 7489 requires that domain to publish a record authorizing it to receive your reports.
Ongoing review
Sources: RFC 7489 (DMARC), including the aggregate report XML schema and external destination verification (section 7.1); RFC 7208 (SPF); Google Workspace 'Set up DMARC' and 'DMARC reports' help articles; M3AAWG Email Authentication Recommended Best Practices.
- During rollout (p=none and quarantine ramp): review weekly.
- At p=reject: review monthly, plus whenever a department adds a new email tool.
- Track three things: legitimate sources failing (fix them), new unknown sources (investigate), and spoofing volume (proof the policy is working, useful for leadership and insurers).
- Keep a copy of reports for at least a year. If your domain is used in fraud against a client, they help show what was sent and that your policy was in force.
Related reading.
- PracticeManaged IT SupportHelpdesk and break/fix, networking, security systems, devices, Microsoft 365, cloud and backup.
- GuideRolling out DMARC from p=none to p=rejectPublishing a DMARC record is easy. Getting to p=reject without blocking your own invoices, newsletters and payroll notices takes an inventory, some careful DNS work and…
- ArticleIs Your Company Email Easy to Spoof? SPF, DKIM & DMARC ExplainedMost small businesses have never checked whether criminals can send email as their domain. A plain-English guide to SPF, DKIM, and DMARC, and how to close the gap.
- ArticleManaged Email Services in Vaughan and the GTA: What Managed Business Email Should IncludeA managed email service is more than a Microsoft 365 licence. What belongs in it, authentication, backup, continuity, monitoring, and how to compare providers.
Want this handled for your business?
Tell us your users, devices and sites. We are staffed 24/7 and reply with next steps. Quotes are built from your environment, not a price list. Active incident? Call (289) 582-9930, 24/7.