Reading DMARC aggregate reports

Once your DMARC record has a rua= address, every large receiver sends you one report a day per domain. Each is a zipped XML file that lists, for every IP address that sent mail claiming to be from your domain, how many messages arrived and whether they passed SPF and DKIM with alignment. Nobody reads these by hand for long; the point of this article is to know what you are looking at when a tool shows you the summary.

The shape of a report

report_metadata    who sent it (google.com), the period (one day, UTC), a report id
policy_published   the DMARC record the receiver saw: p, sp, pct, adkim, aspf
record             one per source IP:
  row              source_ip, count, disposition applied, dkim and spf alignment results
  identifiers      the From: domain the recipients saw
  auth_results     the raw SPF and DKIM checks, with the domains and selectors involved

Alignment is the part that matters. A message can pass SPF for bounces.newsletter-tool.com and still fail DMARC, because that domain is not yours. DMARC only counts a pass when the SPF domain or the DKIM d= domain matches the From: domain (exactly in strict mode, or sharing the organisational domain in relaxed mode).

Sorting the sources

Every source falls into one of three groups.

1. Yours and passing. Your mail server, your newsletter service with DKIM set up, your helpdesk. Leave them alone.
2. Yours and failing. A service you use that signs with its own domain or is missing from your SPF. The fix is on their side of the setup page: add their DKIM CNAMEs so the d= becomes your domain, or add their include to SPF. Forwarded mail also lands here, and SPF will never pass for it; only DKIM survives forwarding, which is why DKIM on everything comes first.
3. Not yours. Addresses you do not recognise, often at hosting providers or residential ranges, usually with zero passes. That is the spoofing DMARC exists to stop. You do not fix these; you tighten the policy so receivers discard them.

Reverse DNS and the provider name beside each IP make the sorting quick. A source with a .mail.protection.outlook.com name is a Microsoft 365 tenant; mail-sor-f41.google.com is Gmail; a bare VPS name with 400 failing messages is a spammer.

When to tighten

Move from p=none to p=quarantine when, for two to four weeks, every source you recognise passes and the failures are all in group three. Use pct=25 first if you are nervous, and keep reading the reports: the quarantined and rejected counts tell you the policy is biting. Move to p=reject when quarantine has run for a few weeks without complaints from real correspondents.

Numbers that mislead

• Pass rate below 100% is normal. Mailing lists, forwarders and out-of-office replies on other systems will fail forever. Judge by source, not by the overall figure.
• A huge count from one IP is usually a receiver re-sending a bounce storm or a list-serv, not an attack. Look at the From: domain and the dates.
• Disposition does not match your policy when a receiver overrides it (Gmail honours p=quarantine by junking, Microsoft may deliver with a warning) or when pct is below 100.
• Reports stop arriving when the record changes and the new rua domain has not authorised yours, or when the mailbox bounces. Check the record with the DMARC checker; it tests the authorisation record for external addresses.

Doing it automatically

Verified owners can send reports straight to whois.me.uk: add rua=mailto:dmarc@whois.me.uk and the dashboard aggregates every receiver's reports per source, with the sorting above done for you and findings that say when you are ready to tighten. For a handful of old files, the report analyser reads them once without storing anything.