Why Your DMARC Reports Are Empty

An empty DMARC reporting view does not have one universal cause. The record may be invalid, the destination may not be authorised, no relevant mail may have reached a participating receiver, or reports may be arriving but failing during mailbox or ingestion processing.

Start by deciding which report type is missing. Aggregate reports requested through rua are different from message-specific failure reports requested through ruf, and receiver support is not the same for both.

1. Confirm that DMARC resolves correctly

Query TXT records at:

_dmarc.example.co.za

The effective result must contain one valid DMARC record. Common problems include:

• publishing the record at the root domain rather than _dmarc;
• leaving a placeholder or malformed address in rua;
• missing separators between tags;
• publishing more than one DMARC record at the same name;
• line breaks or quotation handling that changes the DNS value; and
• editing a different DNS zone from the one delegated publicly.

Use an authoritative DNS query as well as a recursive query when troubleshooting. This helps separate a publication error from cached or resolver-specific behaviour.

2. Inspect the exact rua value

An aggregate-report request commonly includes a value such as:

rua=mailto:dmarc-reports@example.co.za

Check that:

• the URI starts with mailto:;
• the address is spelled correctly;
• the destination mailbox or service exists;
• the ingestion service expects reports for the domain; and
• the address is not being rewritten or disabled upstream.

Do not send passwords, DNS credentials, or private keys to a public support form while troubleshooting.

3. Complete external-destination authorisation

When reports for example.co.za are sent to an address at a different organisational domain, the destination can need to publish a DNS authorisation record. Without it, a receiver can decline to send reports to that external address.

Use the destination provider’s exact setup instructions and validate the authorisation in public DNS. An application showing that the address was entered is not proof that receiver-side authorisation succeeds.

If the destination is operated by a DMARC service, confirm that the customer domain was added to the correct tenant and that the provider-supplied DNS values were copied exactly.

4. Verify that relevant mail was observed

Aggregate reports are based on messages a participating receiver observed. A technically valid record can produce no report when:

• the domain sends no mail;
• test mail was sent only within one internal environment;
• no message reached a participating external receiver;
• a subdomain or different visible From domain was used; or
• the test used a provider domain in the visible From address instead of the domain under review.

Send controlled, legitimate samples through each intended path to test recipients you are authorised to use. Inspect the delivered headers and confirm the visible From domain, return path, and DKIM signing domain.

Do not generate unsolicited bulk traffic merely to trigger reporting.

5. Allow for DNS and reporting cycles

DNS caches can retain an earlier record until their time to live expires. Receivers also aggregate observations over reporting periods and deliver on their own schedules within the applicable standards and operating policies.

Allow for:

1. the public record to become visible;
2. real messages to reach participating receivers after publication;
3. the receiver’s reporting period to close; and
4. delivery and processing by the destination.

There is no universal arrival time. If reports were previously flowing and stop abruptly across several known senders, investigate configuration and ingestion rather than assuming ordinary delay.

6. Check the destination mailbox or ingestion path

Reports can arrive as compressed XML attachments. Mail or security controls may quarantine, reject, strip, or rewrite them.

Check:

• spam, quarantine, and transport rules;
• mailbox size and message-size limits;
• attachment and archive handling;
• accepted sender or report validation rules;
• aliases and forwarding rules;
• parser error or dead-letter logs;
• tenant/domain mapping; and
• access permissions in the reporting application.

Search by report metadata and attachment type rather than relying only on a familiar subject line. If raw reports arrive but the dashboard is empty, the problem is likely after mail receipt.

7. Separate aggregate and failure-report expectations

rua requests aggregate feedback. ruf requests message-specific failure reports. A receiver can provide aggregate reports while declining or limiting failure reports.

Failure reporting also has additional privacy and operational considerations. The current formats are described in RFC 9990 for aggregate reports and RFC 9991 for failure reports.

Do not use an empty ruf mailbox as evidence that DMARC has no failures. Aggregate evidence and controlled samples are generally more dependable starting points.

8. Check effective policy discovery

