Configuring the DMARC rua address (without getting tripped up)

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

v=DMARC1; p=none; rua=mailto:dmarc@example.com,mailto:reports@analytics-vendor.com

The trap: external destination authorization

Here's the rule many miss: sending DMARC reports to an address on a domain other than the sender's requires explicit authorization, published on the receiving domain's side.

Why? To prevent abuse. Without this rule, anyone could publish rua=mailto:victim@other-domain.com and dump (potentially large) reports onto a non-consenting third party. So DMARC requires the receiving domain to declare it accepts reports from another domain.

Concretely, if example.com sends its reports to dmarc@vendor.com, then the vendor.com domain must publish a TXT record on this precise name:

example.com._report._dmarc.vendor.com  IN TXT  "v=DMARC1"

Without this authorization record on vendor.com's side, receivers refuse to send the reports to that external address — leaving the domain owner wondering why nothing arrives. Serious DMARC analytics services handle this automatically (they supply the record to publish, or host it themselves). But a homemade forward to another in-house domain has to be set by hand. The failure mode here is quietly maddening: the DMARC record looks perfect, the syntax validates, and yet reports never appear — because the missing piece isn't in that record at all, but in a zone the owner may not even control. Knowing this rule exists is half the battle; the other half is remembering to check the receiving side whenever an external rua goes silent.

Conversely, as long as rua points to an address on the domain itself, no authorization is needed — which is why starting with dmarc@example.com is the simplest path.

Dedicated mailbox or analytics service?

Once reports are flowing, the next question is what to do with them. Two options.

• A dedicated mailbox. rua points at dmarc@example.com and the XML gets read by hand. Viable for a small, low-volume domain, but quickly unmanageable: reports are numerous, compressed, and painful to aggregate manually. It's a fine starting point to understand, not to operate over time.
• An analytics service. rua points (or copies) to a platform that ingests the XML and presents dashboards — sending sources, alignment rates, trends. It's the realistic choice as volume climbs. Market tools are compared in how to read a DMARC report: tools & method.

Either way, aggregate reports contain no message content — only statistical metadata — which makes them usable with no confidentiality concern, unlike forensic reports (ruf, see RUA vs RUF).

What to expect in volume

The flood takes many by surprise. Each major receiver (Gmail, Yahoo, Outlook, and dozens of others) sends one report per day as soon as it receives mail claiming to come from the domain. For an active domain, that's easily several dozen files daily. That's precisely why a dedicated address, and eventually an aggregation tool, beat a drowned personal inbox. And that volume is good news in disguise: the more reports arrive, the more complete the picture of who sends in the domain's name — each file is a mailbox provider reporting what it saw.

Optional settings: ri and size

Two advanced options exist, rarely needed at the start:

• ri= sets the desired interval between two aggregate reports, in seconds (default 86400, i.e. 24 h). Receivers aren't required to honor it finely; in practice, the daily rhythm dominates. The topic is covered in the DMARC reporting interval.
• Maximum size. A URI can be suffixed with a ! followed by a size (e.g. mailto:dmarc@example.com!10m) to ask not to exceed 10 MB per report. Useful for very large domains; superfluous for most.

A simple record at the start is the right call: p, rua, and the subdomain tags suffice. Fine options are added only when a concrete need shows up. In practice, nearly every domain lives happily without ever touching ri or the maximum size: receivers apply their own sensible defaults, and cluttering a record with these tags usually buys nothing but a longer line to re-read and maintain.

Decoding the external authorization record

Since that _report._dmarc record is the source of most "I get nothing" cases, it deserves detail, because its structure is confusing at first. The full name to publish reads left to right like a sentence: "the sending domain ._report._dmarc. the receiving domain." In our example, example.com._report._dmarc.vendor.com literally means: "vendor.com declares it accepts DMARC reports destined for example.com."

The value is minimal: "v=DMARC1" suffices in most cases. It's a simple consent flag, not a full policy. Two subtleties are worth knowing:

• The authorization lives at the receiver, not at the sender. This is a major source of confusion: a perfectly mastered DNS zone counts for nothing if the destination domain doesn't publish its authorization record — nothing arrives. That's why delegating reporting to a vendor that "handles everything" removes the ambiguity — the authorization is on their side, and they know how to set it.
• A wildcard exists. A receiver can publish a generic authorization (*._report._dmarc.vendor.com) to accept reports from any sending domain. Large analytics platforms use this to avoid creating one record per client. It's not something a sending domain has to set up itself; it's useful to recognize when auditing an existing setup.

Why a dedicated address, from day one

Many first point rua at their usual address "just to see," then regret it. Three reasons to create a dedicated address like dmarc@example.com from the start:

• Volume. As seen above, an active domain gets dozens of reports a day. In a personal inbox, they drown useful mail; in a dedicated one, they accumulate harmlessly, ready to process at any time.
• Traceability. A dedicated address makes the reporting flow identifiable and auditable — valuable in a compliance context, where where and how authentication evidence is collected has to be demonstrable.
• A smooth transition. The day manual reading gives way to an analytics service, only the dedicated address's forwarding changes — no touching the DMARC record, nothing republished in DNS.

It's a five-minute investment that spares a painful migration later. The dedicated address works as a stable pipe: whatever sits at the far end — a human reader today, a dashboard tomorrow — the DMARC record keeps pointing at the same place, and DNS never has to move again just to change how the reports get consumed.

Changing the address later

A related point: changing rua isn't instantaneous either. Receivers read the record at the moment they generate a report, and DNS caching means some will keep seeing the old value for a while after the new one is published. The practical consequence: the old mailbox stays alive on switch day. Keeping it monitored until the flow to it dries up on its own, and only then decommissioning it, is the safe order. The new address has to be confirmed as actually receiving before the migration counts as done — a report that bounces tells the receiver nothing useful and the domain owner even less. Treated as a small overlap period rather than a hard cutover, the change costs nothing and loses nothing.

Common mistakes

• Forgetting external authorization. Trap number one: rua points to another domain without the matching _report._dmarc record, and no reports arrive.
• Pointing rua at a personal inbox. Volume swamps it and reports end up ignored. A dedicated address is the fix.
• Confusing rua and ruf. rua = aggregate reports (statistical, useful, no personal data); ruf = forensic (sensitive, rarely sent). It's rua that comes first.
• Publishing rua but forgetting p. The reverse is more common, but a broken record sometimes prevents all parsing. The full syntax deserves a check.

Checking it works

Once rua is in place, the next question is fair: are the reports actually arriving? If nothing shows up after a few days, diagnosis has its own method — see not receiving DMARC reports, which reviews every possible cause, from syntax to external authorization.

The fastest way to validate the configuration is still a pass through the free DMARC analyzer: it confirms rua is syntactically correct and readable by receivers, before the first report even lands in the mailbox. It's the check that spares three days of waiting only to discover a typo — and it costs nothing to run as often as the record gets tweaked. Configured once and verified from the outside, rua turns a silent policy into a stream of evidence that can actually be acted on.