Back to Learning Center Email Authentication

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

By Samuel ChenardAugust 11, 20266 min read

Ask AI to explain

In brief

DMARC says an rua or ruf domain is not authorized when an external report destination lacks the DNS consent record required for that policy domain.

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

DMARC says an rua or ruf domain is not authorized when a report address points outside the applicable DMARC policy domain and the destination domain has not published the required DNS consent record. This check prevents one domain from directing DMARC reports to an unrelated recipient. Check the exact policy domain, the domain after @ in each reporting address, and the authorization record defined by RFC 9990.

At a glance

Quick takeaways

An external DMARC reporting address needs DNS authorization from the domain that receives the reports.
The authorization record belongs under the report destination domain, not only under the domain publishing DMARC.
rua and ruf addresses require separate checks when they use different destination domains.
An unauthorized report destination does not by itself make SPF, DKIM, or DMARC alignment fail.
The lookup name includes the exact DMARC policy domain, so a subdomain can produce a different authorization name.
A DNS result confirms publication, not that a report processor is receiving and handling production reports.

How external DMARC report authorization works

DMARC policy records can request aggregate feedback through rua and can include failure-report destinations through ruf. Reporting addresses are normally within the policy domain. When an address uses another domain, the receiving domain must explicitly authorize that relationship through DNS.

For aggregate reporting, RFC 9990 defines the external-destination check. The receiver forms a TXT lookup name from the policy domain and the destination domain. A valid authorization record tells the receiver that the destination agrees to accept reports about that policy domain.

This is separate from message authentication. A report destination can be unauthorized while a message still has an aligned SPF or DKIM pass. For the broader protocol, see the DMARC learning hub.

Flow showing a receiver checking an external DMARC reporting address against its required DNS authorization record — Source: Palisade.

When an rua or ruf domain is not authorized

Treat an address as external when its domain is neither the policy domain nor a subdomain of that policy domain. The important comparison is against the domain whose DMARC policy supplies the reporting URI.

For example, if the policy record is published for example.com and includes rua=mailto:reports@processor.example, the report address is external. The receiver checks whether processor.example authorizes reports for example.com.

The answer can change in these cases:

A reporting address at reports.example.com is within example.com, so it is not an external destination for this check.
A policy published specifically for marketing.example.com creates an authorization relationship for marketing.example.com, not automatically for example.com.
Multiple rua or ruf addresses can use different destination domains. Check each external domain separately.
A destination service may provide a customer-specific address and publish the needed authorization itself. Use the address and DNS instructions assigned by that service.

Do not replace the policy-domain label with an organizational-domain guess. RFC 9990 ties the authorization lookup to the policy domain in the reporting relationship.

Worked authorization-record example

For this illustrative DMARC policy:

Technical exampletext

v=DMARC1; p=none; rua=mailto:dmarc-reports@processor.example

If example.com is the policy domain, the external authorization lookup is:

Technical exampletext

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

This is illustrative only. Do not publish this exact record in another domain's DNS. The report destination provider must supply or confirm the real authorization record for its own domain.

The parts have distinct jobs:

example.com is the exact domain whose DMARC policy contains the reporting URI.
_report._dmarc identifies the external DMARC reporting authorization namespace.
processor.example is the domain after @ in the destination address.
v=DMARC1 identifies the authorization record format specified by RFC 9990.

A common failure is publishing a record under _dmarc.example.com, or under the source domain's zone. Neither location gives processor.example consent to receive external reports.

What to check next

Start with the evidence you have.

If you have only the domain name, use the DMARC checker to inspect the public DMARC record and copy each rua or ruf destination exactly. Then identify the policy domain that supplied the record and query the required external authorization name.

If you control the report destination domain, confirm the TXT record on its authoritative DNS servers and through at least one public resolver. If the answers differ, investigate the destination zone, delegation, and DNS propagation before changing the DMARC record.

If a hosted reporting service owns the destination domain, use the reporting address it assigned and its current onboarding instructions. Do not copy an authorization hostname from another customer or assume that a wildcard record is accepted.

After DNS confirms the record, check the report processor for accepted aggregate files once receivers have had time to send them. Receiving systems determine when they generate reports, so immediate arrival is not proof of a successful change. If you are also investigating a delivery rejection, keep that work separate from report authorization. For example, SMTP error 550 5.7.509 concerns a sender's DMARC verification, not an external report mailbox.

Check the external DMARC report destination

Inspect the published DMARC record first, then construct the authorization lookup from the exact policy domain and report destination domain.

Check the DMARC record

A public DNS check cannot prove that every receiver will send reports, that a mailbox or processor accepted a report file, or that the production sending path passes DMARC. Palisade is agentic DMARC software that analyzes aggregate-report data, identifies sources and authentication or alignment issues, and creates prioritized remediation tickets. A human reviews the evidence and applies any DNS or policy change.

Start with Palisade

Evidence

Sources and further reading

Questions readers ask

Frequently asked questions

Does an internal rua address need external authorization?

No. An rua address whose domain is the policy domain or one of its subdomains is not an external destination for this DNS authorization check. The mailbox or report processor must still be able to receive and process reports.

Who publishes the external authorization record?

The domain receiving the reports publishes the record. A DMARC reporting provider commonly publishes it in its own DNS zone after assigning the customer's report address.

Does one authorization record cover both rua and ruf?

Only when the relevant reporting addresses use the same destination domain and the same policy domain. Check every distinct external destination relationship.

Can I publish the authorization record in my own DMARC domain?

No. The authorization record must be published under the destination domain because that domain is granting consent to receive the reports.

Does an unauthorized report address make DMARC fail?

No. DMARC message evaluation depends on aligned SPF or DKIM results for the visible From domain. External report authorization controls whether a receiver can send reports to the requested external destination.