DMARC rua: Where Aggregate Reports Go, and Why Yours May Not Arrive

A DMARC record without a rua= is a policy with no feedback loop: the policy still runs, and it never tells you anything.

The rua tag is the list of addresses where receiving mail providers send your daily aggregate reports. rua stands for Reporting URI for Aggregate reports, and its presence is what asks for feedback at all: RFC 9990 §3.4 states that the presence of the rua tag specifies where to send feedback, and RFC 9989 §4.7 makes the converse normative — if the tag is not provided, Mail Receivers MUST NOT generate aggregate feedback reports for the domain. No rua=, no reports.

Two readers land here: one published DMARC months ago, has never seen a report, and cannot tell a healthy silence from a broken one; the other published a rua= and still gets nothing back.

Below: what your record is doing now, where rua= should point, the DNS record a third-party destination needs, and the ranked reasons a published rua= goes quiet. For how DMARC itself works, start there first.

What is the DMARC rua tag?

rua= is the DMARC tag that tells receiving mail providers where to email your aggregate reports. It holds a comma-separated list of mailto: URIs and is defined as a dmarc-urilist in RFC 9989 §4.8. Receivers discover it when they look up the DMARC record for a message’s From domain (RFC 9990 §3.4).

RFC 9989 §4.7 permits any valid URI, but a receiver only has to support mailto: and MUST ignore schemes it does not support — so in practice every working rua URI is a mailto:. Two separators then do different jobs, and this is the part of the DMARC rua tag that catches people out: semicolons separate DMARC tags, commas separate addresses inside one tag. A minimal record reads v=DMARC1; p=none; rua=mailto:dmarc@example.com.

One behaviour almost nobody documents: a valid rua keeps a partly broken record alive. RFC 9989 §4.10.1 says that if a retrieved record does not contain a valid p tag but a rua tag is present with at least one syntactically valid reporting URI, the receiver MUST act as if p=none was retrieved and continue processing. With neither, it applies no DMARC processing to the message at all.

The full tag grammar and how to publish a DMARC record for the first time are covered separately. This page starts after that.

Does your DMARC record actually have a rua?

Look at the record itself. Query _dmarc.yourdomain.com for its TXT record and check whether the string contains rua=mailto:. If it does not, no receiver has ever generated an aggregate report for your domain, and none ever will while the tag is absent.

Run dig +short TXT _dmarc.example.com @1.1.1.1, substituting your own domain. Querying a resolver outside your own network shows you what receivers see rather than a split-horizon answer. There are three outcomes:

• No rua=. Nothing is being collected. The policy runs; the feedback loop does not exist.
• rua= on your own domain. Reports should arrive. If they do not, work the diagnostic further down.
• rua= on someone else’s domain. You also need the authorization record two sections below, or conforming receivers drop the URI.

That is a measurement of how the tag is used, not a verdict on those domains. Read it beside the enforcement figures from the same scan: 57.9% of DMARC domains sit at p=none. The composite picture is a large population that published a policy, left it in monitoring, and is not watching the monitoring.

Your own record takes seconds to settle — you can check whether your record publishes a rua= without signing up.

Where should the rua address point?

Point rua= at a mailbox or processor that can parse XML unattended: a dedicated address on your own domain, or a report processor. A person’s inbox works mechanically and fails operationally. RFC 9990 §9.2 says outright that the XML reports are not human readable in bulk.

In the same 2026-02-27 scan, 365,257 domains — 40.85% of the 894,057 publishing a rua= — point it at their own domain or a subdomain of it. Read that as an upper bound rather than a count of do-it-yourself setups: operators are grouped by hostname suffix, so that bucket also holds vendors who ask customers to publish a CNAME under their own domain.

The human-mailbox case is worth stating concretely, because the mechanics are fine and the outcome is not. One report per reporting provider per day arrives indefinitely, and a domain whose subdomains each generate their own reports multiplies that — on Cisco’s ESA, each subdomain without its own policy produced a separate report email, each counting against a 1,000-per-day cap (operator account, 2021; pre-dates the current specification, so read it as illustration). The end state in the documented thread is not anger. It is an abandoned mailbox and an accepted answer — “You can ignore the email or remove the email from the DMARC record in DNS” — which trades the noise for blindness.

Before you route reports to a person, look at what reading one actually involves.

Sending reports to another domain: the _report._dmarc record

If your rua= address is on a different organizational domain than the DMARC record, that destination domain must publish a TXT record granting permission — otherwise conforming receivers ignore the URI. RFC 9990 §4 defines the check: the receiver queries <your-domain>._report._dmarc.<destination-domain> and requires a record beginning v=DMARC1.

