External DMARC reporting is a two-domain contract. The policy domain asks for reports with rua, and the destination domain must publish the DNS proof that it is willing to receive them.
The most common DMARC reporting mistake is subtle: the DNS record asks receivers to send reports to a mailbox on another domain, but the destination domain never authorizes that relationship. The record looks fine. The dashboard stays empty.
This happens because aggregate reporting is not just a mail delivery feature. It is also an abuse-control mechanism. Without a verification step, an attacker could publish a DMARC record that points thousands of reports at a victim mailbox and use receivers as report amplifiers.
The two records involved
The policy domain publishes the ordinary DMARC record. That record can ask for aggregate reports with rua.
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:reports@dmarc.example.net"Because the report mailbox is on a different organizational domain, compliant receivers construct a second DNS lookup under the destination domain. In RFC 9990, the lookup is built by prepending the policy domain and _report._dmarc to the destination host.
example.com._report._dmarc.dmarc.example.net. TXT "v=DMARC1"If that TXT record exists and parses as a DMARC-style tag list with v=DMARC1 first, the external reporting relationship is authorized. If it does not, the external rua URI is ignored.
What changed in the 2026 RFCs
RFC 9990 moved aggregate reporting into its own standards-track document and makes external destination verification an explicit part of report delivery. The practical rule is simple: once a report destination crosses organizational-domain boundaries, the receiver must verify that the report consumer agreed to receive the data.
That matters for SaaS-based DMARC monitoring. If a customer publishes rua=mailto:reports@vendor.example, the vendor domain has to publish the matching authorization record. Otherwise, receivers that follow the current standard have no positive proof that the vendor accepts reports for that customer domain.
Why this fails quietly
DMARC reporting is receiver-driven. There is no central registry, no immediate callback, and no guarantee that every receiver logs the same error in a place the domain owner can see. One mailbox provider may send reports, another may drop the external destination, and the dashboard just looks sparse.
- The DMARC record validates syntactically, but reports never arrive.
- Only a subset of large receivers send aggregate reports.
- Reports arrive for domains using an internal rua mailbox but not for domains using the vendor mailbox.
- DNS contains the policy record, but not the matching _report._dmarc authorization record.
The wildcard option
RFC 9990 allows a report consumer to authorize reports for any domain with a wildcard record. That is useful for monitoring providers because onboarding cannot require a bespoke DNS record for every customer domain.
*._report._dmarc.dmarc.example.net. TXT "v=DMARC1"The wildcard is still a real authorization statement. It says the destination domain is willing to receive DMARC reports for arbitrary policy domains. If volume becomes abusive, the report consumer can remove the confirming DNS record, though positive DNS caching means the change follows the record TTL.
The checklist
When a domain uses a third-party DMARC reporting address, the setup checklist should include both sides of the relationship.
- Confirm the policy domain's rua URI uses the intended destination host.
- Publish the matching authorization TXT record under the destination domain.
- Keep the authorization record short enough to fit DNS name-length limits.
- Verify from public DNS, not only from the provider's internal configuration.
- Treat missing reports as a DNS and receiver-behavior issue before blaming message volume.
Where DMARCify fits
DMARCify should treat external destination authorization as part of onboarding, not as a hidden troubleshooting article. The domain setup flow can show the exact rua value and the exact authorization record that needs to exist for compliant receivers.
The operational rule is boring but important: a DMARC dashboard starts with report delivery, and report delivery starts with DNS consent from the destination domain.
Disclosure: AI tools were used in the process of creating this blog post.