How do you read and understand a DMARC report?

To read and understand a DMARC report, you parse the XML data it contains to see which IP addresses are sending email on behalf of your domain, whether those messages passed or failed SPF and DKIM authentication checks, and how your DMARC policy handled each result. Most email senders use a dedicated DMARC reporting tool to convert that raw XML into a readable dashboard. The sections below walk through exactly what you will find in a DMARC report and how to act on it.

What information does a DMARC report actually contain?

A DMARC report contains a structured record of every message sent using your domain during a specific reporting period, including the sending IP address, the volume of messages from that source, the SPF and DKIM authentication results for each message, and the DMARC policy disposition that was applied. It also identifies the organization that generated the report and the domain being evaluated.

Each report covers a fixed time window, typically 24 hours, and is sent by receiving mail servers such as those operated by Google, Microsoft, and Yahoo. Inside each report you will find:

• Report metadata: the reporting organization, the reporting period, and a unique report ID
• Policy published: the DMARC policy your domain has declared (none, quarantine, or reject)
• Record rows: one row per unique sending IP address, showing message count, SPF result, DKIM result, and the disposition applied
• Alignment indicators: whether the authenticated domain aligned with the From header domain

This information gives you a full picture of who is sending email in your name and whether those messages are authenticating correctly.

What’s the difference between aggregate and forensic DMARC reports?

Aggregate DMARC reports (RUA) provide a statistical summary of all messages sent using your domain over a reporting period, grouped by sending source. Forensic DMARC reports (RUF) provide individual, message-level data for emails that failed DMARC, sometimes including headers or partial message content. Aggregate reports are the standard; forensic reports are optional, and not all receivers send them.

In practice, aggregate reports are the more actionable of the two for most senders. They let you spot unauthorized senders, misconfigured mail streams, and authentication failures at scale without being overwhelmed by individual message data.

Forensic reports, when available, are useful for diagnosing specific failure scenarios. However, because they can contain sensitive information, many large mailbox providers have stopped sending them or limit what they include. Privacy regulations in various jurisdictions have also reduced their availability. For most DMARC analysis workflows, aggregate reports provide sufficient detail to identify and resolve issues.

How do you read the XML data in a DMARC report?

To read the XML data in a DMARC report, open the file and locate the record elements. Each record contains a row with the source IP address and message count, and a policy evaluated block showing the SPF, DKIM, and overall DMARC disposition results. Reading the raw XML is possible but time-consuming; most senders convert it using a reporting tool.

If you do open the raw XML file directly, here is what the key elements mean:

• <source_ip>: the IP address that sent the messages
• <count>: the number of messages sent from that IP during the reporting period
• <disposition>: what the receiving server did with the messages (none, quarantine, or reject)
• <dkim> and <spf>: pass or fail results for each authentication method
• <header_from>: the domain in the From header, which is what DMARC evaluates alignment against

The structure is consistent across all DMARC reports because it follows the published DMARC standard, so once you understand the schema, any report from any mailbox provider follows the same pattern.

What do DMARC report pass and fail results mean?

A DMARC pass means at least one authentication method, either SPF or DKIM, passed and its authenticated domain aligned with the domain in the From header. A DMARC fail means neither SPF nor DKIM produced an aligned pass, which triggers the policy action you have specified: none (monitor only), quarantine (send to spam), or reject (block delivery).

Alignment is the critical concept here. An email can pass SPF on its own, but if the domain authenticated by SPF does not match the From header domain, DMARC alignment still fails. The same logic applies to DKIM. This is why a sending service needs to be properly configured for your specific domain, not just authenticated generically.

When you see failures in a DMARC report, they typically fall into one of three categories:

1. Legitimate sending sources that are misconfigured: a marketing platform or CRM that has not been set up with your domain’s SPF record or DKIM signing
2. Third-party services you forgot about: older tools or integrations that still send on your behalf
3. Unauthorized senders: phishing attempts or spoofing using your domain

Distinguishing between these three categories is the core task of DMARC report analysis.

