DMARC report destination authorization deep dive: fixing cross-domain rua/ruf setup when reports never arrive

Cross-domain DMARC reporting looks simple on paper: point rua= or ruf= at another domain, publish one TXT record, and wait. In real deployments, this is one of the easiest ways to end up with a technically valid-looking DMARC record and no reports at all.

The reason is that several details have to line up at once: the right domain has to publish the authorization record, the right destination host has to be authorized, the receiving mailbox has to accept report traffic, and receivers still have discretion about whether they send reports at all. The current 2026 DMARC specifications in RFC 9989, RFC 9990, and RFC 9991 make those rules clearer than the older DMARC text, but the operational failure modes are still the same.

If you only need the base mechanism first, start with DMARC external report destinations. This article goes deeper into the cases where the DNS seems right but reports still do not show up.

The short version

When DMARC reports for example.com should go to reports@vendor.example.net, validate these five things in order:

1. the DMARC record actually contains a syntactically valid mailto: URI
2. the authorization TXT record exists at the exact cross-domain name the receiver will query
3. the destination host in that URI is the one you authorized
4. the destination mailbox and mail flow can actually receive DMARC report mail
5. enough time has passed for receivers that send daily or less often

If any one of those is wrong, the result is usually silence.

When authorization is required at all

Cross-domain authorization is not triggered merely because the rua or ruf address is on a different hostname. Under RFC 9990, the check is required when the Organizational Domain where the DMARC policy was discovered is different from the Organizational Domain of the reporting URI host.

That distinction matters.

These usually do not need external authorization:

• DMARC policy found at example.com, with rua=mailto:dmarc@reports.example.com
• DMARC policy found at example.com, with rua=mailto:dmarc@mx1.ops.example.com

These do need external authorization:

• DMARC policy found at example.com, with rua=mailto:dmarc@example.net
• DMARC policy found at example.com, with rua=mailto:dmarc@reports.vendor.net

So the question is not "is the hostname different?" The real question is "does the reporting URI host belong to a different Organizational Domain from the DMARC policy domain?"

The exact DNS name receivers check

For aggregate reports, the receiver constructs a DNS name using:

1. the domain where the DMARC policy was retrieved
2. the fixed labels ._report._dmarc.
3. the host part of the rua URI

Example:

_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:agg@reports.example.net"

The authorization record must be:

example.com._report._dmarc.reports.example.net. IN TXT "v=DMARC1"

For failure reports, the same mechanism applies to ruf under RFC 9991, just substituting the ruf destination.

The policy-discovery domain is where many setups go wrong

One subtle point from RFC 9990 is that the authorization lookup uses the domain where the DMARC policy was retrieved, not whatever domain an admin happens to be thinking about.

That means these two cases behave differently.

Case 1: mail uses a subdomain, but policy is inherited from the organizational domain

If mail is sent as alerts.eu.example.com but there is no explicit DMARC record there, the receiver may end up using the policy at example.com.

In that case, the lookup is based on example.com:

example.com._report._dmarc.reports.example.net. IN TXT "v=DMARC1"

Case 2: the subdomain has its own explicit DMARC record

If alerts.eu.example.com publishes its own DMARC policy record and that policy points to the external destination, the lookup changes:

alerts.eu.example.com._report._dmarc.reports.example.net. IN TXT "v=DMARC1"

This is a frequent source of confusion during decentralized DNS rollouts. A team adds a new explicit subdomain DMARC record, keeps the old authorization record for example.com, and then wonders why reports for that subdomain disappear.

The host part matters, not the mailbox local-part

Receivers authorize the host portion of the mailto: URI.

So these two addresses use the same authorization target:

rua=mailto:dmarc@reports.example.net
rua=mailto:xml@reports.example.net

Both require authorization under:

example.com._report._dmarc.reports.example.net

But this one is different:

rua=mailto:dmarc@inbound.reports.example.net

That requires:

example.com._report._dmarc.inbound.reports.example.net

Admins often publish the TXT record under the parent zone like example.net while the actual rua host is reports.example.net or inbound.reports.example.net. The record then looks reasonable in DNS, but it is not the name receivers query.

rua overrides are possible, but tightly constrained

The confirming TXT record is allowed to contain more than v=DMARC1. Under RFC 9990, the external report consumer can publish its own rua value there and override the original destination.

That can be useful when a provider wants all reports redirected to a specific mailbox, for example:

example.com._report._dmarc.reports.example.net. IN TXT "v=DMARC1; rua=mailto:dmarc-tenant42@reports.example.net"

But there is an important restriction: the override must keep the same destination host. It cannot bounce reports onward to a different external host.

If the override tries to point at some other domain, receivers must not send the report to either destination.

Wildcards can authorize many domains at once

If a report processor is willing to receive reports for any source domain, RFC 9990 allows a wildcard record such as:

