Key takeaways

  • Aggregate reports are defined in RFC 7489. A receiver sends one XML file, usually compressed, per reporting period, commonly a day, that groups messages by sending IP address with counts.
  • The three parts to read are the report metadata, the published policy the receiver saw, and one record per sending source with the evaluated result and the raw authentication results.
  • DMARC passes when SPF or DKIM passes and the domain it authenticated aligns with the visible From domain. A raw SPF or DKIM pass that does not align is not enough.
  • The evaluated result lives in the policy_evaluated element. The raw results live in auth_results. When they disagree, alignment is almost always the reason.
  • Unknown senders are usually one of four things: a service you forgot, a forwarder, a mailing list, or someone spoofing you. Group by IP address owner and by header From domain before deciding.
  • Forwarding often breaks SPF, and mailing lists often break DKIM. RFC 8617, the Authenticated Received Chain (ARC), lets intermediaries record the original result. Receivers decide whether to trust it, so do not count on it.

What an aggregate report is

When you publish a DMARC record with an rua address, mailbox providers that support the feature send a summary of what they received claiming to be from your domain. The format is in an appendix of RFC 7489. Reports arrive as email attachments, often zipped or gzipped. Providers differ in how often and how fully they report, so a quiet week from one provider does not mean there was no mail.

Reading raw XML for many providers is painful, and most teams use a parser or a hosted service. Even so, understand the fields, or you will not catch a parser's mistake.

The three parts of the file

1. Report metadata. The reporting organization, a contact address, a report identifier and the date range in seconds since the Unix epoch. Convert the dates before you compare reports.

2. Policy published. The domain, the policy letters you published (p, sp), alignment modes for DKIM and SPF (adkim, aspf, relaxed or strict) and the percentage setting. This shows what the receiver actually saw in DNS, so it is the first thing to check when you change your record.

3. Records. One row per combination of sending IP, disposition and results, each with a count. Inside a record:

  • row: source_ip, count, and policy_evaluated, which holds the disposition applied (none, quarantine or reject), the DKIM result and the SPF result as DMARC judged them. It may also hold reason entries, for example a forwarder, a mailing list, sampling by the pct setting or a local policy override.
  • identifiers: header_from is the domain in the visible From. The envelope_from, when present, is the domain used for SPF.
  • auth_results: the raw DKIM result with its signing domain and selector, and the raw SPF result with its domain. These are what the checks said before alignment was applied.

Pass is not the same as aligned

This is the most common confusion. SPF checks the envelope sender domain, the one in the hidden return path. DKIM checks the domain named in the signature. DMARC asks a second question: does that domain match the visible From domain, exactly under strict mode or the same organizational domain under relaxed mode?

So a record can show auth_results SPF pass for a bulk mailer's own domain, while policy_evaluated SPF is fail because that domain is not yours. If DKIM is also unaligned, DMARC fails even though everything raw said pass. The fix is on the sender's side: have them sign with your domain, using a selector you publish, or use a return-path subdomain under your domain.

Sorting the sources

Start with the largest counts. For each source IP, find who runs it using a reverse lookup or a registry lookup, then match it to the header From domain. Sort sources into four groups:

  • Known and aligned: your mail platform, your invoicing system, your newsletter tool. Nothing to do except keep watching.
  • Known and failing alignment: legitimate services that send as you but are not set up. Fix these first. This is the work that lets you move to a stricter policy.
  • Forwarders and lists: real mail that was relayed.
  • Unknown: small volumes from hosting networks with failing results are typically spoofing. Larger volumes from a recognizable company are usually a service someone in the business signed up for without telling IT.

Common legitimate senders people forget include an HR or payroll portal, an e-signature product, a customer support desk, an appointment reminder tool, a website contact form and a printer or scanner that sends by email.

Forwarding, mailing lists and ARC

When a recipient forwards mail, the forwarder's server delivers it. SPF is then checked against the forwarder's IP, not yours, so SPF fails alignment. DKIM usually survives, because the signature travels with the message unless the forwarder changes the content. Mailing lists often add a subject tag or footer, which breaks the DKIM signature, and send from the list's own server, which breaks SPF. Both then fail.

ARC, defined in RFC 8617, lets each intermediary add a signed record of the authentication result it saw when the message arrived. A later receiver can see that the message passed before the relay altered it. ARC does not override DMARC on its own. Each receiver decides which intermediaries it trusts, and you cannot control that. The practical lesson is to expect some failures from forwarded mail, check the reason fields on those rows, and not drive the failure count to zero.

Using the numbers

  • Before you enforce, aim for all your own, known mail to be aligned by DKIM, which survives forwarding better than SPF.
  • Track the share of your volume that passes aligned, not the raw count of failures. Spoofing volume rises and falls with no change on your side.
  • Check the policy_published section after each DNS change to see that receivers have picked up the new record.
  • Watch for new source IPs on a schedule. A new large sender is either a new service or a problem.
  • Move from none to quarantine to reject in steps, with the pct setting if you need a slow rollout.

Limits

Aggregate reports show counts and sources, not message content. They come from the providers that choose to send them. Some failures are outside your control. We run DMARC rollouts and report reviews as scoped, authorized work and hand over a source-by-source list you can act on.

Sources

This article is general information, not legal or technical advice for your environment. Product menus, license names and provider rules change; check the vendor's current documentation before you act. Last reviewed .

Next article

Related reading

Need help with this?

Filter threats out of mail, keep every message in an immutable archive you can search, and keep email working when the mail platform goes down.

Email Security, Archiving & Continuity