RFC 6591 — ARF failure reporting

Authentication Failure Reporting Using the Abuse Reporting Format

Status
Proposed Standard
Published
2012

RFC 6591 defines the report format that DMARC failure reports extend. It adapts the Abuse Reporting Format — originally designed for “this is spam” complaints — to carry authentication failures instead.

If you receive ruf= reports at all, this is the format they arrive in, with the DMARC-specific additions in RFC 9991.

What it carries

An ARF report is a multipart message: a human-readable part, a machine-readable part, and the offending message or its headers. RFC 6591 adds the fields that make it about authentication rather than abuse:

  • Auth-Failure — which check failed: spf, dkim, dmarc, and others
  • Delivery-Result — what the receiver did with the message
  • The identifiers involved, so the report says which domain and selector failed rather than merely that something did

RFC 9991 makes several of these mandatory for DMARC use, including Identity-Alignment and the DKIM selector.

Why it matters less than it should

The format is sound. The problem is what it necessarily contains: parts of a real message, sent to a third party, without the sender’s or recipient’s consent.

That is why failure reporting is rare in practice. Most large mailbox providers concluded the privacy exposure was not defensible and stopped generating these reports, which is why a correctly published ruf= address can sit empty indefinitely.

What to do with it

Understand the format if you are building something that parses failure reports. Otherwise, treat this as background: the reason you receive aggregate reports in volume and failure reports almost never is a privacy decision made years ago, not a misconfiguration on your side.

Reading one if you get one

Failure reports arrive as multipart messages rather than the XML of an aggregate report, so tooling built for one will not parse the other. The machine-readable part uses message/feedback-report, and the original message or its headers follow as a further part.

Expect them to be redacted. RFC 9991 explicitly encourages minimisation, so a report may carry headers only, with addresses partially obscured — enough to identify the sending source, not enough to reconstruct the message.

Read it: rfc-editor.org/rfc/rfc6591