How to Read DMARC Reports: A Guide to RUA and RUF (with examples)

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.

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:

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), or reject (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

Controlling forensic report detail with fo=

The fo= tag in your DMARC record controls when forensic reports are generated:

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:

1. Publish p=none with rua= to start collecting data without affecting mail delivery.
2. 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.).
3. Fix any failing senders. Ensure each legitimate service passes SPF (add their include to your SPF record) or DKIM (configure their signing domain).
4. 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.
5. Monitor for a few weeks and check that no legitimate emails are being quarantined.
6. 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.

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