How to Read DMARC Reports: A Guide to RUA and RUF (with examples)
A DMARC report is a daily summary that mailbox providers like Google and Microsoft send back to you, listing every email they saw claiming to be from your domain and whether it passed SPF and DKIM. There are two types: aggregate reports (rua=), which you should always enable, and forensic reports (ruf=), which are per-message failure reports.
Updated June 2026
This guide walks through what each report type contains, shows an annotated XML example, explains every field you will see, and covers how to use reports to move safely from p=none to p=reject.
Two Types of DMARC Report
The DMARC specification defines two reporting mechanisms. They serve different purposes and are configured with separate tags in your DMARC record.
| Report type | DMARC tag | Format | Purpose |
|---|---|---|---|
| Aggregate (RUA) | rua= | XML (gzip or zip compressed) | Daily summary of all email seen from your domain, grouped by source IP and authentication results |
| Forensic (RUF) | ruf= | AFRF (email format) | Per-message failure report with headers from individual emails that failed DMARC |
Aggregate Reports (RUA)
Aggregate reports are the backbone of DMARC monitoring. Every mailbox provider that supports DMARC (Gmail, Microsoft, Yahoo and others) sends daily aggregate reports to the address in your rua= tag. Each report covers a 24-hour window and contains a summary of every email the provider saw claiming to be from your domain.
What is inside an aggregate report
An aggregate report is an XML file, typically delivered as a gzip-compressed attachment. It contains:
| Section | What it tells you |
|---|---|
| Report metadata | Who sent the report (e.g. google.com), the reporting period (start/end timestamps), and a unique report ID |
| Policy published | The DMARC record the receiving server found in your DNS at the time, including your policy (p=), subdomain policy (sp=), and alignment modes (adkim=, aspf=) |
| Records (rows) | One row per unique combination of source IP, SPF result, DKIM result, and DMARC disposition. Each row includes a message count, the evaluated policy action, and the authentication results |
Example aggregate report (simplified)
Key fields to focus on
- source_ip: The IP address of the server that sent the email. Look this up to identify the service (e.g. Google Workspace, Microsoft 365, Mailchimp, or an unknown server that may be spoofing you).
- count: The number of emails from this source IP during the reporting period. High counts from unrecognised IPs are a red flag.
- disposition: What the receiving server did with the email:
none(delivered),quarantine(sent to spam), orreject(blocked). - dkim/spf results: Whether SPF and DKIM passed or failed for this source. If a legitimate sender is failing, you need to fix their DNS configuration before moving to enforcement.
- header_from: The domain in the visible From header. This should always be your domain. If it is not, the email is not relevant to your DMARC policy.
Forensic Reports (RUF)
Forensic reports provide per-message detail when an email fails DMARC. Unlike aggregate reports which group data by source IP, forensic reports include the actual email headers (and sometimes a redacted body) of each failing message.
What forensic reports contain
- The full email headers of the failing message
- The specific authentication failure (SPF, DKIM, or both)
- The sending IP address
- The subject line (sometimes redacted for privacy)
- Timestamps and receiving server details
Limitations of forensic reports
Most major providers do not send forensic reports. Google, Microsoft, and Yahoo rarely (or never) send RUF reports due to privacy concerns. Forensic reports are most useful when your recipients are on enterprise mail systems that do support them. Do not rely on RUF as your primary data source.
Controlling forensic report detail with fo=
The fo= tag in your DMARC record controls when forensic reports are generated:
| Value | Meaning |
|---|---|
| fo=0 | Generate a report only if both SPF and DKIM fail alignment (default) |
| fo=1 | Generate a report if either SPF or DKIM fails alignment (recommended) |
| fo=d | Generate a report if DKIM signature verification fails |
| fo=s | Generate a report if SPF evaluation fails |
How to Set Up DMARC Reporting
Step 1: Add rua to your DMARC record
Your DMARC record is a DNS TXT record at _dmarc.yourdomain.com. Add the aggregate reporting tag:
The mailto: prefix is required. You can specify multiple addresses separated by commas. Forensic reporting (ruf=) can be added alongside rua= and points at a mailbox that accepts per-message failure reports. Send ruf= to an endpoint that is equipped to parse and store the data safely, not a general-purpose inbox.
Step 2: Sending reports to a different domain
If your RUA address is on a different domain (e.g. you want reports sent to a monitoring service), the receiving domain must publish an authorisation record:
Without this record, receiving mail servers will not send reports to the external address. This is a common gotcha when setting up third-party DMARC monitoring.
Step 3: Wait for reports to arrive
Aggregate reports are sent once per day (though some providers send them more frequently). After updating your DMARC record, allow 24 to 48 hours for the first reports to arrive. The volume depends on how much email your domain sends.
Step 4: Parse and analyse
Raw DMARC aggregate reports are XML files that can be hundreds of kilobytes each. Reading them by hand is impractical at any scale. You have two options:
- Manual: Download the XML attachments, decompress them, and read the records. Feasible for a single domain with low volume, but does not scale.
- Automated: Use a DMARC reporting platform to ingest, parse and visualise the reports. This gives you dashboards showing sending sources, pass/fail rates, and alignment trends over time.
Using Reports to Reach Enforcement
The real value of DMARC reports is the path they create from p=none to p=reject. Here is the process:
- Publish p=none with rua= to start collecting data without affecting mail delivery.
- Identify all legitimate senders from the aggregate reports. Look up each source IP and match it to a known service (your mail server, CRM, marketing platform, etc.).
- Fix any failing senders. Ensure each legitimate service passes SPF (add their include to your SPF record) or DKIM (configure their signing domain).
- Move to p=quarantine once all legitimate senders are passing. Failing emails will go to spam rather than the inbox, so any mistakes are recoverable.
- Monitor for a few weeks and check that no legitimate emails are being quarantined.
- Move to p=reject to fully block spoofed emails. Use relaxed alignment (
adkim=r; aspf=r) for active sending domains to avoid breaking third-party senders, and always set a subdomain policy (sp=reject) to protect unused subdomains.
How long does this take?
There is no fixed timeline. The gate is report cleanliness, not the calendar. A simple setup with one or two email services can reach p=reject quickly once aggregate reports show every authorised sender aligning. Estates with dozens of SaaS senders may take longer because each new sender surfaced in reports needs SPF or DKIM fixed before progression. Don't rush. Don't drag your feet either. Work the report inbox, and advance when it is clean.
Common Problems With DMARC Reports
Not receiving any reports
- Check that your DMARC record has a valid
rua=mailto:tag. Use our DMARC Checker to verify. - If your RUA address is on a different domain, ensure the external authorisation DNS record is in place.
- Check your spam folder. Some email providers classify DMARC report emails as bulk mail.
- Allow at least 48 hours after publishing your DMARC record.
Unrecognised source IPs
Not every unfamiliar IP in your reports is an attacker. Common causes include:
- Email forwarding services that relay messages on behalf of recipients
- Mailing lists that re-send your emails to subscribers
- Forgotten SaaS tools that were authorised to send email but were never added to SPF
- Genuine spoofing attempts that should be blocked once you reach enforcement
Use reverse DNS lookups and IP range lookups to identify the owner of each source IP before taking action.
Report volume overwhelming your mailbox
Domains with high email volume can receive hundreds of aggregate reports per day. Sending these to a regular mailbox quickly becomes unmanageable. A dedicated DMARC reporting tool parses the XML automatically and presents the data in a visual dashboard, making it practical to monitor multiple domains at scale.
DMARC Reporting Tags Quick Reference
| Tag | Purpose | Example |
|---|---|---|
| rua= | Where to send aggregate reports | mailto:dmarc@example.com |
| ruf= | Where to send forensic reports | mailto:forensic@example.com |
| fo= | When to generate forensic reports | 1 |
| ri= | Reporting interval in seconds (default 86400 = 24 hours) | 86400 |
Check Your DMARC Record Now
Not sure if your domain has DMARC reporting configured? Use our free DMARC Checker to see your current DMARC record, including whether RUA and RUF tags are present and correctly formatted. If you need to create or update your record, use our DMARC Generator to build a valid record with the right reporting tags.
For a broader view including SPF, SSL, DNSSEC and domain registration across your primary and alternate domains, try our Security Grade.
Need Automated Report Parsing?
Reading raw XML reports is fine for a single domain, but it does not scale. ShieldMarc automatically ingests your DMARC aggregate reports, parses them, and gives you a visual dashboard showing sending sources, pass/fail rates, and alignment trends over time.
Sign up for ShieldMarc to start parsing your DMARC reports automatically. Free tier available.
Frequently asked questions
How do I interpret an aggregate DMARC XML report?
Read the report in three sections. First, the report_metadata section tells you who generated the report (for example google.com) and the reporting period as start and end timestamps. Second, the policy_published section shows the DMARC record the receiver found in your DNS at the time, including your policy (p=), subdomain policy (sp=) and alignment modes. Third, each record row groups mail by a unique combination of source_ip, count (how many messages from that IP), disposition (what the receiver did: none, quarantine or reject) and the SPF and DKIM results. Walk each row, match the source IP to a service you recognise, and check whether SPF and DKIM aligned. The aggregate report format was originally defined in RFC 7489 and is now specified in RFC 9990 (DMARC Aggregate Reporting), part of DMARCbis. If reading raw XML by hand is impractical, our DMARC report viewer decodes a report into a readable table.
How do I find out who is spoofing my domain?
Your aggregate DMARC reports list every source IP that sent mail claiming to be from your domain, so spoofers show up there. Reconcile your known senders first: match each source IP to a service you authorised (your mail platform, CRM, marketing tool and so on). The likely spoofers are the high-volume sources you do not recognise that fail both SPF and DKIM alignment, because legitimate senders almost always pass at least one. Treat unfamiliar IPs with care, since forwarders and mailing lists can also fail alignment without being malicious, so confirm before acting. Once you reach p=reject, those unauthenticated messages are blocked. Aggregate reports cover direct domain abuse; for attackers using similar-looking domains instead of yours, see our guide on lookalike domain protection. DMARC reporting was originally specified in RFC 7489, obsoleted in May 2026 by DMARCbis: the core DMARC spec is now RFC 9989, with aggregate reports covered by RFC 9990.
What is a DMARC report?
A DMARC report is a daily summary that mailbox providers like Google, Microsoft and Yahoo send back to you, listing every email they saw claiming to be from your domain and whether it passed SPF and DKIM. There are two types: aggregate reports (rua=), which are XML summaries sent daily, and forensic reports (ruf=), which are per-message failure reports.
What is the difference between DMARC RUA and RUF?
RUA reports are aggregate XML summaries sent once a day, grouping email by source IP and authentication result. RUF reports are per-message forensic reports generated when an individual email fails DMARC, containing the actual headers. Most major providers (Google, Microsoft, Yahoo) do not send RUF reports due to privacy concerns, so RUA is your primary data source.
Why am I not receiving any DMARC reports?
Check that your DMARC record has a valid rua=mailto: tag and that the mailbox exists. If the rua= address is on a different domain from your main domain, you need to publish an external authorisation DNS record at yourdomain.com._report._dmarc.othermaildomain.com with the value v=DMARC1. Also check your spam folder and allow at least 48 hours after publishing.
How do I read a DMARC XML report?
Each aggregate report contains three sections: report metadata (who sent it and when), policy_published (the DMARC record seen in DNS), and one or more record rows. Each row shows a source IP, a message count, the disposition applied (none, quarantine, or reject), and whether SPF and DKIM passed. Focus on source_ip, count, and the SPF and DKIM results to identify legitimate senders and spoofers.
What does fo=1 mean in a DMARC record?
The fo= tag controls when forensic reports are generated. fo=0 (the default) only generates a report if both SPF and DKIM fail alignment. fo=1 generates a report if either SPF or DKIM fails alignment and is the recommended setting when you want detailed failure visibility. fo=d triggers on DKIM signature failure and fo=s on SPF evaluation failure.
How long does it take to go from p=none to p=reject using DMARC reports?
There is no fixed timeline: the gate is report cleanliness, not the calendar. Use aggregate reports to identify every legitimate sender, fix their SPF or DKIM configuration, move to p=quarantine for a monitoring period, then step up to p=reject once reports show every authorised sender aligning. A simple setup with one or two services can progress quickly; estates with dozens of SaaS senders take longer because each new sender needs fixing first. We do not recommend ramping the pct= tag as a rollout strategy, because it samples mail randomly and delays nothing useful. DMARCbis removes the pct= tag entirely (Appendix A.6 of RFC 9989), which reinforces the report-driven approach described here.
What does RUA stand for in DMARC?
RUA stands for Reporting URI of Aggregate reports. It is the DMARC tag (rua=) that names the address (or addresses) where receiving providers send their daily aggregate XML reports: the summary of every message they saw claiming to be from your domain. Point rua= at a mailbox you control, or at a platform that parses the reports for you. ShieldMarc gives you a dedicated rua address and turns the raw XML into readable dashboards, free for your first domain.
What does RUF stand for in DMARC?
RUF stands for Reporting URI of Forensic reports, also called failure reports. It is the DMARC tag (ruf=) that names the address where receivers send per-message failure detail when a message fails authentication. In practice, Google, Microsoft and Yahoo rarely or never send RUF reports for privacy reasons, so aggregate (rua) reports remain your primary data source. Point ruf= only at an endpoint equipped to parse and store the message content safely.