The reason the check exists is spelled out in the same section. Without it, a bad actor could publish a record pointing reports at a victim address, send a large volume of failing mail, and let the world’s receivers flood that address on their behalf.

What the receiver does is mechanical: take the host from the rua URI, prepend _report._dmarc, prepend the domain the policy was retrieved from, query TXT, and require a parseable record whose first tag is v=DMARC1. Where that fails to confirm authorization, the URI MUST be ignored.

; Zone file for reports.example.net - the DESTINATION domain.
; Neither record belongs in the policy domain's own zone.

; Named form: authorizes example.com, and only example.com, to have its
; DMARC reports delivered here. This is the exact name RFC 9990 Section 4
; tells the receiver to query.
example.com._report._dmarc.reports.example.net. IN TXT "v=DMARC1"

; Wildcard form: accepts reports for any policy domain. Report processors
; usually publish this one themselves, which is why most people pointing
; rua= at a vendor never create a record at all.
*._report._dmarc.reports.example.net. IN TXT "v=DMARC1"

A destination willing to receive reports for any domain publishes the wildcard form instead. A resolver cannot distinguish a synthesized wildcard answer from an explicit one, so checkers and report generators treat the two identically. Processors usually publish the wildcard themselves, which is why most people pointing rua= at a vendor never create anything — verify it resolves rather than assuming. dig +short TXT example.com._report._dmarc.reports.vendor.example should return a record beginning v=DMARC1. Our ARF checker runs this same lookup for ruf= destinations.

Now the trap, because this is where the diagnosis usually goes wrong. Enforcement of this check is not universal. OpenDMARC’s report generator does not perform it: the last documented state is a 2018-03-20 maintainer response on its issue tracker, and no public report of a fix has appeared since. So a partial trickle of reports can coexist with a validator warning that the destination is not authorized, and reading that trickle as proof the setup is correct is the single most common error here. Rspamd is not documented either way — no code path confirms either behaviour, so do not assume it skips the check.

Who receives DMARC reports, measured across 5.5M domains?

Across 5,499,028 Tranco domains scanned on 2026-02-27, 894,057 DMARC domains publish a rua=. The largest single destination is the domain’s own infrastructure, at 40.85%, and no commercial receiver exceeds 7.1%.

Four things bound what that table can tell you. It is a single scan taken on 2026-02-27. Tranco is a popularity-ranked sample, so these are shares of 5,499,028 Tranco domains and not of the internet. Operators are grouped by hostname suffix, so a vendor on an unrecognised hostname falls into the long tail and is undercounted, and the own-domain row includes vendors who ask customers to publish a CNAME under their own domain. And the count is per-domain, not per-message: a receiver with few domains may still process far more mail than one with many. A domain listing two operators counts in both rows, so the column does not sum to 100%.

For completeness: DMARCguard does not appear in the top 40 receivers in this scan.

The 15,242 domains in the last row route aggregate XML to a free consumer mailbox: the destination decision from the previous section, measured rather than argued. A separate post covers what actually arrives at whichever address you choose.

You published a rua= and nothing arrives

Work these in order. The most commonly reported fixable cause is a missing external-destination authorization record, and its symptom is inconsistent silence rather than total silence, because some report generators skip the check and send anyway.

1. Read the live record from an external resolver. Exactly one v=DMARC1 record, rua= present, value byte-for-byte as intended. Smart quotes pasted from a document and DNS-panel field wrapping are real causes.
2. Check the two-separator rule against the valid record and its three broken variants below. The failure is not uniform, so “it parses in one checker” is not dispositive — parse it in two.
3. Publish _report._dmarc if the destination is external, and do not read a partial trickle as evidence it is unnecessary. No dated public operator account, in any archive searched for this post, shows silence, then a published authorization record, then reports resuming with counts. The mechanism is documented; that before-and-after narrative is not. So use an observable signal: after publishing, watch whether new reporting organizations appear over the next two to three reporting cycles. If they do, the previous setup was hiding a whole class of traffic.
4. Prove the mailbox accepts large compressed attachments. Reports are ordinary email carrying a gzip attachment (RFC 9990 §3.5.2). Size the mailbox for a large one, remove .zip, .gz and .com extension filters, and read the inbound reject logs, not the inbox — the step most operators skip. One operator account, whose date could not be verified, traced missing Gmail reports to an Exim filter matching a .com rule. Malformed declarations happen upstream too: on 2024-07-25 the mailop list recorded 1&1 sending gzipped data labelled application/zip, breaking strict parsers.
5. Set coverage expectations per receiver. Microsoft 365 generates aggregate reports only when the domain’s MX points directly at Microsoft 365; a gateway in front means zero Microsoft reports, which Microsoft documents as intended behaviour and which sits alongside the rest of Microsoft’s DMARC enforcement rollout. “Google reports, no Microsoft” is usually this. Coverage is voluntary and partial, so treat a change in the set of reporters as the signal, not the size of the set.
6. Check the destination is mail-routable at all. A rua domain with no MX still looks like silence to you — the bounces accumulate in the reporting sender’s queue, not yours. No major receiver documents suppressing a persistently failing destination, and RFC 9990 §3.5 lets a receiver that cannot deliver simply discard the data, so resolve the destination’s MX (or A/AAAA fallback) yourself rather than waiting for a signal.