*._report._dmarc.reports.example.net. IN TXT "v=DMARC1"

That is operationally convenient for shared-reporting providers and internal centralized mail platforms.

Two practical cautions still apply:

• wildcard authorization does not fix a wrong rua host
• wildcard authorization does not make a dead mailbox start accepting mail

Why a correct authorization record can still produce no reports

This is the part many teams miss: a valid authorization record does not create a guarantee that reports will be sent.

There are four common reasons for this.

1. The receiver simply does not send the kind of report you asked for

Aggregate rua is the normal visibility channel. Failure ruf is much patchier.

That is even more important in 2026 because RFC 9991 puts heavy emphasis on privacy risk, rate-limiting, and redaction. Many providers either do not send ruf at all, send it only in narrow cases, or suppress content aggressively.

So if rua arrives and ruf never does, that is often normal behavior rather than a DNS failure. For the broader reality of ruf, see DMARC forensic reports in 2026: do ruf failure reports still matter?.

2. The destination mailbox cannot accept real report traffic

The DNS authorization record only says "I permit this domain relationship." It does not prove that the mailbox is alive or operationally suitable.

Common mailbox-side failures are:

• the destination domain has no working MX path
• the mailbox does not exist
• inbound filtering rejects large attachments
• compressed .gz or .zip report attachments are blocked or mishandled
• the mailbox quota is full
• automated processing expects one alias while the published rua uses another

If you are centralizing DMARC reporting, DMARC XML aggregate reports at scale covers the intake side in more detail.

3. The record exists, but not in the form the receiver accepts

The confirmation TXT record is parsed using DMARC-style tag syntax.

That means the safe minimum is still:

v=DMARC1

And the v=DMARC1 tag has to appear first. If the record is malformed, receivers can discard it for authorization purposes.

Practical mistakes include:

• publishing some other text in the TXT record
• putting another tag before v=DMARC1
• authorizing the wrong hostname
• relying on a DNS change that has not propagated yet

4. Not enough time has passed

Many receivers send aggregate reports daily. Some send less often. Some send only after seeing enough traffic for the domain to justify a report.

So a newly corrected setup may still look broken for a day or two. If the domain has very low traffic, the waiting period can be longer.

A reliable troubleshooting flow

When reports never arrive, use this order.

1. Confirm the DMARC policy domain first

Do not start with the destination side. First determine where the effective DMARC policy is actually being discovered:

• the exact subdomain
• the organizational domain
• in PSD DMARC cases, a higher policy domain

This tells you the left-hand side of the authorization lookup name.

2. Expand the destination from the actual mailto: host

Ignore the mailbox local-part and build the query name from the destination host only.

If the URI is:

mailto:agg@reports.vendor.net

then the relevant host is reports.vendor.net, not vendor.net and not agg.

3. Query the exact authorization name

For example:

example.com._report._dmarc.reports.vendor.net

You want to see a parseable TXT record beginning with v=DMARC1.

4. Check whether the report consumer is overriding rua

If the record contains its own rua= value, make sure that:

• the override host is the same destination host
• the resulting mailbox is monitored and routable

5. Test the destination mailbox as a mail system, not just as DNS

At this stage, treat the problem like normal mail intake troubleshooting:

• does the domain publish MX?
• does the mailbox exist?
• can it receive external mail?
• are compressed attachments accepted?
• are messages being quarantined elsewhere?

6. Separate rua expectations from ruf expectations

If aggregate reports are the main goal, debug rua first and treat it as the success criterion.

If ruf is the main goal, confirm you are not expecting universal support from receivers that simply do not generate it.

Example patterns that work

Single domain outsourcing aggregate reporting

_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:agg@reports.vendor.net"
example.com._report._dmarc.reports.vendor.net. IN TXT "v=DMARC1"

Dedicated subdomain with its own policy and its own authorization

_dmarc.marketing.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:marketing@reports.vendor.net"
marketing.example.com._report._dmarc.reports.vendor.net. IN TXT "v=DMARC1"

Provider-side wildcard authorization

_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:agg@reports.vendor.net"
*._report._dmarc.reports.vendor.net. IN TXT "v=DMARC1"

The practical takeaway

Cross-domain rua and ruf failures usually are not caused by DMARC itself being mysterious. They are usually caused by one precise mismatch:

• the wrong policy domain
• the wrong destination host
• the wrong authorization name
• a mailbox that cannot really receive DMARC traffic
• or the assumption that receivers owe you ruf reports

Once you treat the problem as both a DNS authorization problem and a mail intake problem, most silent-report setups become explainable very quickly.

For most teams, the durable operating model is simple:

1. use rua as the primary reporting channel
2. authorize external destinations with the exact queried hostname
3. keep the report mailbox operationally boring and robust
4. treat ruf as optional bonus visibility, not as the backbone of DMARC monitoring