Most domains should skip DMARC ruf failure reports, or enable them only briefly with a clear purpose. RFC 9991 warns they can contain header fields or even the whole failed message, which may include personal data. Many operators restrict their use for that reason, so do not count on receiving them.
What failure reports are
Aggregate reports (rua) are statistics. Failure reports (ruf) are about individual messages. RFC 9991 says they provide detailed information about a single message, or a group of similar messages failing for the same reason. Their purpose is to help find the cause of failures seen in aggregate data and to spot direct domain abuse quickly.
You request them with the ruf tag, and the fo tag controls when they are generated. The default, fo=0, asks for a report only when all authentication mechanisms fail to produce an aligned pass. fo=1 asks when any mechanism fails. Options d and s ask for DKIM or SPF specific reports. The fo tag is ignored without a ruf tag.
The privacy problem
RFC 9991 is direct about the risk. Reports may include personally identifiable information and non-public information from the original message. It lists steps for those who choose to enable them, such as minimization techniques like redacting message bodies and header fields.
The document also notes that the privacy concerns have led many operators to restrict their use. That is a practical reason not to build a process that depends on them.
There is a second concern. Reports could be abused: an attacker can send messages designed to trigger reports toward a victim address. The RFC recommends rate limits for generators.
When they can still be useful
- A short investigation of a phishing campaign using your domain, with a dedicated mailbox.
- Debugging a stubborn alignment failure where aggregate data is not enough.
Even then, treat the mailbox as sensitive: restrict access, set a retention period, and delete when done.
If you do enable them
- Use a dedicated address, not a shared inbox.
- Limit who can read it and record that access.
- Decide how long you keep messages. Write it down.
- Include the mailbox in your records of processing if you handle personal data from the EU. A review by whoever owns privacy for your company is sensible.
- Turn the tag off when the investigation ends.
Better alternatives
For most teams, aggregate reports plus an email gateway log give enough to fix problems. Aggregate data shows source IPs, counts and results without message content.
Quick check
Will I get ruf reports if I publish the tag?
Not necessarily. Receivers decide whether to send them, and RFC 9991 notes many have restricted them. Treat any reports as a bonus.
Sources
Last reviewed: 19 October 2026.
