Why does DMARC say an rua or ruf domain is not authorized?

A DMARC checker says an rua or ruf domain is not authorized when the report destination is outside the policy domain and the destination's DNS does not publish the required consent record for that relationship. This protects third parties from being flooded with reports they did not request. Confirm the exact domain publishing DMARC, the host in the mailto destination, and the authorization name required by RFC 9990. Fix the destination's DNS or use an address inside the policy domain.

Quick takeaways

• External DMARC reporting requires consent from the destination domain.
• The authorization record is published by the report receiver, not the sending domain alone.
• rua and ruf destinations are checked separately when their hosts differ.
• A valid DMARC policy can still have an unauthorized reporting destination.
• Use the exact policy domain and destination host when constructing the DNS name.

This diagram summarizes the article's diagnostic sequence. Use the linked standards, current provider documentation, and production evidence for exact decisions. Open the full-size diagram.

What does the failure mean?

RFC 9989 lets a domain request aggregate or failure reports and points to RFC 9990 for external reporting addresses. Without external authorization, an attacker could point reports at an unrelated victim. RFC 9990 defines a DNS check that proves the destination domain agrees to receive reports about the policy domain.

The error concerns reporting authorization. It does not automatically mean the p policy, SPF, DKIM, or alignment is invalid. Review the DMARC overview for those separate layers.

What usually causes it?

The destination provider has no authorization record

The report address uses another domain, but that provider has not published the DNS record that authorizes reports for the customer's policy domain.

The authorization name uses the wrong source domain

An administrator may build the name from the organizational domain while the actual DMARC policy is published for a subdomain, or may omit a label from the destination domain.

DNS delegation or caching hides the record

The record exists in one control panel but is absent from authoritative DNS, is published under the wrong zone, or has not reached recursive resolvers after a change.

How do I diagnose the failure?

1. Parse every reporting URI

List the full rua and ruf mailto destinations from the discovered policy. Extract the domain after the at sign for each address.

2. Identify the policy domain

Record the exact domain whose DMARC record contains the reporting URI. A subdomain policy creates a different authorization relationship than a parent policy.

3. Construct the authorization lookup

Follow RFC 9990 and the report processor's official instructions to form the DNS name under the destination domain. Query TXT directly.

4. Compare authoritative and public answers

Confirm the destination's authoritative servers publish the record and that public resolvers can retrieve it. Check delegation and DNSSEC when answers disagree.

How do I fix it?

If you control the destination domain, publish the exact authorization record required for the policy domain. If a DMARC processor controls it, use the destination it assigned and follow its onboarding steps. Do not invent a wildcard or copy another customer's authorization name without provider documentation.

When the destination cannot authorize external reports, change rua or ruf to an address inside the policy domain or remove the unsupported destination. Preserve at least one working aggregate-report path if monitoring depends on it.

How do I validate the repair?

Query the DMARC policy and the external authorization record from more than one public resolver. Confirm each external destination is authorized for the exact policy domain, then monitor the report processor for accepted aggregate files. Report arrival can lag because receivers send on their own schedules.

Use Palisade's DNS lookup tool for both names and Email Security Score for the surrounding public configuration. A passing checker does not prove the report mailbox or processor is operational.