How to read DMARC aggregate reports (and what to fix before you tighten)

What arrives, and why

Aggregate reports are what the rua tag in your DMARC record asks for. A record like v=DMARC1; p=none; rua=mailto:dmarc@yourdomain tells every receiver that supports DMARC reporting to send a daily summary of the mail it saw claiming to be from your domain. Each receiving organisation sends its own report, usually once a day. Microsoft describes them as arriving about once per day as an XML attachment that is likely GZIP compressed. A small domain gets a handful a day; Google notes that large organisations can get hundreds or thousands.

Two practical points. Send reports to a dedicated mailbox or group, not a person's inbox; Google recommends the same. And if the rua address is on a different domain from the one being reported on (a report service, or your parent company's domain), that other domain has to publish a small authorisation record: a TXT record at yourdomain._report._dmarc.otherdomain containing v=DMARC1. Without it, many receivers won't send reports there.

Aggregate reports contain no message content and no recipient addresses. They are counts: this IP sent this many messages as your domain, and this is how they fared.

The four parts of a report

Open the XML (unzip it first) and you will find the same structure every time.

The report metadata comes first: which organisation sent the report (org_name, for example google.com), a contact address, a report ID, and the date range. The dates are Unix timestamps in seconds, in UTC. A begin value of 1335571200 is 28 April 2012 at midnight UTC; any epoch converter will translate them.

Next is the published policy: what the receiver found in your DMARC record when it checked. The domain, the policy (p), the subdomain policy (sp), and the alignment modes for DKIM and SPF (adkim and aspf, r for relaxed or s for strict). Compare this with what you think you published. A typo or an old record shows up here.

Then come the records, one per sending source. Each has a row with the source IP, a count of messages, and the policy evaluated for them: the disposition the receiver applied (none, quarantine or reject) and the DMARC result for DKIM and for SPF. Below the row, identifiers give the header_from domain (the domain in the From: line), and auth results give the raw SPF and DKIM checks, each with the domain that was checked and the result.

That is all a report is: metadata, your policy as seen from outside, and a list of sources with counts and results.

The one distinction that matters: policy_evaluated versus auth_results

Every record has DKIM and SPF results in two places, and they often disagree. That isn't a bug. It is the most useful thing in the report.

The auth_results section is the raw check. SPF pass for bounces.newsletter-tool.com means the IP was allowed to send for newsletter-tool.com. DKIM pass for newsletter-tool.com means the message carried a valid signature from newsletter-tool.com.

The policy_evaluated section is the DMARC verdict. It only says pass if the check passed for a domain that aligns with your From: domain. In the example above, both raw checks pass, but neither is for your domain, so policy_evaluated shows fail for both, and the message fails DMARC.

So when you read a row, ask two questions. Did SPF or DKIM pass at all (auth_results)? And did either pass for my domain (policy_evaluated)? Most problems you will find are senders where the first answer is yes and the second is no.

Reading one row, step by step

Take a record with source IP 203.0.113.25 (a documentation address, used here as an example), a count of 1,240, disposition none, policy_evaluated DKIM fail and SPF pass, header_from yourshop.dk, DKIM auth result pass for mailer-platform.example, and SPF auth result pass for yourshop.dk.

Read it like this. 1,240 messages claimed to be from yourshop.dk. They came from one IP. SPF passed, and for your own domain, so SPF is aligned and the messages pass DMARC on SPF alone. DKIM passed too, but the signature was the platform's, not yours, so it doesn't count for DMARC. The receiver applied no action (disposition none): the messages passed, and your policy is p=none anyway.

Is that fine? Today, yes. But this sender rests on SPF only, and SPF breaks when mail is forwarded. The fix is to turn on DKIM signing with your own domain in that platform. Then both methods align, and the messages keep passing DMARC even when someone forwards them.

Forgotten sender or spoofing?

This is the question the reports exist to answer. A few signals separate the two.

A forgotten legitimate sender usually comes from a recognisable provider. Look up the IP: reverse DNS or WHOIS will often name a mail platform, a newsletter tool, a CRM or a hosting company. Its volume is steady from day to day and rises when you send campaigns or invoices. Its raw checks usually pass, just for the wrong domain: DKIM signed by the provider, SPF passing for the provider's bounce domain. That pattern, pass in auth_results and fail in policy_evaluated, is the fingerprint of a service you use but never set up with your domain.

Spoofing looks different. The IPs sit in networks with no connection to you, often residential or hosting ranges in countries you don't send from. Volumes are irregular: bursts of a few hundred, then nothing. Both raw checks fail, or there is no DKIM signature at all, or a signature from a domain that has nothing to do with you. Nobody in your organisation recognises the source. That is exactly the mail p=reject is designed to stop.

Then there is a third group that trips people up: forwarding and mailing lists. Mail you sent legitimately gets passed on by another server. SPF fails, because the forwarding server isn't yours, but your DKIM signature often survives, so DMARC still passes. Mailing lists that rewrite the subject or footer can break DKIM as well. Some receivers mark this in the report with a policy override reason such as forwarded or mailing_list. A small, scattered volume of SPF failures from big mailbox providers is usually this, not an attack, and it is the main reason aligned DKIM matters more than SPF.