Subdomains can inherit DMARC policy and reporting behaviour from a higher-level domain. Confirm:

• which domain appears in the visible From address;
• whether a record exists at that exact _dmarc name;
• whether discovery falls back to an organisational or public-suffix policy; and
• which report destination belongs to the effective record.

This matters when a test is sent from a subdomain but the reporting service is configured only under the parent domain or a separate tenant object.

9. Compare independent evidence

Use more than one evidence source:

• authoritative and recursive DNS results;
• the raw DMARC record and destination authorisation;
• headers from controlled messages;
• destination mail-flow logs;
• raw XML or archive files;
• parser and application logs; and
• reports from more than one participating receiver when available.

This sequence helps locate the gap: publication, observation, receiver generation, transport, ingestion, or presentation.

Worked example: find where the evidence stops

This is a synthetic example using reserved domains, not a live DNS test or customer incident. Assume the DMARC policy is published at _dmarc.example.com and requests reports at aggregate@reports.example.net.

On a system with dig installed, these are read-only queries. Replace the example names with the exact domain and destination you are authorised to investigate:

dig +noall +answer TXT _dmarc.example.com
dig +noall +answer TXT example.com._report._dmarc.reports.example.net

The expected policy value in this example is:

v=DMARC1; p=none; rua=mailto:aggregate@reports.example.net

The second name is in the report destination’s DNS, not the sender’s zone. A valid authorisation response can contain v=DMARC1;. A provider may authorise destinations through a wildcard; query the exact constructed name rather than assuming an individually named record must exist. This construction follows RFC 9990’s external-destination verification procedure.

An empty +answer result is not a diagnosis. Re-run without +noall +answer to inspect the response status and authority section: no TXT answer, NXDOMAIN, SERVFAIL and a timeout need different investigations. To compare publication with caching, obtain the authoritative nameserver for the zone containing the record, then query that server directly:

dig @ns1.example.net +norecurse TXT _dmarc.example.com

Here ns1.example.net is a placeholder for that zone’s actual authoritative server. Do not use it as a real troubleshooting endpoint.

For escalation, record the UTC test time, exact queried names, response status, TTL, tested From domain, destination and the last confirmed stage. Share report IDs and redacted evidence through the agreed support channel. Keep message content, recipient details and credentials out of public tickets.

A practical diagnostic order

1. Validate the effective DMARC record and rua syntax.
2. Validate external-destination authorisation if domains differ.
3. Confirm the destination mailbox or tenant mapping.
4. Send an authorised controlled message to an external recipient.
5. Inspect headers to confirm the tested From domain and authentication results.
6. Allow for DNS and the receiver’s reporting cycle.
7. Search raw mail, quarantine, and ingestion logs.
8. Compare another participating receiver if available.
9. Document the evidence and escalate to the relevant DNS, mail, or reporting owner.

Avoid changing policy strength merely to make reports appear. Report delivery depends on rua, authorisation, observed mail, and receiver participation—not on moving from p=none to p=reject.

Frequently asked questions

Do I need p=reject to receive aggregate reports?

No. A valid monitoring policy can request aggregate reports. Policy progression should follow evidence and delivery risk, not report troubleshooting.

Does no report mean no one is using the domain?

No. It means the configured destination has not received or presented a report you can see. Receiver participation, traffic, DNS, transport, and processing all need to be considered.

Should I publish both rua and ruf?

They request different data. Choose destinations and retention based on operational need, receiver support, privacy, and governance. Do not assume ruf will be widely available.

Can a public checker confirm report delivery?

A checker can inspect public syntax and some authorisation records. It cannot prove that a receiver observed mail, generated a report, or that the destination processed it successfully.

Next step

Use the Vigil DMARC checker to confirm the public record, then follow the diagnostic order above. If the DNS looks correct but raw reports still do not arrive, contact Vigil with the domain, the approximate test period, and non-sensitive evidence from the reporting path. WISPs coordinating this across customer domains can use the WISP scope and workflow guide to define ownership, DNS handoffs, and escalation.