How to Read DMARC Aggregate Reports

Published 27 April 2026

Once you've published a DMARC record with a rua= address, receivers around the world will start sending you aggregate reports — typically one per receiver per day. Each report summarises which IPs sent mail claiming to be from your domain, what authentication results were observed, and what the receiver did with each message.

The reports are dense, in XML, and often delivered as base64-encoded zip attachments. Reading them by hand at any meaningful scale is impossible. But understanding what's in them — and what patterns matter — is the difference between a DMARC deployment that protects your domain and one that just generates noise.

What an Aggregate Report Contains

A typical aggregate report includes:

• Reporter metadata — which receiver generated the report (Google, Microsoft, Yahoo, etc.) and the time window covered.
• Your published DMARC policy — what was being enforced during that window.
• One <record> per source IP sending on your behalf during the window.

Each <record> contains:

<record>
    <row>
        <source_ip>192.0.2.10</source_ip>
        <count>42</count>
        <policy_evaluated>
            <disposition>none</disposition>
            <dkim>pass</dkim>
            <spf>pass</spf>
        </policy_evaluated>
    </row>
    <identifiers>
        <header_from>example.com</header_from>
    </identifiers>
    <auth_results>
        <dkim>
            <domain>example.com</domain>
            <result>pass</result>
            <selector>20260427</selector>
        </dkim>
        <spf>
            <domain>example.com</domain>
            <result>pass</result>
        </spf>
    </auth_results>
</record>

Reading top-down: a sender at IP 192.0.2.10 sent 42 messages during the report window, claiming to be from example.com. Both DKIM and SPF passed, so DMARC passed (alignment was OK). The receiver applied no special disposition — the messages went to inbox.

The Fields That Actually Matter

source_ip

The IP that sent the messages. This is your single most important field — it tells you who's sending mail claiming to be from your domain. Look it up: rDNS, WHOIS, ASN. If it's a known sender (your provider's IP range, your office IP, etc.), it's legitimate. If it's an IP in a country you don't operate in, sending mail you didn't send, it's almost certainly spoofing.

count

How many messages from this IP during the report window. High counts on legitimate senders are normal. High counts on unknown senders are alarming.

policy_evaluated.disposition

What the receiver actually did with the messages: none, quarantine, or reject. This is what your DMARC policy caused to happen — useful for confirming enforcement is working as expected.

policy_evaluated.dkim and policy_evaluated.spf

The aligned authentication result — meaning, did SPF/DKIM not just pass, but pass against the same domain as the From header. Crucial: a message can have auth_results.dkim=pass but policy_evaluated.dkim=fail if the DKIM signature was for a different domain than the visible From.

identifiers.header_from

The visible From domain on the message. If your DMARC policy is on example.com but messages are being sent with header_from=phishing.example.com, that's relevant context.

auth_results

Raw SPF and DKIM results — what authenticated, regardless of alignment. Useful for understanding why a message failed: was it that SPF didn't pass at all (auth failure), or that SPF passed but for a different domain (alignment failure)?

The Three Categories You're Sorting Into

For each unique source IP in your reports, you're answering: which of these three buckets does it belong to?

Bucket 1: Legitimate, authenticated

Known sender, mail passes both SPF and DKIM with alignment. Action: nothing. This is what you want to see for the bulk of your traffic.

Bucket 2: Legitimate, not properly authenticated

Known sender (your CRM, your invoicing tool), but SPF and/or DKIM are failing. Sometimes the IP isn't in your SPF; sometimes the DKIM key isn't published; sometimes the sender uses a different envelope domain that doesn't align. Action: fix the authentication. This is the entire reason for keeping p=none for the first weeks of a DMARC rollout — to surface these.

Bucket 3: Illegitimate

Unknown sender, mail failing auth. Almost certainly spoofing. Action: nothing — DMARC will reject these once you reach p=reject. But monitoring volume is useful: a sudden spike in spoof attempts may indicate a phishing campaign targeting your customers, which is worth knowing about.

Reading Reports Without a Tool

You technically can read aggregate reports manually. The flow:

1. Receive the report (usually a .zip or .gz attachment to an email).
2. Decompress to get the XML.
3. Read the XML.

For one or two reports, that's fine. In production, you'll receive 10–50 reports per day. You'll need:

• A mailbox or service consuming the reports automatically.
• A parser that extracts the <record> entries.
• Aggregation: group by source IP, sum counts across reporters, show trend over time.
• Reverse DNS lookups to identify each source IP.
• Filtering to focus on failures and unknown senders.

Don't build this yourself. DMARC Dashboard handles ad-hoc spot checks. For ongoing monitoring of high-volume domains, paid services (dmarcian, EasyDMARC, Valimail, Postmark) handle ingestion, aggregation, and alerting in exchange for a monthly fee.

What to Look at First

When you open your reports, the order of operations:

1. Total volume. Has it changed dramatically from previous reports? Big jumps may indicate a new sender came online — legitimate or otherwise.
2. Top source IPs by count. The 5–10 IPs sending the most mail. These should all be familiar; if any aren't, investigate.
3. Failure rate. What percentage of mail is failing DMARC? At p=none, this isn't actionable — but at p=quarantine, persistent fails mean your enforcement is hitting real mail.
4. New source IPs. IPs that weren't in previous reports. These are the most interesting — they represent a change in sending patterns, deserving attention.
5. Failures aligned to the apex. Mail with header_from=example.com failing alignment is a higher concern than failures from subdomains you may not be enforcing.

Patterns That Mean Spoofing

• IPs from countries where you don't operate sending in volumes too high to be a one-off. Especially residential IPs (DSL, cable) — legitimate senders use commercial mail relays.
• Sudden burst of mail from an unknown IP that lasts a few hours and disappears. Classic spam campaign signature.
• Lookalike subdomains. Mail from support.example.com when you only send from example.com. Spoofers know subdomain inheritance and try to evade p=none policies.
• SPF passes on someone else's domain. The mail's SPF passed for some unrelated domain (the spammer's), but the From header says yours. SPF passes but DMARC alignment fails. Classic spoofing pattern.

Patterns That Mean You Have a Configuration Problem

• A familiar sender consistently failing. Your CRM has been sending for years and never failed before — but now its IP isn't in your SPF, or its DKIM isn't aligned. The sender changed something; update your auth setup.
• Per-message failures from a known sender. Most messages pass; some fail. Often a sign of header modification by an intermediate (a list, a gateway). Check whether the failing messages are forwarded.
• SPF failures that DKIM compensates for. If SPF is failing but DKIM is consistently passing, your SPF record is incomplete — but DMARC still passes overall (because DMARC requires either SPF or DKIM to pass, not both). Worth fixing for cleanliness.
• A sender passing only DKIM, not SPF. Means they're forwarding mail, signing it themselves but not getting their IP into your SPF. Common for mailing lists; usually fine.

The Maintenance Cadence

For a fully-deployed DMARC at p=reject:

• Weekly: 10-minute scan of new source IPs and any sender showing failures. Most weeks: nothing actionable.
• Monthly: review the volume and pass-rate trend. Big swings deserve investigation.
• Quarterly: full sender audit. Confirm every known sender is still authenticating cleanly; investigate any new senders.
• Annually: rotate DKIM keys, audit SPF for obsolete includes, refresh reporting tooling.

Most weeks you'll close the report after 30 seconds because everything looks normal. The 30 seconds is what makes the next attack visible the moment it happens. DMARC Dashboard can verify your policy and reporting setup in seconds — useful for the periodic check.