How to Read DMARC Aggregate Reports

What a DMARC Aggregate Report Actually Tells You

A DMARC aggregate report is a daily XML summary that a mailbox provider sends to the address in your domain's rua tag. It lists every sending source that used your domain, how many messages each one sent, and whether SPF and DKIM passed. The rest of this guide goes through it field by field, because a first report reads as pure noise until you know where the signal sits.

The report answers one question: who sent mail as your domain, and did it authenticate? It will not tell you about opens. It will not tell you whether a message reached the inbox or the spam folder. Authentication results are the entire payload, which makes the format narrower than people expect and more useful than it first looks.

Worth saying plainly, because the panic is predictable: a big number in the fail column is not automatically an attack. A few thousand failures in a first report usually turn out to be a mailing list forwarding your mail and breaking SPF on the way through, or a vendor that has been sending on your behalf without aligned SPF or DKIM.

There are three layers, and they always appear in this order.

• Report metadata, which says who generated the report, when, and for which domain
• The published policy, which is the DMARC record the receiver saw when it evaluated your mail
• Record blocks, one per source IP and set of results, each with message counts and auth results

Read them in that order and the file becomes legible, even when what it tells you is annoying.

Aggregate Reports vs Failure Reports

Aggregate reports arrive on a schedule and cover everything. Failure reports, also called forensic reports, fire in near real time but only when a message fails and the receiver decides to send one, which is a lot of conditions to clear.

Most large mailbox providers no longer send failure reports at all. They carry message content and personal data, and privacy rules have pushed providers away from sending them. Aggregate reports are the feed you can actually rely on. The current DMARC standard, RFC 9989, splits reporting into aggregate reports (RFC 9990) and failure reports (RFC 9991), and leaves it to each receiver whether to send failure reports at all.

Timing and coverage are where the two diverge:

If failure reports show up, treat them as a bonus. The process you actually operate day to day should run on aggregate data.

DMARC Aggregate Report Examples: What the XML Looks Like

A raw report is a compressed XML file attached to an email, usually gzipped, though some providers send ZIP instead. Unzip it and you get a structure like this, trimmed for length:

<feedback>
  <report_metadata>
    <org_name>example.net</org_name>
    <report_id>1234567890</report_id>
    <date_range><begin>1735689600</begin><end>1735775999</end></date_range>
  </report_metadata>
  <policy_published>
    <domain>yourdomain.com</domain>
    <p>none</p>
    <pct>100</pct>
  </policy_published>
  <record>
    <row>
      <source_ip>203.0.113.25</source_ip>
      <count>412</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>yourdomain.com</header_from>
    </identifiers>
    <auth_results>
      <dkim><domain>yourdomain.com</domain><result>pass</result></dkim>
      <spf><domain>mail.yourdomain.com</domain><result>fail</result></spf>
    </auth_results>
  </record>
</feedback>

Each <record> block covers one source IP and one set of results, so the same IP can appear more than once. A busy domain can produce hundreds per day.

A common mistake is reading the <policy_evaluated> result and stopping there. Its dkim and spf values are alignment verdicts. The <auth_results> block below it holds the raw results and the domain each mechanism checked, which is what explains a fail.

DMARC Report XML Fields, Decoded

Each field answers a specific question. Skip one and the diagnosis goes wrong.

• org_name: the reporting organization, meaning the mailbox provider that generated the file
• report_id: a unique identifier, useful when you need to ask a provider about a specific report
• date_range: Unix timestamps for the start and end of the reporting window
• domain: the domain the receiver evaluated
• p and pct: the policy you published, as the receiver saw it. pct was removed from the current standard, so newer reports may carry a testing field instead
• source_ip: the IP address that delivered the mail
• count: how many messages came from that IP in the window
• disposition: what the receiver did, one of none, quarantine, or reject
• dkim and spf: the DMARC verdict for each mechanism: pass only if it passed and aligned with the header-from domain
• header_from: the domain in the visible From line
• auth_results: the underlying domain each mechanism actually checked

The last two fields carry the most weight. DMARC passes when either SPF or DKIM passes and aligns with the header-from domain. Alignment is the part people miss. A message can show SPF pass and still fail DMARC because the envelope-from domain does not match the header-from domain.

The DMARC overview at dmarc.org explains alignment in plain terms, and it is worth reading before you touch policy.

How to Read DMARC Aggregate Reports in Excel

Excel works fine for small volumes and breaks down fast. The steps are still worth knowing for a quick one-off check.

