DMARC rua points to another domain: the external reporting authorization record you may be missing

Why external destinations need consent

Without an authorization check, a domain owner could publish another organization’s address in rua and cause many receivers to send reports there. DMARC therefore includes a mechanism for the external destination to signal that it accepts reports for the protected domain. In current DMARC reporting work, this behavior belongs with aggregate reporting rather than the core authentication decision. The practical lesson is simple: a cross-domain reporting mailbox has a DNS dependency on the destination side.

Confirm whether the address is actually external

Compare the domain that publishes the DMARC policy with the domain after @ in the rua URI. A mailbox such as dmarc@example.com is internal to example.com. A mailbox such as dmarc@reports.example.net is external even if both domains belong to the same person or company. Ownership in your registrar account does not change protocol semantics. If the domains differ, check whether the destination domain has published the authorization record expected for reports from the protected domain.

Do not diagnose missing reports from mailbox logs alone

If authorization fails, a compliant report generator may simply decline to send the report. There may be no bounce in the protected domain’s mailbox because no message was attempted to that address. That is why checking spam folders or mailbox quota first can be misleading. Start at DNS: validate the DMARC record, the rua URI, and the external-authorization record. Then confirm that the receiving mailbox itself accepts normal mail and can process compressed XML attachments if your workflow depends on automated parsing.

Multiple report destinations create multiple authorization checks

A DMARC record can request reports to more than one URI. If one address is internal and another is external, the external one still needs its own authorization path. If two different external reporting domains are listed, each destination domain must be considered independently. This explains partial reporting patterns where one analytics service receives data and a second mailbox does not. Do not treat “some reports arrived” as proof that every rua destination is configured correctly.

Expect receiver variation without building policy around it

Not every receiver generates aggregate reports with the same frequency, and implementations can differ in optional behavior. That variability can mask a missing authorization record because a few reports may still arrive from senders or systems with different handling. Base your configuration on the specification rather than on accidental partial success. If the DNS authorization is correct, you have removed one deterministic reason for missing data; remaining gaps can then be investigated as report-generation, volume, or mailbox-processing issues.

A clean setup pattern for a reporting service

Suppose example.com publishes rua=mailto:agg@reports.example.net. Document the exact protected domain and reporting domain, create the external authorization record on reports.example.net according to the reporting specification or service instructions, verify it publicly, and only then enable automated ingestion. Send ordinary test mail to the reporting mailbox separately so you know mailbox routing works. This separates DNS consent from mailbox delivery and from XML parsing, giving you three testable layers instead of one opaque “DMARC reports missing” problem.

Protect the authorization record during DNS cleanup

Reporting records are easy to delete because they can look unrelated to websites or normal mail. Add them to the same DNS inventory as SPF, DKIM, DMARC, MX, and verification records. If you later move the reporting mailbox or analytics provider, remove the old authorization only after the new destination is confirmed. A routine DNS cleanup should never silently disable deliverability telemetry that may take days to notice.

Use aggregate reports as evidence, not as a live event stream

Even after configuration is correct, DMARC aggregate reporting is not a real-time message trace. Reports summarize observed authentication results over reporting periods and can arrive on different schedules. For low-volume outbound, they are useful for identifying unexpected senders and alignment patterns, but they should be paired with direct headers and SMTP diagnostics during an incident. Fix the external authorization so the telemetry is as complete as possible, then interpret it at the right timescale.

Troubleshoot external report delivery at the DNS authorization layer

When `rua` points outside the domain publishing DMARC, the destination domain participates in an authorization check designed to prevent arbitrary domains from being flooded with reports. If aggregate reports do not arrive at a third-party mailbox, confirm the exact reporting URI, determine that it is external to the policy domain, and inspect the destination-side authorization record described by the DMARC reporting specification. A perfectly valid `_dmarc.example.com` record does not by itself prove that an external report collector has authorized receipt for your domain.

Create an evidence chain instead of repeatedly editing `rua`. Record the policy-domain TXT answer, the external destination, the authorization DNS answer at the reporting side, and at least one report generator that is expected to send data. Then allow for reporting cadence and receiver discretion; aggregate reports are not designed as real-time delivery logs. If you use more than one external URI, verify authorization for each destination independently because one working collector does not validate another. Finally, protect these records during vendor offboarding. Removing a reporting service should include removing its URI and any corresponding authorization records, while moving to a new collector should be tested before the old destination is dismantled so you do not create an observability gap exactly when policy is changing.

Field checklist

• Compare the protected domain with every rua destination domain.
• Publish the required authorization on each external reporting destination.
• Verify DNS before troubleshooting mailbox spam folders or parsers.
• Test mailbox delivery separately from DMARC report generation.
• Keep external-report authorization records in the DNS inventory.
• Use raw headers and SMTP logs for real-time incidents; use aggregate reports for broader patterns.