Two parties make the reporting relationship
Publishing a reporting destination in a domain’s DMARC policy expresses the domain owner’s request. It does not unilaterally require an unrelated destination to accept the resulting reports. External destination verification protects recipients from being selected as unwilling report targets. The receiving side publishes permission through DNS, while the reporting side checks that permission before using the external destination.
RFC 9990 applies its verification procedure when the relevant Organizational Domain comparison shows an external destination for aggregate reporting. Do not replace that rule with a simplistic test that the strings in the From address and report address differ. The discovered policy domain, destination host and organizational-domain context must be retained so the decision to perform verification is reproducible. RFC 9990, section 4
Construct the owner name in the right order
Extract the destination host from the reporting URI. Prepend _report._dmarc, then prepend the domain name from which the policy was retrieved, converting that domain to an A-label if needed. The resulting DNS owner has the form policy-domain._report._dmarc.destination-host. It is queried for TXT records. If the constructed name exceeds DNS limits, a positive authorization determination cannot be made.
This construction uses the actual domain from which the policy was retrieved. Do not shorten it to a familiar parent merely because that parent looks like the organization’s brand. Equally, the local part of a mailto address is not inserted into the DNS owner name. Preserve the original URI and the parsed destination host so reviewers can see how the constructed name follows from the inputs. RFC 9990, section 4
Validate the response rather than recognizing a familiar string
The returned records are parsed as tag-value lists. The mandatory v=DMARC1 tag must appear first, and a trailing semicolon is optional. Records that fail the specified parsing test are discarded. At least one remaining qualifying record establishes the external reporting arrangement under the procedure. An empty answer, an unrelated TXT value or a record with the wrong version placement does not establish permission.
The DMARC version value is case sensitive: DMARC1 is the required value, not a lowercase approximation or a newly invented protocol version. DNS name comparison rules should not be confused with the version value’s case requirement. A review should preserve the exact answer bytes and record boundaries instead of normalizing away details before validation. RFC 9990, section 4; RFC 9989, section 4.7 and 4.8
Respect override and failure behavior
An authorization record can supply a reporting destination override under the procedure. The overriding URI must use the same destination host extracted at the beginning. This restriction prevents an authorization response from redirecting the process into a chain of unrelated recipients. If confirmation contains an override with a different host, the report generator must not generate a report to either the original or override URI.
If verification does not confirm authorization, the external URI must be ignored. A temporary DNS error has its own treatment: the receiver may elect to temporarily fail delivery so the verification test can be repeated later. Preserve that permission as MAY, not a universal retry guarantee or a description of a tested implementation. A successful DNS check still does not prove that the destination mailbox exists, accepts the report size or feeds the intended customer dashboard. RFC 9990, section 4
Distinguish aggregate and failure report requests
For aggregate reports, the procedure is associated with rua. Failure reporting is specified separately in RFC 9991. For external failure-report destinations, that document requires the same external-verification procedure with ruf substituted wherever rua appears. Do not treat failure reporting as automatically enabled just because aggregate reports are flowing, or copy aggregate destination handling without acknowledging the separate report type.
Failure reports raise additional data-exposure concerns because their content can be more detailed than aggregate summaries. A correct DNS authorization record is not a substitute for an organization’s decision about which data may be shared, with whom and for what purpose. This manuscript supplies no permission to request, transmit or upload actual reports. Any real setup must satisfy the applicable privacy, recipient and operational approvals. RFC 9991, section 5 and 7
Fictional construction and acceptance worksheet
Assume a fictional policy was retrieved from blue.example.com and requests aggregate reports at mailto:reports@red.example.net. The constructed authorization owner is blue.example.com._report._dmarc.red.example.net. A hypothetical TXT answer whose complete value is v=DMARC1; satisfies the illustrated version-first requirement. No DNS query was executed, and this example does not claim that the names have published records.
The worksheet should retain the policy lookup result, discovered policy domain, original reporting URI, destination host, organizational-domain comparison, constructed owner, query type, timestamp, exact returned records and parsing outcome. Add a separate field for any override and confirm its host restriction. A reviewer should be able to reconstruct the name without relying on a provider screenshot or a DNS editor’s abbreviated display.
Use a second acceptance section for collection: intended account, destination mailbox, authorized report type and pipeline owner. Those fields describe a planned verification workflow, not completed ingestion evidence. Keep the DNS relationship result distinct from receipt, parsing, tenant attribution and dashboard presentation. A permission check can succeed while another part of the collection path remains unresolved.
Publication and implementation holds
The catalogue requires construction of the exact authorization lookup from source and destination domains and verification of its answer. This draft supplies a fictional construction only. An actual answer, original query transcript and receiving-domain implementation remain open. No DNS record was published, no mailbox was accessed and no report was transmitted.
Before release as an operational walkthrough, obtain authorized evidence for the exact production relationship and have a qualified reviewer confirm the policy-discovery context, version parsing and override handling. Retain the source date and distinguish standards requirements from provider-specific account onboarding. All six release gates remain open, including original evidence, human review, source applicability, production routes, visual accessibility and owner release.
A later change to the destination or policy-discovery domain can change the required authorization owner. Treat it as a new scoped relationship to verify rather than assuming an old positive check covers every future reporting address. The useful outcome is an auditable permission chain, not merely a copied TXT value.