What is a DMARC aggregate report?

A DMARC aggregate report is an XML file sent by email receivers (like Google, Microsoft, and Yahoo) to domain owners. It covers a specific time period (usually 24 hours) and contains data about who sent email using your domain, whether authentication passed or failed, and what the receiver did with each message.

How often are DMARC reports sent?

Most email providers send DMARC aggregate reports once every 24 hours. The exact timing depends on the provider. Google typically sends reports daily, while some smaller providers may send them less frequently.

Can I read DMARC reports without a tool?

Technically yes, DMARC reports are XML files that can be opened in any text editor. However, they're difficult to interpret manually, especially at scale. Most organizations use a tool like MailShield to automatically parse, aggregate, and visualize the data.

All posts

Guides

How to Read a DMARC Report (With Real Examples)

Q: What does DMARC alignment mean?

DMARC alignment means the domain in the From header matches the domain authenticated by SPF or DKIM. A message can pass SPF and DKIM but still fail DMARC if neither authenticated domain aligns with the From domain. Alignment is what DMARC actually checks.

May 2, 20269 min

How to Read a DMARC Report (With Real Examples)

You published a DMARC record, pointed the rua tag at your inbox, and now you're receiving compressed XML files from Google, Microsoft, Yahoo, and others. You open one and see hundreds of lines of angle brackets, IP addresses, and cryptic status codes.

These are DMARC aggregate reports, and they're the most valuable tool you have for understanding who's sending email as your domain. But only if you can read them. Here's a practical guide.

What's in an aggregate report?

A DMARC aggregate report is an XML file covering a specific time period (usually 24 hours) from a single reporting organization. It contains two main sections:

Report metadata: who sent the report, for which domain, and the time period it covers
Records: one entry per unique combination of sending IP, authentication result, and disposition. Each record includes the IP address, message count, SPF result, DKIM result, and what the receiver did with the messages

The key fields to focus on

You don't need to read every XML tag. Focus on these fields in each record:

source_ip: the IP address that sent the email. Look this up to identify the sending service (Google, SendGrid, your own server, etc.)
count: how many messages came from this IP during the reporting period
disposition: what the receiver did: none (delivered), quarantine (sent to spam), or reject (blocked)
dkim: pass or fail, plus the domain that was checked (the d= value)
spf: pass or fail, plus the domain that was checked (the envelope sender)
alignment: whether the authenticated domain matches the From header domain. This is what DMARC actually cares about

A message can pass SPF and DKIM but still fail DMARC if neither result aligns with the From domain. Alignment is the most commonly overlooked part of DMARC reports.

What to look for

When analyzing your reports, ask these four questions for each record:

Do I recognize this IP? If not, someone unknown is sending email as your domain. Look up the IP to determine if it's a forgotten service or an unauthorized sender.
Is authentication passing? If a known sender fails SPF or DKIM, they need to be configured correctly. This is the most common issue.
Is alignment working? Even if SPF/DKIM pass, the authenticated domain must align with your From domain. Many third-party senders break alignment by default.
What's the disposition? If your policy is p=none but you see quarantine or reject actions, the receiving server is applying its own stricter policy.

A real-world example

Here's what a typical record looks like in a DMARC report (simplified):

This is what you want to see: a known sender (Google), passing both DKIM and SPF with alignment, and all messages delivered normally.

Now contrast that with a problematic record:

This IP is sending email as your domain, failing all checks, and still being delivered (because your policy is p=none). This could be a phishing attempt, or a legitimate service you forgot to authorize. Either way, it needs investigation.

The problem with manual analysis

A small domain receives dozens of reports per week. A busy domain can receive hundreds. Each report contains multiple records. The reports arrive compressed (ZIP or GZIP), and you need to decompress, parse the XML, resolve IP addresses, and aggregate data over time to spot trends.

This is exactly the kind of work that should be automated.

How MailShield automates this

MailShield receives your DMARC reports automatically, parses every record, resolves IP addresses to known services, and presents everything in a clear dashboard. You see who's sending email as your domain, whether they're authorized, and what needs to be fixed.

No more XML. No more IP lookups. No more guessing. Add your domain to MailShield and start seeing your DMARC data clearly. Free for up to 2 domains.