What a wildcard deliberately broadens
A report consumer may be willing to receive DMARC reports for any domain rather than publish one authorization owner for each relationship. RFC 9990 explicitly permits a wildcard DNS record for that purpose. Its example places a TXT record at *._report._dmarc.example.com with at least v=DMARC1. This is a broad opt-in by the receiving domain, not a mechanism that proves every reporting customer has been vetted.
The distinction is operationally important. A provider can legitimately choose broad intake while separately requiring account-level verification before showing data to a customer. The DNS record does not implement those account controls. A security review should identify exactly which boundary the wildcard changes and which boundaries remain the responsibility of the receiving application and its owners. RFC 9990, section 4
Keep exact queries visible beneath the wildcard
The reporter still constructs the authorization lookup from the domain where the policy was retrieved, the _report._dmarc labels and the destination host. A wildcard is a DNS publication strategy that can answer those queries; it does not remove the need to understand the queried owner or the returned value. Preserve the exact owner and response when verifying a particular relationship.
The confirming answer must pass the external-verification parsing rules, including mandatory first v=DMARC1. The version value remains DMARC1 with its required case. An administrator’s intention to use a wildcard is not evidence that a particular query resolves as expected in the deployed DNS tree. Exact-name records and DNS structure can affect real resolution, so proposed tests must retain the actual answer instead of assuming a screenshot proves coverage. RFC 9990, section 4; RFC 9989, section 4.7
Separate intake permission from ownership and data access
A wildcard says the receiving domain is willing to receive the reports covered by the protocol arrangement. It does not establish that a person signing into a dashboard controls the domain named inside a report. It also does not establish that the sender of an uploaded artifact is trustworthy or that a report belongs to the account receiving it.
Define application-level acceptance requirements separately: domain-to-tenant binding, authenticated access, provenance tracking, duplicate handling and review of unexpected domains. These are proposed controls, not claims about an implemented EmailAuth platform. A report mentioning an organization should not automatically create an ownership relationship or expose data to the first account that claims the name.
Keep billing, onboarding and data authorization out of the DNS inference. Broad willingness to receive traffic is not consent to enroll an organization in a paid service or publish its observed configuration. If a workflow needs these actions, it requires explicit decisions and evidence beyond the wildcard record. The review should name the responsible owner for each boundary rather than treating a single DNS result as comprehensive approval.
Account for abuse and resource pressure
RFC 9990 warns that report content can attack the decompressor or XML parser and that report data may be forged. A broad intake service should therefore assume that permission to receive reports does not make every arriving file safe or accurate. Capacity planning, parser limits and provenance checks belong alongside the authorization design.
Propose bounded message sizes, decompressed-size limits, parsing time budgets, queue isolation and alerting for unexpected source volume. The numerical values must be selected and tested for the actual environment rather than copied from an invented universal limit. Preserve rejection reasons and avoid allowing one noisy source to obscure unrelated customer evidence. None of these controls is claimed to be deployed or tested here. RFC 9990, section 8.1 and 8.2
Withdrawal and cached authorization
A report consumer overwhelmed by volume can remove the confirming DNS record, but RFC 9990 notes that positive caching can delay the effect for as long as the record’s TTL. Do not promise immediate cessation of reports after a DNS change. Intake systems may also need to handle reports already generated or queued independently of the fresh lookup state.
A withdrawal plan should identify the record owner, approval path, relevant TTL evidence, intake behavior during the transition and communication responsibilities. Removing a wildcard may affect many legitimate relationships at once. A proposed move to explicit per-domain authorization needs an inventory of those relationships and a verification plan, not merely a record deletion.
Keep the distinction between DNS withdrawal and application access revocation. Removing receiving permission does not itself delete stored reports, close customer accounts or revoke existing user sessions. Those are separate controls with separate authorization and retention implications. RFC 9990, section 4
Fictional boundary review and test design
Consider a fictional consumer at reports.example.net that proposes *._report._dmarc.reports.example.net with the value v=DMARC1;. For a hypothetical policy at blue.example.com, the exact query would be blue.example.com._report._dmarc.reports.example.net. No query, publication or DNS fixture was executed for this example.
The positive-case plan would retain the exact query and confirm that the returned authorization value passes parsing. The negative-case plan must be chosen carefully: another source domain directed to the same broadly authorized destination is not necessarily unauthorized, because the wildcard intentionally covers source domains generally. Instead, a separately controlled destination host without permission can illustrate the external-destination boundary, provided any actual fixture is authorized and isolated.
The worksheet should list the wildcard owner, expected coverage, exact test owners, answers, version parsing, destination-host boundary and tenant-access checks. It should also record the rollback plan and limits on report processing. Expected outcomes are design hypotheses until actual bounded tests are performed; they must not be labeled passed merely because the reasoning is plausible.
Unresolved original evidence and release gates
The catalogue requires the exact authorization owner and answer, including a positive test and an unauthorized-destination test. Those original observations remain open. This manuscript supplies a proposed test design and fictional names, not a functioning wildcard deployment or an account-access assessment.
Before publication as a verified operational guide, a qualified reviewer must inspect the actual DNS responses and confirm that the negative test really crosses the intended authorization boundary. Original evidence, human review, source applicability, production routes, visual accessibility and owner release remain open. No external contact, report upload or DNS modification was performed for this work.