You’ve set up DMARC, and now XML files are flooding your inbox. The data inside tells you exactly which emails pass authentication and which fail — but only if you know how to read it.
DMARC reports arrive from mailbox providers like Gmail, Microsoft, and Yahoo. Each report contains authentication results for every email sent from your domain during a specific period. Reading these reports correctly reveals:
- Unauthorized senders
- Misconfigured services
- Authentication gaps are causing your emails going to spam
Let’s break down each field in a DMARC report so you can identify problems and fix them.
What do DMARC reports tell you about email authentication?
A DMARC report is a feedback document generated by receiving mail servers.
When someone receives an email claiming to be from your domain, the receiving server checks authentication (SPF and DKIM) and records the results. Those results get packaged into a report and sent to you.
Reports arrive in XML format — structured data meant for machines, not humans. A single report from Google might contain authentication results for hundreds or thousands of messages sent during a 24-hour window.
Each report answers three questions about emails sent from your domain:
- Who sent them (identified by IP address)
- Did they pass SPF and DKIM checks
- What action did the receiving server take based on your DMARC policy
The value here is visibility. Without reports, you’re guessing whether your marketing platform, CRM, or transactional email service is properly authenticated. With reports, you know — and you can spot problems before they tank your sender reputation.
What are the two types of DMARC reports?
DMARC generates two distinct report types, each serving a different purpose. Understanding the difference matters because you’ll interact with them differently (and one is far more useful than the other for most situations).
Aggregate reports (RUA)
Aggregate reports provide statistical summaries of authentication results over a time period — usually 24 hours. Gmail sends one report per day covering all emails they received from your domain.
These reports contain:
- SPF and DKIM pass/fail rates
- Total message counts per sending IP
- No personally identifiable information
- Policy disposition (what happened to failing messages)
Aggregate reports are your primary working document. The rua tag in your DMARC record specifies where these reports should be sent.
Forensic reports (RUF)
Forensic reports (also called failure reports) provide message-level details when authentication fails. Instead of statistics, you get copies of actual failed messages — headers, subject lines, sometimes even body content.
The catch: most major providers don’t send forensic reports anymore. Google and Yahoo stopped sending them due to privacy concerns (GDPR and similar regulations). Microsoft sends limited forensic data. If you’ve configured the ruf tag and aren’t receiving reports, the receiving servers are likely blocking them.
For practical purposes, focus your energy on aggregate reports. Forensic reports are helpful when available, but you can’t count on receiving them.
How do you break down a DMARC aggregate report?
Raw aggregate reports look intimidating — walls of XML tags with cryptic values. But the structure is consistent, and once you understand the sections, reading them becomes straightforward.
Here’s a simplified example of what you’ll receive:
xml
<?xml version="1.0" encoding="UTF-8"?>
<feedback>
<report_metadata>
<org_name>google.com</org_name>
<email>noreply-dmarc-support@google.com</email>
<report_id>1234567890</report_id>
<date_range>
<begin>1704067200</begin>
<end>1704153599</end>
</date_range>
</report_metadata>
<policy_published>
<domain>yourdomain.com</domain>
<adkim>r</adkim>
<aspf>r</aspf>
<p>none</p>
<pct>100</pct>
</policy_published>
<record>
<row>
<source_ip>192.0.2.1</source_ip>
<count>150</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>pass</spf>
</policy_evaluated>
</row>
</record>
</feedback>Every aggregate report contains three main sections. Let’s walk through each.
Report metadata
The metadata section identifies who sent the report and what time period it covers.
| Field | What it shows | Example |
| org_name | Mailbox provider that generated the report | google.com |
| report_id | Unique identifier for this report | 1234567890 |
| begin | Start of reporting period (Unix timestamp) | 1704067200 |
| end | End of reporting period (Unix timestamp) | 1704153599 |
Unix timestamps represent seconds since January 1, 1970. The example above covers January 1, 2024, 00:00:00 to January 1, 2024, 23:59:59 UTC. Online converters can translate these to human-readable dates.
Policy published
The policy section shows your DMARC configuration as the receiving server understood it when processing messages.
| Field | Meaning | Values |
| domain | Your sending domain | yourdomain.com |
| adkim | DKIM alignment mode | r (relaxed) or s (strict) |
| aspf | SPF alignment mode | r (relaxed) or s (strict) |
| p | Your DMARC policy | none, quarantine, or reject |
| pct | The percentage of messages the policy applies to | 0-100 |
Alignment modes matter more than most people realize. Relaxed alignment (r) allows subdomains to pass — mail from news.yourdomain.com can align with a DKIM signature for yourdomain.com.
Strict alignment (s) require exact domain matches. Most configurations use relaxed alignment because it’s more forgiving of legitimate mail setups.
Record section
The record section contains the actual authentication data — one entry per unique combination of source IP, SPF result, and DKIM result.
| Field | What it tells you |
| source_ip | IP address of the server that sent the email |
| count | Number of messages from that IP during the reporting period |
| disposition | Action taken (none, quarantine, reject) |
| dkim | DKIM authentication result |
| spf | SPF authentication result |
When you see 150 messages from IP 192.0.2.1 with dkim: pass and spf: pass, that’s a healthy sending source. When you see 50 messages from an unfamiliar IP with dkim: fail and spf: fail, you’ve found either a misconfigured service or someone attempting to spoof your domain.
What do authentication results actually mean?
Pass and fail seem obvious, but DMARC authentication has nuances worth understanding. A “pass” on SPF doesn’t automatically mean DMARC passes — alignment matters too.
SPF results
SPF checks whether the sending server’s IP address is authorized in your SPF record.
| Result | Meaning |
| pass | Sending IP is explicitly authorized |
| fail | Sending IP is not authorized (hard fail) |
| softfail | Sending IP is questionable (~all mechanism) |
| neutral | SPF record makes no assertion (?all) |
| none | No SPF record exists for the domain |
A softfail usually indicates an SPF record ending with ~all instead of -all. Many domains use softfail during initial SPF deployment, but it weakens your authentication.
DKIM results
DKIM verifies that the email content hasn’t been modified since the sender signed it. You’ll need to set up DKIM for each service that sends on your behalf.
| Result | Meaning |
| pass | Valid signature verified against public key |
| fail | Signature invalid, missing, or doesn’t match |
| none | No DKIM signature present |
DKIM failures happen for several reasons — missing DNS records, incorrect selector configuration, or content modifications by forwarding servers. The report tells you that DKIM failed, but not why, so you’ll need to investigate the specific sending source.
DMARC alignment
SPF and DKIM can both pass, yet DMARC still fails. DMARC requires alignment — the domain in SPF or DKIM must match (or be a subdomain of, in relaxed mode) the domain in the From header.
An email from newsletter@yourdomain.com passes DMARC when:
- SPF passes and the Return-Path domain aligns with yourdomain.com, OR
- DKIM passes and the DKIM signing domain aligns with yourdomain.com
Only one needs to align. If both SPF and DKIM pass but neither domain aligns with the From header, DMARC fails despite the individual authentication successes.
How do you identify problem sources in your reports?
Reading the XML structure is one thing. Knowing what to do with the data is another. The goal is to categorize your sending sources into three buckets: legitimate and working, legitimate but misconfigured, and unauthorized.
Recognizing legitimate sources
Start by listing every service that should send email from your domain:
- Transactional email services (EmailWarmup.com, SendGrid, Mailgun, Postmark)
- Your email service provider (Google Workspace, Microsoft 365)
- Marketing platforms (Mailchimp, Klaviyo, HubSpot)
- CRM systems (Salesforce, Pipedrive)
- Support ticketing systems
- Internal applications
Match source IPs in your reports to these services. Many DMARC analysis tools perform automatic reverse DNS lookups — turning 192.0.2.1 into mail-server.sendgrid.net saves significant investigation time.
Spotting configuration issues
Common patterns indicate specific problems:
| Pattern | Likely cause |
| SPF fail, DKIM pass | Sending IP missing from SPF record |
| SPF pass, DKIM fail | DKIM not configured for that sender |
| Both fail, known IP | Major authentication misconfiguration |
| Both fail, unknown IP | Possible spoofing attempt |
When a legitimate service shows SPF failures, check whether you’ve added their sending IPs or include a mechanism in your SPF record. When DKIM fails, verify you’ve added the correct DNS records for that service’s signing domain.
Handling unknown senders
Not every unknown IP means malicious activity. Forwarding services, mailing lists, and email security gateways can modify messages in ways that break authentication. But unknown IPs with high volumes and failed authentication deserve scrutiny.
Before assuming the worst, check whether the IP belongs to:
- An email security vendor
- A service you forgot you integrated
- A forwarding service that your recipients used
If you genuinely can’t identify the source and volumes are significant, someone might be spoofing your domain. Moving your DMARC policy from p=none to p=quarantine or p=reject will stop those messages from reaching inboxes.
Should you use DMARC analysis tools?
Raw XML reports work fine when you’re receiving a handful per day. But organizations sending significant email volume receive hundreds or thousands of reports weekly. Manual analysis becomes impossible.
DMARC analysis tools (EasyDMARC, Mimecast DMARC Analyzer, dmarcian, MxToolbox) automatically:
- Track authentication trends over time
- Perform reverse IP lookups to identify senders
- Categorize sources as compliant, non-compliant, or suspicious
- Alert you when new sending sources appear
- Parse XML into readable dashboards
The investment makes sense once you’re actively monitoring and tuning your DMARC configuration. For initial setup and testing with low volumes, manual review teaches you what the data actually means — which makes you better at using the tools later.
What should you do after reading your reports?
DMARC reports are diagnostic. The value comes from acting on what you find.
When reports show authentication failures for legitimate senders, update your SPF and DKIM configurations. Your SPF record needs to include every IP that sends on your behalf. Each sending service needs its own DKIM setup.
When reports show failures you can’t diagnose, run a deliverability test to see how different providers handle your messages. If the technical details feel overwhelming, a 1:1 session with an email deliverability consultant (free) can pinpoint exactly what needs fixing.
Once your legitimate sources show consistent passes, consider tightening your DMARC policy from p=none to p=quarantine — then eventually to p=reject. The reports will continue showing you what’s happening, letting you catch new issues before they affect deliverability.
Frequently asked questions
Here are some commonly asked questions about DMARC reports:
Most mailbox providers send aggregate reports once every 24 hours. Google, Microsoft, and Yahoo follow this daily cadence. Some smaller providers batch reports weekly. The ri tag in your DMARC record can request a specific reporting interval (in seconds), but providers aren’t required to honor it.
Missing reports usually mean one of three things: your DMARC record doesn’t have a rua tag specifying where to send them, the email address in your rua tag isn’t valid, or your domain hasn’t sent any email to providers that generate reports. Check your DMARC record syntax and verify the receiving mailbox exists.
A disposition of “none” means the receiving server didn’t take any action against the message — even if authentication failed. This happens when your DMARC policy is set to p=none (monitoring mode). The server recorded the results but delivered the email normally regardless of pass or fail status.
Yes. XML files are text-based and readable in any text editor. For low volumes, manual review teaches you exactly what each field means. The challenge is scale — once you’re reviewing dozens of reports covering thousands of messages, spreadsheets or dedicated analysis tools become practical necessities.
RUA (aggregate reports) contain statistical summaries with no message content — just counts, IPs, and authentication results. RUF (forensic reports) contain actual message data from authentication failures. RUA reports are universally supported. RUF reports are rarely sent by major providers due to privacy regulations.
