DMARC failure reports and the ruf= tag
Forensic reports carry real message data, one per failure. Few receivers send them and the privacy cost is real, but they answer what aggregates cannot.
Aggregate reports tell you that 148 messages from an IP failed. Failure reports, configured with ruf=, tell you what one of those messages was: headers, and in some formats the body, of an individual message that failed authentication.
Why they are rare
A failure report forwards someone's mail to a third party. Most large receivers decided that was incompatible with their privacy obligations and stopped sending them. If you publish ruf=, expect little and be glad of what arrives.
Configuring them
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; ruf=mailto:forensics@example.com; fo=1- fo=0 reports only when everything fails. The default.
- fo=1 reports when any mechanism fails, even if DMARC overall passed. The most useful setting for debugging.
- fo=d reports on DKIM failures specifically.
- fo=s reports on SPF failures specifically.
Whatever arrives at the ruf address is other people's correspondence, including possibly your own users'. Restrict access, set a retention limit, and check it fits your privacy policy before publishing the tag.
When to use them
Turn ruf= on temporarily while diagnosing a specific failure you cannot explain from aggregate data, such as an intermittent alignment problem or a signature breaking on one path. Turn it off again afterwards.
More on DMARC
What DMARC actually does
DMARC binds SPF and DKIM to the From address your recipients see, tells receivers what to do on failure, and sends you reports about it.
Every DMARC tag, and which ones matter
A DMARC record has eleven possible tags. Four of them do the work; the rest are tuning you will rarely touch.
Publishing your first DMARC record
Start at p=none with a reporting address. It changes nothing about delivery and gives you the data you need for every decision that follows.