1. Download the attachment from the rua mailbox and unzip it.
2. In Excel, use Data > Get Data > From File > From XML, pick the file, select the record table in the Navigator, and choose Transform Data.
3. Expand the row, policy_evaluated and identifiers columns (the two-arrow icon in each header) so source IP, count, disposition, DKIM, SPF and header-from each get a column, then Close & Load. Leave auth_results unexpanded: a record with two DKIM signatures would count its messages twice.
4. Build a pivot table with source IP as rows and message count as values.
5. Sort by count descending to see which senders dominate.

The limits show up quickly. Every provider sends its own file every day, so a week of reports from five providers is 35 files, and comparing days means merging them by hand.

Spreadsheets also lose the nesting. A single record can hold several DKIM signatures, and flattening that into columns drops information.

Use Excel to learn the format. Do not run a permanent monitoring process on it.

Using a DMARC Report Analyzer Instead of Reading Raw XML

A DMARC report analyzer parses incoming reports, stores them, and presents the data as dashboards. Once reports arrive from more than a couple of providers, reading them by hand becomes a chore, and that is usually when an analyzer earns its place.

What to look for in an analyzer:

• Source grouping: each sending source's results gathered across providers and days, so one IP reads as one history instead of dozens of files
• Volume trends: message counts over time per source
• Alignment view: SPF and DKIM results shown against the header-from domain
• Export: raw data out, so you are not locked in

The trade-off is real. Hosted analyzers see your full sending inventory, which is sensitive data. Self-hosted options exist but need someone to run them.

For a small team, the deciding factor is usually time. Reading a hundred XML files a week is not a job anyone keeps up with.

Triage Unknown Sending IPs Before You Change Policy

An unknown IP is not automatically an attacker. Work through this order before touching your policy:

1. Check the volume. A handful of messages is often a forwarder or a single user's mail client.
2. Look up the IP owner. A WHOIS or reverse DNS lookup usually names the provider.
3. Check the auth results. SPF pass with DKIM fail on a known ESP points to the ESP not signing with your domain's DKIM key, not spoofing.
4. Compare against your sender inventory. If the IP belongs to a tool you forgot about, that is a gap in your records, not an attack.
5. Decide what is left. An IP that belongs to no provider you use, sends at volume, and fails both SPF and DKIM is most likely someone spoofing your domain. That is the traffic a stricter policy is for.

Watch out: changing policy to quarantine before you finish this triage will block legitimate mail from a sender you have not yet identified. That is the most common self-inflicted deliverability wound in DMARC rollouts.

If an IP stays unclear, pull a raw message header from a sample and trace the Received chain. How to analyze email header information walks through that step by step.

Safe Policy Progression from Report Evidence

Move policy only when the data supports it. A workable sequence:

1. Publish p=none and collect reports for at least two weeks.
2. Identify every legitimate sender and confirm each one passes DMARC through alignment.
3. Fix broken senders, usually by adding DKIM signing or correcting the envelope-from domain.
4. Move to p=quarantine and watch the next reports for legitimate mail being quarantined.
5. Move to p=reject once quarantine shows no legitimate failures.

Each step waits for evidence, not a calendar.

For the exact record syntax and a rollout checklist, see how to set up DMARC for small business. It covers the p=none starting point and the two-week clean-report window before escalation.

Reading Your DMARC Reports in SEMAOS

SEMAOS has DMARC monitoring on every plan, Free included, so you do not have to read the XML yourself. An account admin turns it on per domain under Settings > DMARC monitoring (or with the Monitor button on a deliverability scan report), and it becomes active once your domain has a DMARC record of its own whose rua tag lists the account's report address. From then on SEMAOS reads the aggregate reports mailbox providers send to that address and shows them on the in-app DMARC page, with a weekly digest email to the account's admins.

On paid plans and the trial, it also sends alerts, by email and in the app, for three changes worth acting on: a source it has not seen in the last 28 days sending failing mail, a sender that usually passes DMARC starting to fail, and a sudden fall in reported volume. Reports are kept for 90 days on Free and about 13 months on paid plans.

Monitoring reads reports, not your DNS. Apart from the DMARC and ownership records it checks to confirm setup, it does not look at SPF, DKIM or MX, so a broken record shows up only if it makes mail fail DMARC. It does not publish or change your DMARC record either, so the policy steps above are still yours to take. On SEMAOS's shared sending domain, DKIM and DMARC are already in place. On your own sending domain you add the records SEMAOS shows you (an ownership TXT record, three DKIM CNAMEs, and MX plus SPF on the mail subdomain) and publish DMARC yourself. To see what your domain publishes today, the free deliverability scan checks its DMARC, SPF and MX records, and DKIM at the common selectors (a custom selector is not found).

The wider picture of how SPF, DKIM, and DMARC alignment affect inbox placement is covered in the email authentication and inbox placement guide, and the underlying records are explained in the four DNS records every sender needs.

FAQ