A published rua request does not produce a complete census of every destination. A receiver may not participate in reporting, may not have relevant observations, or may encounter a generation or delivery problem. Treat an absent reporter as an investigation question, not proof of zero mail or zero abuse.
Define the expected receiver population
Start with sending logs and verified destinations for the interval under review. Group them by actual receiving infrastructure where that is known; a recipient domain and a report-generator identity need not have a one-to-one relationship. Outsourced mail hosting and gateways can make a brand-based reporter list misleading.
Record what supports each expectation: an earlier report, current first-party documentation, a controlled delivery or a sender log. Keep assumptions separate. Do not invent a provider's reporting schedule or capability from another provider's behavior.
Rule out request and collection defects
References: RFC 9990 §4, RFC 9990 §3.5.
Verify the applicable policy and rua destination, then required external authorization. Check receiving mailbox logs, quarantine and parser failures. If a report reached the collector but was not displayed, the receiver did report; the gap belongs to the collection process.
A fresh controlled message to a consenting test mailbox can establish that a particular path received mail. Its trusted authentication results help diagnose the message, but they do not prove that an aggregate report will be generated or arrive at a guaranteed time.
Classify uncertainty honestly
References: RFC 9990 §3.1, RFC 9989 §5.3.8.
Use distinct statuses such as previously reporting but late, request invalid, delivery rejected, parser failed, and participation unconfirmed. This prevents different teams from treating every missing entry as the same outage. RFC 9990 describes daily or more frequent feedback, but practical coverage still depends on actual participating systems and successful collection.
Illustrative case: reports arrive from receivers A and B, while sender logs also show accepted mail at C. No report from C is present. Without further evidence, classify C as unobserved in aggregate reporting. Do not assign a zero failure rate to C or infer its policy implementation from A's reports.
Make decisions with the available evidence
Prioritize missing coverage for critical flows, recent infrastructure changes and receivers that previously contributed reliably. Use sender logs, authorized message samples and delivery diagnostics to supplement reports. Do not repeatedly change a valid record merely to make an unconfirmed reporter appear.
Publish both the observed findings and the coverage limitation. If the absent receiver materially affects an enforcement decision, obtain better evidence for that route or document the remaining uncertainty and decision owner. The result should be a defensible evidence map rather than a promise that every mailbox provider is represented.
Maintain the expected-reporter register
For each important receiver, record why participation is expected, the last interval observed, historical arrival behavior and current evidence quality. Separate a verified provider change from a local guess based on a missing file. Review the register after sender migrations or recipient-hosting changes, because the relevant reporting infrastructure may change without a change in the customer's email address. An expectation that cannot be substantiated should be labelled unconfirmed. This gives the next analyst a concrete starting point instead of a recurring unexplained alert.
Continue the investigation
Use the aggregate-report walkthrough to interpret the underlying fields and the alignment diagnosis guide when a raw authentication pass does not satisfy DMARC.
Executed synthetic evidence
The following is a locally rerun offline synthetic fixture, not a live DNS, SMTP or customer observation. Its XML input was parsed with Python's standard library, and assertions checked the resulting fields and calculations. The simulated DNS and mail stages are supplied test inputs, not evidence that a real receiver performed those operations. Full schema validation and production-source authentication are outside this small fixture; live evidence remains pending.
The supplied request is _dmarc.brand.example TXT "v=DMARC1; p=none; rua=mailto:aggregate@collector.example,mailto:archive@archive.example". These reserved example domains are assumed to be separate organizational domains in the fixture. The two synthetic authorization answers are brand.example._report._dmarc.collector.example TXT "v=DMARC1" and brand.example._report._dmarc.archive.example TXT "v=DMARC1". The local model matches both supplied authorization-owner names and their version values under RFC 9990 §4. It does not execute DNS queries or the complete authorization algorithm. A production implementation must perform the complete discovery and authorization procedure rather than assuming these domain boundaries.
The retained report has ID R1, policy domain brand.example, date_range begin 1772409600 and end 1772496000, source IP 192.0.2.10 and count 100. Its evaluated aligned DKIM result is pass and aligned SPF is fail. The raw SPF result is pass for vendor.example, illustrating why raw success is not aligned success. These fields are parsed from XML rather than inferred from a dashboard.
The positive-control receiver.example has a simulated accepted receipt and a parsed count of 100. The second synthetic receiver, unobserved.example, has 20 supplied sender submissions but no receipt and no parsed count. The assertion preserves that count as null rather than zero. The completed request-to-parser positive control shows that the model's collector can process one report; it does not establish that the missing receiver participated or attempted delivery. A live investigation must obtain its own mailbox and provider evidence before changing that classification.
Keep the result within the tested scope
The supplied local demonstration verifies only its small synthetic parser, supplied stage inputs and calculations. No real DNS authorization, SMTP delivery, collector migration, provider participation or production database behavior was tested. Original inputs remain archived, and any live comparison needs its own protected evidence and accountable approval.