Email Security8 min read

How to Set Up DMARC Aggregate Reporting (rua=)

Publishing a DMARC policy without a reporting address gives you enforcement with no visibility. This guide adds the rua= mailbox, handles cross-domain authorisation, and confirms reports are actually arriving.

A DMARC record without a rua= tag is a policy with no feedback. Receivers will enforce it, but you will never learn which of your senders are failing until someone complains that their mail vanished. Adding aggregate reporting is a small change — one tag, one mailbox — and it is what turns DMARC from a guess into a measurement. This guide covers the mailbox, the record change, the cross-domain authorisation step that silently breaks most vendor setups, and how to confirm reports are genuinely arriving.

Prerequisites

You need an existing DMARC record and the ability to edit DNS for your domain. If you have not published one yet, start with How to Configure DMARC — publish p=none first, add reporting here, and only then consider enforcement.

Step 1: Decide Where Reports Should Land

Aggregate reports arrive as ordinary email with a compressed XML attachment. Volume scales with how many receivers see your mail — a small domain gets a handful a day, a large one gets hundreds. Three workable destinations:

  • A dedicated mailbox on your own domain — dmarc@example.com. Simplest option, no authorisation record needed, and you keep the raw files.
  • A distribution list or shared mailbox — works the same way, and survives people leaving the team.
  • A third-party analytics platform — they give you an address on their domain, which requires the extra authorisation step in Step 4.
Do not use a personal inboxReports are machine-generated, arrive daily from dozens of senders, and are unreadable without tooling. Sending them to a person's inbox guarantees they get filtered, ignored, or lost when that person changes role. Create a dedicated mailbox even if only one person reads it.

Step 2: Create the Mailbox

Create dmarc@example.com as a real mailbox — not an alias that forwards elsewhere, since forwarding can complicate retrieval later. Then make sure it can actually receive:

  • Confirm the domain's MX records resolve and accept mail for that address.
  • Relax spam filtering for it. Bulk XML attachments from unfamiliar senders is close to a textbook spam profile, and reports landing in Junk is one of the most common "no reports arriving" causes.
  • Allow ZIP and GZ attachments. Some corporate policies strip them by default.
bash
# Confirm mail can be delivered to the domain at all dig +short MX example.com # Confirm the address accepts mail (expect 250 on RCPT TO) swaks --to dmarc@example.com --from test@example.net --server mx.example.com

Step 3: Add the rua Tag to Your DMARC Record

Look up what you currently publish, then add rua= to it. Everything else stays as it is.

bash
# What is published now dig +short TXT _dmarc.example.com "v=DMARC1; p=none"

Add the reporting address:

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

In your DNS provider, this is a TXT record with host _dmarc and the above as its value. Some options worth knowing:

text
# Two destinations — your mailbox and a vendor rua=mailto:dmarc@example.com,mailto:reports@vendor.example # Skip reports over 10 MB (rare, but avoids attachment-size bounces) rua=mailto:dmarc@example.com!10m # Request 6-hourly reports — advisory only, most receivers still send daily v=DMARC1; p=none; rua=mailto:dmarc@example.com; ri=21600
Reporting is safe at any policyAdding rua= changes nothing about delivery. It is purely additive, so there is no risk in adding it to an existing p=reject record — and if you are enforcing without reports, you should add it today.

Step 4: Authorise Cross-Domain Reporting

This is the step that quietly breaks vendor setups. If the rua address is on a different organizational domain from the DMARC record, the receiving domain must publish a record confirming it consents to receiving your reports. Without it, conforming receivers discard the reports and send nothing — with no error anywhere.

The record lives on the destination domain and is named after your domain:

text
# You publish: _dmarc.example.com -> rua=mailto:reports@vendor.example # Vendor publishes: example.com._report._dmarc.vendor.example. IN TXT "v=DMARC1"

Reputable DMARC platforms create this automatically when you add a domain to their dashboard, but it is worth verifying rather than assuming:

bash
dig +short TXT example.com._report._dmarc.vendor.example "v=DMARC1" # present — reports will be accepted # empty output means reports are being dropped

Sending to an address on your own domain — or any subdomain of it — needs none of this. It is one good reason to start with your own mailbox before adding a vendor.

Step 5: Verify the Record Parses

A syntax error means no reports and no warning. Check the published record before you start waiting:

