How often do DMARC reports arrive?

Aggregate (RUA) reports are sent once per day by each participating receiver, so a domain with many senders will get several separate reports daily — one per reporting organization. Failure (RUF) reports, where they are sent at all, are near-real-time per-message samples, but you should not expect them from major providers. Plan your review around the daily aggregate cadence.

Do I need a paid tool to read DMARC reports, or can I use the raw XML?

You can technically open the XML yourself, but it does not scale past a couple of sources and is easy to misread. A report reader or monitoring service aggregates reports from every receiver into one sender view, tracks changes over time, and flags failures — which is what makes it practical to reach enforcement. The raw file is fine for a one-off spot check, not for ongoing management.

Should I turn on RUF (failure) reports?

Only if you have a specific reason and a privacy-aware place to send them. Because forensic reports can contain message content and recipient data, most large receivers do not send them, so enabling ruf= adds little coverage. For nearly all domains, aggregate reports provide everything needed to reach and maintain enforcement.

My reports are clean but mail still lands in spam — why?

DMARC reports only tell you about authentication and alignment; they say nothing about content, sending reputation, list hygiene, or blocklist status. A domain can pass DMARC perfectly and still be filtered for other reasons. Passing DMARC removes authentication as a cause, but deliverability depends on the broader picture — reputation, engagement, and infrastructure.

How long should I read reports before moving to enforcement?

Read them for at least one full sending cycle — long enough to see every legitimate source appear, including monthly or quarterly senders like invoicing or annual notices. Confirm each passes SPF or DKIM and aligns, fix any that do not, then move from none to quarantine and finally reject in stages.

Back to Resources Email News

How to Understand DMARC Reports

By Samuel ChenardAugust 9, 2023Updated August 13, 202610 min read

Ask AI to explain

In brief

Email delivery is crucial for businesses to communicate effectively with their customers, partners, and employees.

DMARC reports are how you see who is actually sending email as your domain — legitimate services, forgotten tools, and outright spoofers alike. Reading them is the whole point of starting at a monitoring policy: they tell you which senders still need fixing before you tighten enforcement and risk blocking your own mail. This guide covers the two report types, the fields that matter, and how to troubleshoot the problems you will hit.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is an email authentication protocol that builds on SPF and DKIM. Its reporting channel is what turns authentication from a guess into a measurable process.

That visibility is often missing: the State of DMARC 2026 research found that 21.0% of domains with a valid DMARC record published no aggregate-reporting address at all.

The two DMARC report types

DMARC reports come in two forms, and they answer different questions.

Side-by-side comparison of DMARC aggregate reports and failure (forensic) reports.

The two DMARC report types and what each tells you about your domain's email.

Aggregate reports (RUA) are daily XML summaries of every source that sent mail claiming to be from your domain, grouped by sending IP with pass/fail counts for SPF, DKIM, and alignment. They contain no message content — just statistics — which is why receivers send them freely. This is where nearly all practical work happens: aggregate reports are how you discover forgotten senders such as a billing platform, a helpdesk, or a marketing tool before you enforce.
Failure reports (RUF), also called forensic reports, are near-real-time samples of individual messages that failed authentication, including message headers and sometimes body content. In practice you should not count on receiving them: because that content can contain personal data, the major receivers — Google, Microsoft, and Yahoo among them — generally do not send RUF reports at all. Treat RUF as an optional extra that only fires from a minority of senders, not a stream you can rely on.

The takeaway: build your process around aggregate reports, and only enable ruf= if you have a dedicated, privacy-aware processor ready to receive the occasional sample.

If you want to keep aggregate-report processing in infrastructure you control, compare open-source DMARC analyzer operating models before choosing a parser.

Understanding the DMARC tags behind reporting

Your DMARC record — a TXT record at _dmarc.yourdomain.com — controls both policy and where reports go. Three tags matter most when you are reading reports:

p sets the enforcement policy the receiver applies to failing mail: none (take no action, just report), quarantine (deliver to spam/junk), or reject (refuse outright). This is the value you will see echoed back in every report's policy published section.
rua names the address that should receive aggregate reports, written as a mailto: URI (for example, rua=mailto:dmarc@yourdomain.com). This is the tag that actually produces the data you will read day to day.
ruf names the address for failure reports. Given how rarely major receivers send them, most organizations omit this tag or point it at a dedicated inbox.

To build or correct a record, the DMARC record generator walks you through valid tag syntax, and how to create a DMARC record covers the safe rollout order.

Reading a DMARC aggregate report

Aggregate reports arrive as XML, which is meant for a machine, not your eyes. The fastest path is to feed the file to a report reader that renders it as a sender table. But it helps to know what the underlying sections mean so the rendered view makes sense.

Six steps for reading a DMARC XML report, from opening the file to investigating failures.

Follow these steps each time you review a DMARC XML report.

