How to Read and Act on DMARC Aggregate Reports: A Practical Guide

What DMARC aggregate reports actually tell you

A DMARC aggregate report arrives on a schedule set by your domain's RUA (Reporting URI Aggregate) tag. It does not contain message content. It contains metadata: which mail servers sent email claiming your domain, whether those servers passed SPF, DKIM, and DMARC alignment checks, and what the receiving server decided to do with the message.

Think of it as a traffic report for your domain's email identity. You did not ask every car on the road where it was going. But someone is counting which cars drove through your street and whether they had the right to be there.

This is also the data DMARCFlow processes automatically when you connect your domain. Rather than opening XML files manually, DMARCFlow normalizes the report data and surfaces it as a triage dashboard. You still need to understand what the underlying data means so you can make the right decisions about your policy.

The anatomy of a DMARC aggregate report

Aggregate reports arrive as XML or JSON. The structure is defined in RFC 7478 and expanded by RFC 9083. Here is what each part means.

feedback: the top-level container. It holds metadata about the report itself, including the report generator and the date range covered.

record: the core unit. Each record represents one sending source within the report window. One report can contain hundreds of records.

Inside each record:

row: the summary line for one source IP.

• source_ip: the IP address of the mail server that sent the email. This is how you identify who is actually sending for your domain.


• count: how many messages were sent from this IP during the reporting period.

policy_evaluated: what the receiving server decided to do based on your DMARC policy.

• disposition: none, quarantine, or reject. This tells you what the receiving server did with the message, not what you told it to do. If you published p=quarantine but the message shows disposition=none, the server may have overridden your policy, or alignment failed in a way that bypassed your rule.


• dkim: pass or fail. This is the result of the DKIM check on the RFC 5322 From domain.


• spf: pass or fail. Same logic: SPF check against the RFC 5322 MAIL-FROM domain.

identifiers: the email addresses involved.

• header_from: the domain in the RFC 5322 From header. This is the domain DMARC checks against.


• envelope_from: the MAIL-FROM domain. This is the domain SPF checks against.


• return_path: similar to envelope_from, this is where bounces go.

auth_results: detailed per-mechanism results.

• dkim: shows whether DKIM passed or failed for each selector tested.


• spf: shows whether SPF passed or failed for the envelope domain.

Alignment is the part DMARC actually checks. Alignment means the domain in the From header matches (or does not match) the domain that passed SPF or DKIM. Strict alignment requires an exact domain match. Relaxed alignment allows a subdomain match and is the default if you do not specify anything.

Reading the XML fields in practice

Here is a simplified parsed example of a passing record:

Source IP: 203.0.113.45
Messages sent: 1,247
SPF result: pass
DKIM result: pass
DMARC alignment: pass (relaxed)
Policy evaluated: none

This means the sending server authenticated correctly, the From domain aligned with the authenticated identity, and the receiving server took no action because your policy was p=none.

Now a failure record:

Source IP: 198.51.100.22
Messages sent: 89
SPF result: pass
DKIM result: fail
DMARC alignment: fail
Policy evaluated: none

DKIM failed here. That could mean the message was signed but the signature did not verify, the selector DNS record is wrong, or the signing domain does not match the From domain. The fact that SPF passed but DKIM failed is a specific pattern worth investigating before you tighten your policy.

Which failures actually matter

Not all failures are equal. Here is a quick triage priority.

High priority: DKIM failures from known senders. If your CRM, marketing platform, or internal mail server is sending email that fails DKIM alignment, fix the DKIM selector configuration or change the signing domain to match your From domain. This is the most common legitimate-sender problem DMARCFlow surfaces in reports.

Medium priority: SPF failures from legitimate sources. If a forwarding chain broke your SPF because the forwarder changed the envelope MAIL-FROM, that shows as SPF fail. You may need ARC (Authenticated Received Chain) to handle forwarded mail, or accept that forwarded newsletters will fail DMARC.

Low priority: Unaligned failures from unknown sources. If a record shows a source IP you do not recognize and both SPF and DKIM failed, that is likely spoofing. Your policy is already doing its job if it is set to quarantine or reject. Log the IP and move on.

Check the count field. A count of 1 from an unknown IP is noise. A count of 50,000 from an unknown IP is an active spoofing campaign. Scale your response to the volume.

Moving from p=none to p=quarantine using report data

You do not need to guess when to tighten your DMARC policy. The aggregate report tells you when you are ready.

Read your p=none reports for at least 30 days. Count the number of unique source IPs that show aligned passes for SPF and DKIM. Those are your legitimate senders. DMARCFlow tracks this over time, so you can see whether your legitimate senders are consistently passing before you change anything.

The transition sequence most practitioners follow:

1. Stay at p=none for at least 30 days while monitoring weekly.
2. Fix any legitimate sources that are failing alignment.
3. Move to p=quarantine and monitor for two weeks.
4. Move to p=reject if quarantine produces no unexpected bounces.

If you see unknown sources sending high volumes before you have tightened the policy, investigate those before moving up. You cannot block what you have not identified.

Automating DMARC report analysis

Reading XML reports manually works for one or two domains. It does not scale. If you manage multiple domains, the file size and the number of records per report make manual parsing impractical.

DMARCFlow automates the ingestion and parsing of DMARC aggregate reports. It normalizes the data, flags authentication failures by source IP, identifies legitimate versus suspicious senders, and surfaces the report data in a format you can act on. That means you spend time on the triage decision, not on parsing XML.

For any domain where you are serious about moving to p=quarantine or p=reject, automated monitoring is the practical path. The alternative is building a parsing pipeline and a dashboard yourself, which is a project with ongoing maintenance.

FAQ

What does SPF pass mean in a DMARC report?
SPF pass means the sending server's IP is authorized for the envelope MAIL-FROM domain. It does not mean the From header domain is authorized. DMARC checks alignment separately. A message can have SPF pass and still fail DMARC if the From domain does not align with the envelope domain.

How do I find the source IP of a failed email in my DMARC report?
Look at the field in the section of each record. This is the IP address of the mail server that delivered the message. Cross-reference it with your sending platform logs to identify the source.

What does alignment strict versus relaxed mean in a DMARC report?
Relaxed alignment allows a subdomain match. If your From domain is example.com and the authenticated domain is sub.example.com, relaxed alignment passes. Strict alignment requires an exact domain match. If your DMARC record does not specify a strict mode, you are using relaxed alignment by default.

Why do forwarded emails show DKIM fail in DMARC reports?
Forwarded emails often lose the DKIM signature because the forwarding server modifies the message. When the forwarded message arrives at the final destination, the DKIM signature no longer verifies. This is a known limitation of DKIM. Forwarding chains also break SPF because the envelope MAIL-FROM changes. ARC (Authenticated Received Chain) was designed to handle this by preserving the original authentication results through the forwarding chain.

When should I move from p=none to p=quarantine based on my DMARC reports?
Move to p=quarantine when your aggregate reports show that all of your legitimate sending sources are consistently passing DKIM or SPF alignment. If you have unknown sources sending legitimate email (such as a third-party platform you forgot to configure), fix those before moving up. Rushing the policy change before identifying all legitimate sources will cause legitimate email to be quarantined or rejected.