[ Reports & investigation ]
DMARC failure reports: availability, usefulness and limitations
Use message-specific reports as optional, sensitive diagnostic evidence rather than a complete feed of authentication failures.
By the EmailAuth research team · 3 min read
[ Key points ]
- Failure reports may expose private message content.
- External DNS permission does not replace data-sharing approval.
- Use narrow diagnostic collection with a review date.
[ Takeaway ]
Use narrow diagnostic collection with a review date.
[ By role ]
What this means for you
Choose your role for practical next steps.
IT / Mail Admin
Prepare safe report intake
A working address is not a complete reporting system.
Next steps
- Verify external authorization.
- Correlate reports with route evidence.
- Handle embedded content as untrusted.
CISO / SecOps
Treat reports as sensitive evidence
Failure reports can expose private communications and malicious content.
Next steps
- Restrict access and forwarding.
- Approve retention and processing.
- Review continued collection necessity.
Founder / Non-technical
Ask for only useful detail
More message data creates obligations as well as diagnostic value.
Next steps
- Define the question first.
- Prefer controlled samples when sufficient.
- Set a collection review date.
[ FAQs ]
Frequently asked questions
Does publishing ruf guarantee reports?
No. Receivers may limit or decline failure reporting, including for privacy reasons.
Are failure reports the same as aggregate reports?
No. Failure reports can contain message-specific details; aggregate reports summarize observations and counts.
Will every failure generate one report?
Do not rely on that. Receiver participation, rate limits and report behavior prevent complete one-to-one accounting.
Can failure reports include message content?
Yes. Content and headers may be included subject to the reporter’s policies and redaction choices.
Does an external destination need authorization?
Yes where required by the external-destination verification procedure, and organizational data-sharing approval remains separate.
Can missing failure reports prove the problem is gone?
No. Use other evidence, including controlled tests and aggregate observations.
Should reports go to an ordinary shared inbox?
Use a restricted intake with safe handling, a named owner and retention controls.
[ Sources ]
Sources
[ Glossary ]
Glossary
- Identifier alignment
- The required relationship between the author domain and an authenticated SPF or DKIM domain for DMARC.
- Aggregate reporting request (rua)
- A DMARC tag specifying destinations for aggregate authentication reports.
- Failure reporting request (ruf)
- A DMARC tag specifying destinations for potentially sensitive message-specific failure information.
- Failure reporting options (fo)
- Requested failure-report conditions, considered only with a ruf destination; they do not change the DMARC pass condition.
- Reported disposition
- The receiver-reported DMARC-related treatment, distinct from a complete final-delivery audit.
- Reporting coverage
- The receivers, periods and observed traffic represented in an available report set, not necessarily all mail sent.
- Retention schedule
- An approved purpose-based rule for keeping and disposing of a defined record class, including exceptions and copies.
Enterprise provenance
Why top financial institutions and governments retired their email security dashboards.
Traditional email authentication platforms sell you a dashboard and ask your engineers to do the labour. In high-stakes environments, manual oversight means delayed enforcement, configuration drift and unmonitored shadow domains.
EmailAuth is the agentic email provenance platform. Our agents enforce p=reject, keep third-party senders aligned and move your domains to full RFC 9989 compliance, the new DMARC standard,, with human-in-the-loop auditability.
SaaS · Dedicated tenancy · Air-gapped on-prem · BYOK encryption