DMARC Report Analyzer

Convert complex DMARC Aggregate (RUA) XML reports into human-readable tables and security insights.

Evidence ASSESSED

Checked against: DMARC aggregate report XML · RFC 7489 §7.2

RED TEAM 0 findings BLUE TEAM control did not hold

Working with RUA Reports

DMARC Aggregate Reports are sent periodically by email providers (like Google, Microsoft) to the address specified in your rua= tag.

Analyze Sources: Identify exactly which IPs are sending mail on behalf of your domain.
Verify Compliance: Check which percentage of your mail streams are successfully aligned with SPF and DKIM.
Fix Spoofing: Spot unauthorized IPs attempting to spoof your domain before you move to a reject policy.

Our DMARC Report Analyzer parses the aggregate XML reports that mailbox providers send to your rua address and turns them into a readable summary — which sources are sending as your domain, which pass authentication, and which are failing and why.

What is a DMARC Aggregate Report?

A DMARC aggregate report is an XML document that a mailbox provider sends you once a day, summarising every message it received claiming to be from your domain.

Each report groups messages by sending IP address and records how many there were, whether SPF and DKIM passed, whether each result aligned with your From domain, and what policy the provider applied as a result.

The reports arrive as gzip or zip attachments at the address in your rua= tag. They contain no message content and no recipient addresses — only counts and authentication outcomes — which is why providers are willing to send them at scale.

Daily XML summaries from each participating mailbox provider
Grouped by sending IP with message counts and authentication results
Contains no message content or recipient addresses
Delivered as compressed attachments to your rua= address
The only reliable way to discover every source sending as your domain

Why DMARC Reports Matter

Aggregate reports are what make DMARC enforcement safe. Moving to p=reject without reading them means guessing which of your systems send mail — and discovering the ones you forgot when their mail starts being rejected.

They are also a detection capability. Reports reveal every source using your domain, including ones you did not authorise: a marketing platform a department signed up for without telling anyone, a compromised account relaying spam, or an attacker spoofing your domain in a phishing campaign. None of that is visible any other way.

Reveals every system sending as your domain, including forgotten ones
Makes the move to enforcement safe rather than a guess
Surfaces unauthorised senders and shadow IT
Detects active spoofing and phishing campaigns against your brand
Shows exactly which mechanism is failing for each source

How This DMARC Report Analyzer Works

The tool parses the aggregate XML and aggregates the records into a per-source summary.

Accepts the aggregate report XML from your rua mailbox
Parses the report metadata: reporting organisation, date range and published policy
Groups records by source IP address with message volumes
Evaluates SPF and DKIM results together with their alignment status
Summarises which sources pass, which fail, and what the failure mode is

How to Use the DMARC Report Analyzer

Open the report attachment from your DMARC mailbox and extract the XML
Paste or upload the XML content into the tool
Review the summary of sending sources by volume
Investigate any source you do not recognise
For known sources that are failing, note whether SPF or DKIM is the problem

Understanding Your DMARC Report Data

Each report record describes one sending source over the reporting period:

Field / Value	Meaning
`Source IP`	The address that made the connection. Resolve it to identify the sender — it will usually be your mail provider, a vendor, a forwarder, or something unexpected worth investigating.
`Message count`	How many messages arrived from that source during the period. High volume from an unknown source is the clearest signal of either shadow IT or active abuse.
`SPF result`	Whether SPF passed for this source, and separately whether the authenticated domain aligned with your From domain. Both matter, and they are reported separately.
`DKIM result`	Whether a valid DKIM signature was present and whether its d= domain aligned. A pass without alignment does not satisfy DMARC.
`Disposition`	What the provider actually did — none, quarantine or reject. Under p=none this always reads none regardless of the authentication outcome.
`Policy evaluated`	The policy the provider applied, which may differ from your published one if they applied local overrides such as trusted forwarder handling.

Common Problems & How to Fix Them

Resolve the IP address and look up its owner. There are three likely explanations: a vendor a team signed up for without central approval, a forwarder relaying legitimate mail, or an attacker spoofing your domain.

If it is legitimate, add it to SPF or arrange DKIM signing. If it is not, an enforcing DMARC policy is what stops it — this is precisely the case DMARC exists to address.

The vendor is using its own bounce domain as the Return-Path, so SPF authenticates their domain rather than yours.

Configure a custom Return-Path with that vendor so the envelope sender is a subdomain of yours. Alternatively, arrange branded DKIM signing — only one mechanism needs to align for DMARC to pass.

This pattern usually indicates forwarding. A recipient auto-forwards your mail, which breaks SPF because the connecting server changed, and may break DKIM if the forwarder modifies the message.

This is expected background noise and is not a reason to delay enforcement. DKIM alignment typically survives forwarding, and ARC exists to handle the cases where it does not.

Raw aggregate XML is not designed for human consumption, and volume grows quickly once several providers are reporting.

Use a parser to convert reports into a summary view. Several services ingest DMARC reports for free at low volume, and reading a dashboard weekly is far more sustainable than opening attachments by hand.

Either the rua= tag is missing from your DMARC record, the address is wrong, or reports are being filtered as spam because they arrive as compressed attachments from unfamiliar senders.

Verify the rua= address, check the spam folder of the reporting mailbox, and confirm the mailbox accepts attachments. If the reporting address is on a different domain from the one being monitored, that domain needs an authorisation record.

Best Practices

Send reports to a dedicated mailbox rather than a personal inbox
Use a parser or reporting service instead of reading raw XML
Review reports weekly, and daily during a policy change
Investigate every unrecognised source before moving to enforcement
Track the proportion of mail that passes DMARC as your rollout metric
Keep reporting enabled permanently, not just during the initial rollout
Correlate report volume with your own sending volume to spot anomalies

Security Recommendations

Treat an unrecognised high-volume source as a potential compromise or active spoofing campaign and investigate promptly
Remember reports are submitted by third parties, so validate and sanitise the XML before parsing it programmatically
Watch for sudden volume spikes, which frequently precede or accompany a phishing campaign using your brand
Use reports to find shadow IT — unauthorised vendors sending as your domain are a governance problem as well as a technical one
Do not expose your DMARC reporting mailbox publicly, since knowing it reveals your monitoring posture
Keep historical reports so you can establish what normal looks like and detect deviation from it

Frequently Asked Questions

It is a daily XML summary sent by a mailbox provider describing every message it received claiming to be from your domain, grouped by sending IP with authentication results and message counts. It contains no message content.

Any mailbox provider that has implemented DMARC reporting. Google, Microsoft, Yahoo, Comcast and many others do. Each sends its own report, so you receive several per day once your rua address is configured.

No. Aggregate reports contain only counts, source IP addresses and authentication outcomes. Forensic reports, configured through ruf=, could include message details, which is why most large providers stopped sending them.

The XML is readable in principle but impractical at volume. Use a parser or a reporting service that aggregates reports across providers and presents sources, volumes and pass rates in a dashboard.

Check that your DMARC record includes a rua= tag with a valid mailto: address, look in the spam folder of that mailbox, and confirm it accepts compressed attachments. If the reporting address is on a different domain, that domain must publish an authorisation record permitting it to receive your reports.

First, any high-volume source you do not recognise. Second, known senders that fail alignment, which tells you what to fix before enforcing. Third, the overall proportion of mail passing DMARC, which is the metric that tells you when enforcement is safe.

At least two to four weeks, enough to cover a full business cycle including monthly or quarterly sending patterns. The objective is not elapsed time but confidence that every legitimate source has been identified and aligned.