If you set up DMARC on your domain, you probably started receiving a DMARC report every day soon after: an email from Google, Microsoft, Yahoo or another mail provider with a compressed XML file attached and no explanation. Multiply that by several domains and several receivers and your inbox fills with files nobody opens.

Those reports are useful at the right moment and noise the rest of the time. This guide explains what they are, how to read one, what to look for, and how to stop getting them when you no longer need them.

Where DMARC reports come from

Your DMARC record lives in DNS at _dmarc.yourdomain.com. Two optional tags in that record ask receivers to send you reports:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com; ruf=mailto:dmarc-fail@example.com"
  • rua is the address for aggregate reports. These are summaries, usually sent once a day by each receiving provider that saw mail claiming to be from your domain.
  • ruf is the address for failure reports (sometimes called forensic reports). These describe individual messages that failed.

Nothing in DMARC requires either tag. Your policy (p=none, quarantine or reject) works the same with or without them. The tags only control whether you get feedback.

Aggregate reports (rua)

Aggregate reports are XML files, usually zipped or gzipped. Each one covers a time window and lists, for every sending IP address the receiver saw using your domain: how many messages it sent, whether SPF and DKIM passed, whether they aligned with your From domain, and what the receiver did with them. No message content or recipient addresses are included.

Failure reports (ruf)

Failure reports are per-message and can include headers, subject lines and recipient addresses, which raises privacy concerns. Many large receivers do not send them at all. Gmail, for example, has never sent them. In practice most of what you learn comes from aggregate reports.

Sending reports to another domain