Open the report. It usually arrives as an XML attachment (often gzipped) or through a monitoring dashboard.
Read the report metadata. The header names the reporting organization, the date range covered, and your domain — context that tells you which report you are looking at.
Check the policy published. This section shows the DMARC policy the receiver saw for your domain (none, quarantine, or reject) and any subdomain policy, confirming your record was read as you intended.
Work through the record rows. Each row is a sending source: its IP address, the message count, the SPF and DKIM results, whether each aligned with your From: domain, and the disposition (what the receiver did).
Identify the sources. Match each IP to a service you recognize. Familiar senders that pass are fine; unfamiliar IPs are either shadow IT or spoofing, and both need explaining.
Investigate the failures. For any source that failed alignment, work out why — a missing DKIM signature, an SPF record that does not list the sender, or a genuine forgery — and fix or block accordingly.

The single most important field is alignment. DMARC needs only one of SPF or DKIM to pass and align with the visible From: domain — not both. A source showing SPF fail but DKIM pass is still a DMARC pass.

What the disposition and policy values tell you

Every report echoes the policy you published, and the disposition column shows what the receiver actually did: none took no action (pure monitoring), quarantine sent failing mail to spam, and reject refused it outright. The standard path is none → quarantine → reject, tightening only once your reports are clean. Reports are what make each step safe; for choosing between the last two, see DMARC reject vs quarantine. Skipping the monitoring phase is the most common way to enforce DMARC and accidentally block your own mail.

Common issues when reading DMARC reports

Most of the trouble people hit with reports comes from a handful of predictable causes. Here is how to recognize and fix them.

I'm not receiving any reports

Three things cause silence. First, check rua syntax: the address must be a full mailto: URI, and a typo means no delivery. Second, if reports go to an address on a different domain than the one being reported on, that receiving domain must publish an authorization record (a TXT record at yourdomain._report._dmarc.receiver.com with v=DMARC1) or receivers will refuse to send. Third, give it time — reports are daily, and a brand-new record or a domain that simply sends very little may take a day or two to produce anything. Confirm your record is live and correct with the DMARC checker.

The XML is unreadable

That is expected. Aggregate reports are structured for a parser, not a person, so raw XML full of and tags will always look dense. Do not try to read it by hand — load the file into a DMARC report reader or monitoring service, which turns the XML into a plain sender-by-sender table with pass/fail counts.

A legitimate sender shows SPF fail but DKIM pass — is that a problem?

No. DMARC passes as long as one mechanism passes and aligns, so a source with SPF fail and DKIM pass (aligned) is a clean DMARC pass. You only need to act when both SPF and DKIM fail or fail to align. It is still worth understanding why SPF failed, but it is not blocking your mail.

Forwarded mail shows as failing

Forwarding breaks SPF: when a message is relayed, the forwarding server's IP is not in your SPF record, so the SPF check fails. DKIM, however, travels with the message and usually survives forwarding intact. As long as your mail is DKIM-signed and aligned, DMARC still passes through forwarders and mailing lists. If forwarded mail is failing outright, the fix is almost always to get DKIM signing working — see fixing SPF alignment for DMARC.

Reports show a source I don't recognize

Decide whether it is shadow IT or spoofing. Look up the IP with a DNS lookup and see who owns it: if it resolves to a known email platform (a CRM, a survey tool, a payroll system) that a team signed up for without telling IT, that is shadow IT — authorize it by adding it to SPF or enabling DKIM. If the IP belongs to unrelated or offshore hosting and the mail is failing authentication, treat it as spoofing — which is exactly what an enforced DMARC policy is there to block.

How reports fit into email authentication

DMARC does not authenticate anything on its own. It evaluates the results of SPF and DKIM against the From: domain, then applies your policy. Reports simply record, source by source, whether those checks passed and aligned — which is why fixing a failing sender always comes back to correcting its SPF or DKIM setup. You can see all three mechanisms for your domain at once with the Email Security Score, or check a single record with the SPF and DKIM tools.

Reviewed on a regular cadence, DMARC reports keep your authentication honest: they surface new senders, catch broken configurations before they hurt deliverability, and give you the evidence to move confidently from monitoring to full enforcement.

A note on the standard: for its first decade DMARC was defined by RFC 7489. In 2026 the IETF published the DMARCbis revision as RFC 9989 (core protocol), RFC 9990 (aggregate reporting), and RFC 9991 (failure reporting), which obsolete RFC 7489. This is a clarification with no breaking changes — the reports and tags described here keep working exactly as before.

For a provider-specific implementation of these authentication checks, see Why DMARC Fails and How to Fix It.

For a provider-specific implementation of these authentication checks, see What are Gmail and Yahoo error codes and how can I fix them?.

Questions readers ask

Frequently asked questions

Turn DMARC findings into a managed fix path

Start in Palisade.

Get started

Share this article

Written by

Samuel Chenard

CEO & Co-Founder, Palisade

Samuel Chenard is the CEO and co-founder of Palisade, AI-first DMARC software for IT teams and MSPs, from one domain to thousands.