What should you look for when analyzing a DMARC report?

When analyzing a DMARC report, look first for unexpected IP addresses sending on your domain, then for legitimate sources that are failing authentication, and finally for the volume of failures relative to your total send volume. High failure rates from known senders point to configuration problems; failures from unknown IPs point to potential abuse or spoofing.

A structured review process helps you work through reports efficiently:

• Identify all sending sources: cross-reference IP addresses against your known sending infrastructure, including ESPs, CRMs, transactional email services, and internal mail servers
• Check alignment results for each source: confirm that every legitimate sender is passing both SPF and DKIM with proper alignment to your From domain
• Flag unknown IPs immediately: any IP you cannot attribute to a known service warrants investigation as a potential spoofing source
• Review your policy disposition: if you are running a none policy while investigating, track whether failure volumes are decreasing as you fix configurations
• Monitor trends over time: a single report is a snapshot; comparing reports across multiple days reveals patterns that a one-off review would miss

The goal of ongoing DMARC monitoring is to reach a point where all legitimate mail passes authentication and you can confidently enforce a reject policy to block unauthorized use of your domain.

What tools make DMARC reports easier to understand?

DMARC reporting tools convert raw XML files into visual dashboards that show sending sources, authentication pass and fail rates, and policy disposition breakdowns in a readable format. Popular options include dedicated DMARC platforms that aggregate reports from multiple mailbox providers into a single view, making it far easier to spot issues than reading XML manually.

When evaluating a DMARC reporting tool, look for these capabilities:

• Automated report ingestion: the tool should collect RUA reports directly rather than requiring manual uploads
• IP geolocation and source identification: mapping IP addresses to known sending services saves significant investigation time
• Trend visualization: charts showing pass and fail rates over time help you measure progress as you fix authentication issues
• Alerting: notifications when new or suspicious sending sources appear in your reports
• Policy enforcement guidance: recommendations for when it is safe to move from none to quarantine or reject

Some email service providers and security platforms include basic DMARC reporting within their existing dashboards. Standalone DMARC tools generally offer deeper analysis, particularly for organizations managing multiple domains or dealing with complex sending infrastructures.

How Email Industries helps you understand and act on DMARC reports

We work with organizations at every stage of their DMARC journey, from setting up reporting for the first time to enforcing a reject policy across complex, multi-domain sending environments. Our team brings over two decades of email authentication experience to every engagement, which means we can identify what is causing failures in your reports and fix them quickly rather than leaving you to interpret raw XML on your own.

Here is what we provide when helping clients with DMARC:

• DMARC report analysis: we review your aggregate reports, identify every sending source, and flag unauthorized or misconfigured senders
• Authentication remediation: we configure SPF, DKIM, and DMARC alignment correctly for all legitimate sending services in your environment
• Policy enforcement planning: we guide you from a monitoring policy to full rejection without disrupting legitimate mail flow
• Ongoing monitoring: through our Deliverability Assurance Packages, we keep watch over your authentication posture and alert you when new issues emerge
• Expert consulting: our email deliverability services cover the full authentication stack, not just DMARC in isolation

If your DMARC reports are surfacing failures you cannot explain, or you want to move toward a stronger policy without the risk of blocking legitimate mail, we are here to help. Reach out and contact our team to get started.

Related Articles

• What is a DMARC policy and how does it work?
• What is DMARC alignment and why does it matter?
• Is SPF still relevant for email security?
• How do email advertising agencies ensure brand consistency?
• Can full service email agencies work with small businesses?
• Should you migrate your entire email list at once or in segments?
• How do you monitor domain warmup progress effectively?
• What sending volumes should you use during domain warmup?
• Should you warm up a new IP before migrating your email program?
• What are transactional emails for ecommerce?
• What email strategies work best for ecommerce stores?
• How long does it take to improve email deliverability?
• What is email blacklist removal and how does it work?
• How do consultants address spam filter issues?
• What should you look for in email deliverability agencies?