If the rua address is on a different domain from the one being reported on (for example, a reporting service's domain), the receiving domain must publish a verification record such as example.com._report._dmarc.reportingservice.com with the value v=DMARC1. Reporting services set this up on their side. If it is missing, receivers skip sending the reports.

How to read an aggregate report

Unzip the attachment and open the XML in a browser or text editor. The structure is the same from every provider:

<feedback>
  <report_metadata>
    <org_name>google.com</org_name>
    <date_range><begin>1760313600</begin><end>1760399999</end></date_range>
  </report_metadata>
  <policy_published>
    <domain>example.com</domain>
    <p>none</p>
  </policy_published>
  <record>
    <row>
      <source_ip>203.0.113.25</source_ip>
      <count>412</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers><header_from>example.com</header_from></identifiers>
    <auth_results>
      <dkim><domain>example.com</domain><result>pass</result></dkim>
      <spf><domain>bounces.vendor.com</domain><result>pass</result></spf>
    </auth_results>
  </record>
</feedback>

Read it in this order:

  1. report_metadata tells you who sent the report and the time window. Dates are Unix timestamps.
  2. policy_published shows the DMARC record the receiver found. If it does not match what you think you published, you have a DNS problem.
  3. Each record is one sending source. source_ip and count tell you who sent how much.
  4. policy_evaluated shows the DMARC verdict: whether DKIM and SPF passed in an aligned way, and the disposition (none, quarantine or reject) the receiver applied.
  5. auth_results shows the raw SPF and DKIM results and which domain they passed for.

The example above is a common and healthy case: a marketing platform's mail where SPF passed for the vendor's bounce domain (so it did not align), but DKIM passed for example.com. Because DKIM aligned, DMARC passed.

What to look for

  • Legitimate sources failing. A known IP or vendor with DKIM and SPF both failing alignment is a sender you have not authenticated yet. This is the main reason to read reports before tightening your policy. Our guide to SPF, DKIM and DMARC for third-party senders covers how to fix each one.
  • Unknown sources. IPs you do not recognize sending as your domain are either a forgotten tool or someone spoofing you. A reverse DNS lookup on the IP usually tells you which.
  • Forwarding noise. Mail forwarded through mailing lists or university and alumni addresses often fails SPF and sometimes DKIM. Small counts from these sources are normal and not worth chasing.
  • Disposition changes. After you move to quarantine or reject, check that the only sources being quarantined or rejected are ones you want blocked.

Reading raw XML works for one domain and a few days. For anything more, use a report-processing service that parses the files and shows you a dashboard by source. Several DMARC vendors offer this, and many have free tiers for low volumes. Pricing and limits change, so check current plans.

How to stop receiving DMARC reports

Once a domain is stable (every legitimate sender authenticated, policy at quarantine or reject, nothing new in the reports for weeks), the daily emails stop telling you anything. You have three options.

Option 1: remove the rua tag

Edit the DMARC TXT record and delete the rua= tag (and ruf= if present). Keep everything else.

Before:

v=DMARC1; p=reject; rua=mailto:dmarc@example.com

After:

v=DMARC1; p=reject

Your policy keeps working exactly as before. Receivers still check SPF, DKIM and alignment and still quarantine or reject failures. They simply stop emailing you about it. Reports already in flight may arrive for a day or two while DNS caches expire, then they stop.

This is what we did on our own domains. We manage several domains with a mix of Microsoft 365 and Google Workspace mailboxes plus marketing and form senders. Once SPF, DKIM and DMARC were in place and the domains were stable, we removed the rua address because the daily XML files had become noise.

Option 2: point rua at a reporting service

If you want visibility without the inbox clutter, change the rua address to one provided by a DMARC report-processing service. The reports go to the service, it parses them, and you get a dashboard and alerts for new or failing sources instead of raw attachments.

v=DMARC1; p=reject; rua=mailto:yourid@reports.dmarcvendor.example

The service handles the external destination verification record on its side.

Option 3: route them away from people

If you want to keep the raw data but not see it, point rua at a dedicated mailbox or alias that nobody reads day to day, and filter it into an archive folder. This keeps the history available if you ever need to investigate.

What not to do

Do not delete the whole DMARC record to stop the reports. That removes your policy, and Gmail, Yahoo and Microsoft require a DMARC record for higher-volume senders. Also do not use a mailbox rule to auto-delete reports while assuming everything is fine. If you want them gone, change the record so the decision is deliberate.

The tradeoff

Turning off reports means you lose your early warning. If marketing adds a new platform next quarter and nobody authenticates it, a p=reject policy will block its mail, and without reports you will hear about it from a customer instead of a dashboard. The same goes for spoofing attempts: your policy still blocks them, but you will not see them.

Our rule of thumb: keep reports on, ideally through a processing service, while you are moving from p=none to enforcement and whenever you add a new sending tool. Turn them off when the domain is at enforcement and stable, and turn them back on temporarily before any change to how you send email. For parked domains that send no mail, reports add little value at all, as long as the domain has a strict policy (v=DMARC1; p=reject) and an SPF record of v=spf1 -all.

A note on standards: DMARC was updated by the IETF in 2026 (RFC 9989, with aggregate and failure reporting moved into separate documents). The rua and ruf tags still work as described here, and existing v=DMARC1 records do not need to change.

Getting help

Reading reports and deciding when to tighten policy is part of our email and domain security service. We get every sender passing, move the domain to enforcement, and then set up reporting the way you want it: a dashboard, a quiet archive, or off.

Frequently asked questions

Will removing rua weaken my email security?

No. The rua tag only controls where reports are sent. Your DMARC policy, and the protection it gives against spoofing, stays fully in effect. What you lose is visibility into what is being blocked.

Why am I getting DMARC reports from companies I have never emailed?

Any provider that receives mail claiming to be from your domain can send a report, including mail forwarded by your recipients and spoofed mail sent by someone else. Reports come from the receiving side, not from people you emailed directly.

How often do DMARC reports arrive?

Most large receivers send aggregate reports once a day per domain. With several domains and several receivers, that adds up to many emails a day, which is why most companies send them to a processing service or a dedicated mailbox.

Do I need ruf failure reports?

Usually not. Many major receivers do not send them, and those that do may redact them for privacy. Aggregate reports cover what most businesses need.

How do I know my change worked?

Look up the record with any DNS lookup tool and confirm the rua tag is gone or changed. Expect a day or two of stragglers while caches expire.