Step 2 is worth seeing rather than describing:

# VALID - semicolons separate tags, commas separate addresses
v=DMARC1; p=none; rua=mailto:dmarc@example.com,mailto:reports@example.net

# BROKEN 1 - the mailto: scheme is missing on the second address.
# That one destination is not a valid DMARC URI and is dropped. The rest of
# the record still parses, so reports keep arriving from the first address
# and the fault stays invisible.
v=DMARC1; p=none; rua=mailto:dmarc@example.com,reports@example.net

# BROKEN 2 - a comma is used where a semicolon belongs.
# The whole record misparses and ALL reporting stops.
v=DMARC1, p=none, rua=mailto:dmarc@example.com

# BROKEN 3 - a semicolon sits between two addresses inside one rua= tag.
# A tag value cannot contain a semicolon (RFC 9989 Section 4.8 ABNF), so the
# rua value ends at the first address and the second one is never used.
v=DMARC1; p=none; rua=mailto:dmarc@example.com;mailto:reports@example.net

If you generate reports yourself rather than only consuming them, two gotchas are specific to that setup: your OpenDMARC install does not enforce external-destination authorization, and your Rspamd install can generate reports about its own reporting domain unless you exclude that recipient.

Frequently Asked Questions

What is the rua tag in DMARC?

rua is the DMARC tag listing where receivers email your daily aggregate reports. It holds comma-separated mailto: URIs and is defined as a dmarc-urilist in RFC 9989, Section 4.8. Its presence is what requests feedback at all (RFC 9990, Section 3.4). Without it, no aggregate report is generated.

Why am I not getting any DMARC reports?

In order: the record has no rua=; the value is malformed (a missing mailto:, or a comma where a semicolon belongs, which breaks the whole record); the destination is on another domain and lacks the _report._dmarc authorization record; or the mailbox rejects the compressed attachment. Check inbound reject logs, not just the inbox.

Can I use my own email address for the DMARC rua tag?

It works mechanically, and it stops working the moment volume matters. Each reporting provider sends a gzipped XML file per day, and RFC 9990, Section 9.2 notes the reports are not human readable in bulk. Use a dedicated mailbox or a report processor: in a 2026-02-27 scan of 5,499,028 Tranco domains, 15,242 route aggregate XML to a free consumer mailbox instead.

Do I need a rua tag in my DMARC record?

DMARC enforces without it, but you see nothing: no senders, no alignment failures, no evidence the policy is safe to tighten. In a 2026-02-27 scan of 5,499,028 Tranco domains, 776,918 of 1,670,975 DMARC domains publish none. A valid rua also keeps a record with a broken p tag in play as p=none (RFC 9989, Section 4.10.1).

Can I put multiple addresses in the rua tag?

Yes. Separate addresses inside one rua= with commas; separate DMARC tags with semicolons. Getting those two backwards is a common cause of total reporting failure. Each address on an external domain needs its own _report._dmarc authorization, and conforming receivers send only to the authorized ones.

What to change today

Three things, in the order they pay off:

1. Check whether the record has a rua= at all. Nearly half of DMARC domains in the 2026-02-27 scan of 5,499,028 Tranco domains do not, and that is the whole explanation for their silence.
2. Point it at something that parses XML unattended, not at a person who will stop opening the attachments by week three.
3. If the destination is external, publish _report._dmarc — then watch for new reporting organizations rather than trusting the trickle you already have.

A DMARC rua tag is a one-line change that decides whether the rest of your DMARC work is measurable. Once the first report lands, the work shifts from collecting to reading.