Source review dated 8 November 2026. Operational steps are proposed; only the explicitly labelled offline demonstration is executed. No live tenant, DNS or mail delivery is claimed.
When DMARC reports stop arriving, investigate the collection path before drawing a conclusion about the domain's traffic. A reporting request, permission to send to an outside destination, successful mail delivery and successful processing are separate dependencies.
A quiet dashboard can mean that no relevant report arrived. It can also mean that a delivered attachment failed parsing, the mailbox changed, or a filter hid the results. Start with the last point in the chain that you can verify.
Confirm the policy that requests reports
Query the applicable policy and save the authoritative answer, the query name and a timestamp. Check the actual reporting URI rather than the address an administrator intended to publish. If a parent policy applies, follow the discovered policy rather than inspecting only a child name.
The rua tag requests aggregate reports. A working DMARC policy without a reporting request does not automatically create a report stream. Check for an address typo, a recently changed collector identifier or a record at an inactive DNS host.
An illustrative source-domain record is:
v=DMARC1; p=none; rua=mailto:aggregate@reports.example.netThis example does not establish that the external destination accepts reports for example.com. It also does not justify weakening an existing stronger policy to match the example.
Check permission at an external destination
Reporting to a domain outside the applicable organisational-domain relationship requires the destination check defined by the reporting specification. The destination operator supplies the relevant permission.
For a policy at example.com requesting mail to reports.example.net, an illustrative verification name is:
example.com._report._dmarc.reports.example.netA qualifying third-party reporting permission must contain v=DMARC1 as the first tag in the TXT record. This is a reporting permission record controlled by the destination, not another source-domain policy. Use the domain where the effective policy was retrieved in this name, not automatically the original child From domain. A destination override must retain the same destination host under RFC 9990 §4. The collector may use a supported wildcard arrangement; follow its approved configuration and verify the applicable answer.
Do not add an unfamiliar destination merely to make reports appear. Confirm its ownership, the intended customer identifier and the authority to receive the data.
Follow delivery into the collection system
Establish whether reports reach the mail boundary. Check the destination domain's receiving configuration and relevant mail logs, quarantine, forwarding rules and attachment restrictions.
A normal test email can demonstrate that an address accepts some mail. It does not prove that compressed report attachments pass the same filters or that a particular reporting receiver generated anything.
Continue through storage, decompression, XML parsing, deduplication and the dashboard query. Record a report identifier and interval at each stage where the system exposes them. Preserve a failed original attachment in an appropriately controlled location rather than repeatedly uploading an edited copy.
Use a known report to isolate the stage
Consider this synthetic investigation. The receiving mailbox accepted an attachment at 09:12, storage retained it at 09:13, but the ingestion job rejected its namespace. The dashboard remained empty.
The immediate fault is in processing. Replacing the published rua address would change a working part of the path and obscure the original evidence. Correct the parser or supported format handling, then reprocess under the system's documented duplicate rules.
A second investigation might find no receiving-mail event at all. That moves attention upstream to generation, destination permission, routing and filtering. The same dashboard symptom can have different causes.
Check the traffic and observation period
Confirm that the domain actually sent relevant mail to receivers that participate in reporting. Record the period being reviewed and the configured time-zone or date filters.
Receivers need not all produce the same feedback, and reports can arrive after their covered interval. A short window with no reports does not prove that there was no domain use or that authentication succeeded. Compare the situation with sending logs and previous reporting patterns without treating either population as identical.
If one reporter continues while another disappears, investigate the affected reporter's path and participation. Avoid declaring the entire collection service healthy or broken from a single observation.
Close the incident with an observable result
Retain the policy answer, destination permission where applicable, delivery evidence, ingestion outcome and a report visible under the intended account and period. Record which stage failed and who owns its maintenance.
After collection resumes, use the report interpretation guide to examine the data. If the policy is missing from DNS, use missing-record diagnosis. Collection is restored when the evidence can be followed through the chain, not simply when a graph changes.
Primary section references: RFC 9990 §3.4, RFC 9990 §3.5, RFC 9990 §4, RFC 9990 §8, RFC 9989 §4.7, RFC 9989 §4.10.