bash
dig +short TXT _dmarc.example.com # Expect exactly ONE line starting v=DMARC1. # Two records = broken; receivers treat the domain as having no policy. dig +short TXT _dmarc.example.com | grep -c DMARC1

Common mistakes at this point, all of which produce a record that looks fine:

  • rua=mailto: dmarc@example.com — a space after the colon invalidates the URI.
  • rua=dmarc@example.com — the mailto: scheme is required.
  • rau= — a typo. Unknown tags are ignored silently, so reporting is simply off.
  • Smart quotes pasted from a document instead of ASCII quotes.
  • The host field set to _dmarc.example.com in a provider that already appends the domain, producing _dmarc.example.com.example.com.

The DMARC Lookup tool resolves the record and flags syntax problems without you having to eyeball it.

Step 6: Wait, Then Confirm Reports Arrive

The first reports land within 24 to 72 hours. They only come from receivers that actually saw mail from your domain, so a domain sending very little may wait longer.

Reports have a machine-readable subject line:

text
Subject: Report Domain: example.com Submitter: google.com Report-ID: 4829174726351928374 Attachment: google.com!example.com!1753574400!1753660799.zip

The filename encodes the reporting receiver, your domain, and the Unix start and end timestamps of the window. If nothing has arrived after 72 hours, work through these in order:

  1. Check the Junk folder — the single most common cause.
  2. Re-check the published record with dig; a typo disables reporting silently.
  3. If the destination is another domain, verify the _report._dmarc record exists.
  4. Confirm the mailbox accepts ZIP and GZ attachments.
  5. Confirm your domain is actually sending mail — no traffic means no reports.

Step 7: Read the First Report

Unpack the attachment and take a look before deciding on tooling:

bash
unzip -o 'google.com!example.com!1753574400!1753660799.zip' # Sources and volumes at a glance grep -oP '(?<=<source_ip>)[^<]+' *.xml | sort | uniq -c | sort -rn # Total messages covered by this report grep -oP '(?<=<count>)[0-9]+' *.xml | paste -sd+ | bc

Raw XML is fine once and tiresome by the third day. Load the file into the DMARC Report Analyzer for a readable table of sources, alignment and disposition, and see How to Read Your DMARC Reports for how to interpret each column.

Reports describe yesterdayAggregate reporting is a measurement tool, not an alerting system. A live incident will not appear for hours. If you need real-time signal, that comes from your own outbound logs, not from DMARC.

Step 8: Make It a Habit

The point of reporting is to reach enforcement safely and stay there. A sustainable routine:

  • Weekly during rollout — inventory every source, chase down anything unfamiliar, and fix alignment until legitimate senders show an aligned pass.
  • Monthly once at p=reject — new SaaS tools get adopted without anyone telling you, and each one can start silently bouncing.
  • Keep the mailbox even if you later add a vendor. Raw reports are your fallback if the vendor relationship ends.

Once reports are flowing and you can account for every sender, the next step is rolling out enforcement.

Frequently Asked Questions

How long until the first report arrives?

Usually 24 to 72 hours. Receivers batch a full day of data before sending, and they only report on mail they actually received — so a low-volume domain may see nothing for several days simply because no reporting receiver got mail from it.

Can I send reports to more than one address?

Yes. rua accepts a comma-separated list, and a common setup is one mailbox you control plus one analytics vendor. Each address on an external domain needs its own _report._dmarc authorisation record.

Do I need a paid DMARC monitoring service?

Not to get started. A dedicated mailbox and an analyzer will carry a small or medium domain through a full rollout. Paid platforms earn their place at scale — many domains, long retention, trend alerting — rather than by revealing anything the XML does not already contain.

Will enabling reporting affect my email delivery?

No. The rua tag only tells receivers where to send statistics. Delivery is governed by p= and the authentication result, neither of which reporting touches.

Why do I get reports from providers I have never sent mail to?

Because someone is sending mail that claims to be from your domain and it reached them. That is exactly the signal DMARC exists to surface — check whether those sources are a forgotten legitimate sender or an actual spoofing attempt.

Should I also set up ruf forensic reporting?

Usually not. Google and Microsoft do not send forensic reports, so the tag often yields nothing, and what does arrive contains third-party recipient addresses and message content. See RUA vs RUF for the trade-off in full.

Related