Microsoft 365 and Google Workspace: the usual first findings

If you run Microsoft 365, check DKIM for your custom domain first. Microsoft's documentation says that mail from custom domains isn't DKIM signed with your domain until you configure it, which takes two CNAME records (selector1 and selector2) and a switch in the Defender portal. Until then, your own Exchange Online mail relies on SPF alone for DMARC, and every forwarded message fails. Microsoft also recommends sending bulk mail from services you don't control from a subdomain, such as marketing.yourdomain, so their reputation doesn't affect your main domain.

If you run Google Workspace, the same applies: until you generate a DKIM key in the Admin console and publish it, Google signs your mail with a Google default domain rather than yours, so DKIM doesn't align.

After that, the typical list of forgotten senders looks the same in most organisations: the newsletter tool, the webshop or booking platform, the invoicing or accounting system, the CRM, the helpdesk, a website contact form, and the multifunction printer that e-mails scans. Each one needs DKIM with your domain, or at least an SPF entry with an aligned return-path.

What to fix before you tighten

Moving from p=none to p=quarantine, and later to p=reject, asks receivers to act on failing mail. Before you do, the reports should show four things.

Every legitimate source passes DMARC, ideally with aligned DKIM, not just SPF. Go through the sources by volume and account for each one, until what remains is only mail you don't recognise.

SPF stays under 10 DNS lookups, so adding a sender doesn't break SPF for everyone. Check it with the free SPF Surveyor at monitordmarc.eu/tools/spf-surveyor.

Subdomains and parked domains are covered. The sp tag sets the policy for subdomains; domains you own but don't send from should have their own DMARC record with p=reject, so they can't be used for spoofing either.

The results are stable over time, not for one good day. Invoicing runs monthly, some tools send quarterly, and a sender you only see at month-end can disappear from a week of reports.

Then take the steps one at a time: none, then quarantine, then reject, watching the reports after each change. If a legitimate sender starts failing after a step, fix the sender rather than reverting by reflex.

There is no fixed timeline for this. A busy domain gathers evidence quickly; a domain that sends a few dozen messages a day takes much longer, because there is simply less data to judge from.

Reading reports without reading XML

You can do all of the above by hand, and for one domain with a few sources it is a good way to learn. Microsoft's own DMARC guide offers two routes: build your own processing with PowerShell or Power BI, or use a reporting service, which Microsoft says makes it "easier to view and interpret DMARC results". Google's help page also lists a third-party report service as the recommended option.

For a single report, the free XML-to-Human tool at monitordmarc.eu/tools/xml-to-human turns the file into a readable table and shows the names of the sending sources, not just the IP addresses. No account needed.

For ongoing monitoring, MonitorBase receives your reports, reads them for you and shows each sending source with its results, from €16/month ex. VAT on the Basic plan; Pro (€45/month ex. VAT, 10 domains) has a 30-day trial with a payment card. From Basic up, the app shows a "Next policy step" for each DMARC domain. It recommends moving to the next policy only once the domain has 500 or more messages over at least 14 days of reports, with at least 98% passing (99% for the later steps). Until then it says it is still collecting data, and for a quiet domain that can take a while. It recommends the next step; you change your DNS record yourself. All data is stored and processed in Paris, with no US sub-processors.

Try it on your own report

Take yesterday's report from your DMARC mailbox, unzip it and paste it into XML-to-Human at monitordmarc.eu/tools/xml-to-human. Within a minute you will know who sends as your domain.

Sources

Google, About DMARC reports, support.google.com/a/answer/10032472 (accessed 20 October 2026; page updated 13 October 2026): report frequency, volume for large organisations, dedicated mailbox, recommended third-party service, external report address authorisation, and the sample XML structure.

Microsoft Learn, Set up DMARC to validate the From address domain for cloud senders, learn.microsoft.com/en-us/defender-office-365/email-authentication-dmarc-configure (updated July 2026, accessed 20 October 2026): report frequency and format, and the two options for processing reports.

Microsoft Learn, Set up DKIM to sign mail from your Microsoft 365 domain, learn.microsoft.com/en-us/defender-office-365/email-authentication-dkim-configure (updated 3 July 2026, accessed 20 October 2026): DKIM for custom domains, selector1/selector2 CNAME records, subdomains for bulk senders.

Google Workspace Admin Help, Set up DKIM, support.google.com/a/answer/180504 (accessed 20 October 2026).

RFC 7489, Domain-based Message Authentication, Reporting, and Conformance (DMARC), rfc-editor.org/rfc/rfc7489: aggregate report format and policy override reasons. DMARC was updated by RFC 9989 to 9991 in May 2026 (dmarc.org, accessed 20 October 2026).

Free tools that help

• XML-to-Human Converter: Paste or upload a DMARC aggregate report and read it as a table with named sources.
• SPF Surveyor: Visualize the full SPF include tree and count DNS lookups against the limit of 10.