Email glossary · Practical guide
DMARC rua: the destination for aggregate reports
The rua policy tag requests aggregate DMARC reports at designated destinations. It does not direct ordinary replies or prove that every receiver will send a report.
Reviewed · Examples are illustrative
Who this helps: Readers checking a term before making an outreach or mailbox decision.
Meaning and common confusion
Reporting requires an appropriate destination and a process for reading the resulting data. A third-party reporting service may require additional authorization. Treat report delivery, parsing and interpretation as separate checks rather than assuming that publishing an address completes monitoring.
Worked example
This is a synthetic illustration, not a customer result or a live configuration to copy.
Policy destination: a dedicated aggregate-report mailbox
Expected artifact: reports about evaluated traffic
Not expected: normal customer replies
Review: source, reporting interval and observed identities before drawing conclusions.Checks to make
- Verify that the destination is controlled and monitored.
- Follow the reporting provider's authorization instructions.
- Check report coverage before interpreting missing traffic as zero activity.
Next step and limits
Use the aggregate-report walkthrough to interpret a sample. Keep reports in an appropriate access-controlled location; they describe infrastructure and traffic. This glossary entry is not a promise of native DMARC report ingestion in Zintara.
Source references
Worked examples are illustrative. Editorial procedures are suggested methods, not measured performance claims or promises of additional product features.
Related guides
- DMARC aggregate report walkthrough: turn rows into sender decisions →
- Set up DMARC with a sender inventory and a working report destination →