What an aggregate report contains
An aggregate report (the "rua" kind, as opposed to the rarely sent forensic "ruf" kind) is one XML file from one receiver covering one day. It has three parts:
| Section | Fields | What it tells you |
|---|---|---|
report_metadata | org_name, report_id, date_range | Which receiver wrote it and for which 24 hours. The report_id is what makes a duplicate a duplicate. |
policy_published | p, sp, adkim, aspf, pct | The DMARC record the receiver saw when it evaluated your mail. If it differs from what you think you published, DNS caching or a typo is the first suspect. |
record (repeated) | source_ip, count, disposition, dkim, spf, header_from, auth_results | One row per sending IP and result combination: how many messages, whether SPF and DKIM passed, whether they aligned, and what the receiver did with the mail. |
The rows are the useful part. A single day from one receiver can hold a handful of rows or several hundred, and a domain with normal traffic collects thirty to ninety files a month.
Pass, fail and the alignment trap
DMARC does not ask "did SPF pass?". It asks "did SPF pass for a domain that matches the visible From address?". That second condition is alignment, and it is where most confusion starts.
- SPF aligned: the envelope sender domain (Return-Path) is your domain or a subdomain of it, and the sending IP is in that domain's SPF record. Many services send with their own Return-Path, so SPF passes for their domain and still fails alignment for yours.
- DKIM aligned: the signature's d= domain is your domain and the signature verifies. This is the one that survives forwarding, and the one to fix first for third-party senders.
- DMARC pass: at least one of the two is aligned. Both failing is a DMARC fail, and the disposition column shows what the receiver did about it under your current policy.
Strict versus relaxed alignment (adkim and aspf set to s or r) decides whether a subdomain counts as a match. Relaxed is the default and the right choice until every sender is known.
Sorting the sources
Group the rows by source IP, add the counts, and look at the top of the list. Every source with real volume falls into one of three groups.
- Your own senders. Google Workspace or Microsoft 365, the newsletter tool, the CRM, the ticket system, the invoicing software, the website's contact form. Each has to pass with alignment. Where one fails, the fix is on your side: add the service to SPF, or better, set up its DKIM signing with your domain, which the service's documentation describes under "custom domain" or "domain authentication".
- Forwarders. Mailing lists and people who auto-forward their inbox to another provider. SPF breaks because the forwarder's IP is not in your record. DKIM keeps passing as long as the forwarder does not rewrite the message. These sources show a steady low volume with DKIM pass and SPF fail, and there is nothing to fix.
- Everyone else. Sources nobody in the company recognises, often from hosting ranges or consumer ISPs, with both checks failing. This is spam or phishing sent in your name. You cannot stop it at the source; your policy decides whether receivers accept it.
Reverse DNS and the WHOIS owner of the address help with naming a source, but the deciding question is always whether someone in the company can say what it is. A source that sends thousands of messages and nobody can explain is not "probably fine".
From none to reject without breaking your own mail
A new DMARC record starts with p=none, which changes nothing and only turns on the reports. The purpose of reading them is to reach p=reject safely.
- Collect two to four weeks of reports, so monthly senders such as invoicing runs appear at least once.
- Fix every legitimate source until the aligned pass rate of your own traffic is at or near 100 percent.
- Change to p=quarantine with pct=10. Only a tenth of failing mail is affected, and a sender you forgot shows up as a complaint rather than as a disaster.
- Raise pct to 100, then switch to p=reject. Keep the rua address and keep reading; new services get added by colleagues without telling IT.
Set sp= explicitly if subdomains should follow a different policy, and remember that p=reject on a domain that sends no mail at all is the correct setting and needs no monitoring period.
Reading the files without forwarding them anywhere
Most monitoring services want you to change the rua address so the reports flow to them. That is convenient, and it also means a third party receives a daily list of every system that sends mail for your company. For a one-off review, or when the reports may not leave the organisation, the files can be read locally instead.
The DMARC Aggregate Report Analyzer takes the XML, gzipped XML or ZIP attachments as they arrive, up to 64 files per batch, and produces the source list described above: messages per source, SPF and DKIM results with alignment, the published policy as receivers saw it, and the sources that fail repeatedly at the top. Duplicate report IDs are dropped so a report you saved twice does not double the counts. It does no DNS lookups and has no access to the mailbox, works only on the upload, and deletes the result after 24 hours. Three batches a day are free and need no account. The output is an HTML summary, an XLSX and CSV of the rows, and the normalised JSON in case you want to keep your own history.
DMARC report FAQ
Why am I getting DMARC report emails every day?
Your DMARC record contains a rua= address. Every receiver that handles mail from your domain sends one compressed XML file per day to it. The reports are meant for software, not for people, which is why they look like noise in an inbox.
What does a DMARC fail in the report mean?
A row where neither SPF nor DKIM produced an aligned pass. Either the source is not authorised for your domain, or it is authorised but signs or sends with a different domain than the visible From. Forwarded mail fails SPF by design and should still pass DKIM.
When is it safe to change from p=none to p=reject?
When every source with real volume passes with alignment for at least two to four weeks. Go through quarantine with a low pct first so a forgotten sender affects a fraction of mail rather than all of it.
Do I have to forward my reports to a service to read them?
No. The XML can be read locally. The analyzer above works on an upload only, without DNS lookups or mailbox access, and deletes the result after 24 hours.
Drop this month's reports in and see who is sending as your domain
XML, XML.GZ or ZIP as they arrived. Duplicates are removed, sources are ranked by volume, nothing is stored beyond 24 hours.
Open the DMARC Aggregate Report Analyzer