---
title: "DMARC rua Tag: Are Reports Reaching You?"
description: "The DMARC rua tag decides whether you get aggregate reports at all. Where to point it, the _report._dmarc record, and why reports stop. Check yours free."
publishedAt: 2026-09-10
tags: ["dmarc", "rua", "dmarc-rua", "aggregate-reports", "rfc-9990", "dmarcbis"]
faq:
  - question: "What is the rua tag in DMARC?"
    answer: "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."
  - question: "Why am I not getting any DMARC reports?"
    answer: "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."
  - question: "Can I use my own email address for the DMARC rua tag?"
    answer: "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."
  - question: "Do I need a rua tag in my DMARC record?"
    answer: "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)."
  - question: "Can I put multiple addresses in the rua tag?"
    answer: "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."
---
# DMARC rua: Where Aggregate Reports Go, and Why Yours May Not Arrive

<TLDR>

The DMARC `rua` tag tells receiving mail providers where to email your aggregate
reports. If your `_dmarc` TXT record contains no `rua=`, nothing is being
collected and nothing will be — which describes 46.49% of DMARC domains in a
2026-02-27 scan of 5,499,028 Tranco domains. Point `rua=` at a mailbox or
processor that parses XML unattended, not at a person. If the address sits on
another domain, that domain must publish a `_report._dmarc` TXT record, and a
missing one is the first thing to check when reports stop.

</TLDR>

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](/learn/dmarc/), 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](https://www.rfc-editor.org/rfc/rfc9989.html) §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`.

| Tag     | What it asks for                       | What arrives                | If absent                                        |
| ------- | -------------------------------------- | --------------------------- | ------------------------------------------------ |
| `rua=`  | Aggregate feedback (RFC 9990)          | Daily gzipped XML summary   | No aggregate reports are generated               |
| `ruf=`  | Per-message failure reports (RFC 9991) | Individual failure samples  | No failure reports; most domains set only `rua`  |
| neither | Nothing                                | Nothing                     | Policy still applies; you see none of its effect |

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](/blog/how-to-create-dmarc-record/)
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.

<Figure
  src="/images/blog/dmarc-rua-collection/dmarc-rua-collection_is-it-collecting_flowchart.svg"
  alt="Flowchart deciding whether a DMARC record collects aggregate reports: no rua tag, rua on the same domain, or rua on an external domain"
  caption="Three outcomes from one TXT lookup. Only the external-destination branch needs a second record."
  width=860
  height=480
/>

<KeyStat
  stat="776,918 of 1,670,975"
  label="DMARC domains publish a policy with no rua= address — 46.49% ask for no aggregate reports at all"
  source="DMARCguard analysis of the State of Email Authentication 2026 scan — 5,499,028 Tranco domains, 2026-02-27"
  sourceHref="/research/email-authentication/"
/>

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=`](/tools/dmarc-checker/) 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.

<VerdictTable
  columns={["Destination", "What you get", "What it costs"]}
  rows={[
    [
      "Dedicated mailbox on your own domain",
      "Reports arrive with no extra DNS, and you hold the raw data",
      "You parse gzipped XML yourself (RFC 9990 §9.2)",
    ],
    [
      "A report processor on another domain",
      "Parsed, deduplicated data",
      "Needs the _report._dmarc authorization record unless the vendor wildcards it",
    ],
    [
      "A personal or shared human mailbox",
      "Mail you cannot act on",
      "A gzipped attachment per reporting receiver, every day",
    ],
    [
      "No rua= at all",
      "Nothing",
      "The policy runs with no feedback loop; 46.49% of DMARC domains in the 2026-02-27 scan of 5,499,028 Tranco domains",
    ],
  ]}
  verdict="Point rua= at a destination built to parse XML unattended. Whatever you pick, it must accept a large compressed attachment every day, indefinitely."
/>

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](/blog/how-to-read-dmarc-report/).

## 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](https://www.rfc-editor.org/rfc/rfc9990.html) §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.

<CodeBlock
  filename="DNS TXT records — published by the destination domain"
  lang="dns"
  code={reportAuthorization}
/>

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.

<Figure
  src="/images/blog/dmarc-rua-collection/dmarc-rua-collection_report-authorization_process.svg"
  alt="Diagram of the RFC 9990 external destination verification query name built from the policy domain and the report destination host"
  caption="The query name is assembled, not configured — which is why the record lives in the destination's zone, never yours."
  width=860
  height=570
/>

## 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%.

<DataTable caption="DMARC report destinations by operator — share of the 894,057 domains publishing a rua=, from a 2026-02-27 scan of 5,499,028 Tranco domains">

| Receiver                | Domains | Share of the 894,057 |
| ----------------------- | ------- | -------------------- |
| Own domain or subdomain | 365,257 | 40.85%               |
| Cloudflare              | 63,482  | 7.10%                |
| GoDaddy                 | 62,943  | 7.04%                |
| Valimail                | 44,781  | 5.01%                |
| Brevo                   | 39,544  | 4.42%                |
| Proofpoint              | 31,555  | 3.53%                |
| dmarcian                | 23,354  | 2.61%                |
| MXToolbox               | 19,566  | 2.19%                |
| Postmark                | 17,396  | 1.95%                |
| DMARC Analyzer          | 17,370  | 1.94%                |
| Free consumer mailboxes | 15,242  | 1.70%                |

</DataTable>

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](/blog/dmarc-aggregate-report/).

## 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](https://www.mail-archive.com/mailop@mailop.org/msg22653.html)
   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](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dmarc-configure)
   and which sits alongside the rest of
   [Microsoft's DMARC enforcement rollout](/blog/microsoft-dmarc-enforcement/).
   "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:

<CodeBlock
  filename="One valid rua= and three ways to break it"
  lang="dns"
  code={ruaMalformed}
/>

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.

<CTA
  title="Upload an aggregate report and read it without opening the XML"
  description="Once the first report arrives, drop the gzipped attachment into the free report analyzer. It parses the XML, groups the sending sources, and shows which ones fail alignment — no signup."
  label="Open the report analyzer"
  href="/tools/dmarc-report-analyzer/"
/>