Summary

  • RFC 9991 defines detailed DMARC failure reports for an individual failed message or a group of similar failures, often delivered sooner and with more diagnostic material than an aggregate report.
  • A Domain Owner's ruf and fo settings request that detail. The Mail Receiver still decides which report types, if any, to send under its own policy, and must consider privacy, minimization, rate limiting and secure handling.
  • Daniel Kade proposes a purpose-limited failure-disclosure receipt that records why a bounded set of data was released and how it was protected, without retaining the message body, addresses, credentials or hostile payload.

The most useful attachment may be the one that cannot be sent

Imagine an authentication engineer looking at a sudden DKIM failure. An aggregate row says that several messages failed alignment. The cause could be a broken selector, an intermediary transformation, an unauthorized sender or a transient verification problem. One original header block might resolve the question in minutes.

That header can also expose a recipient, an internal host, a forwarding path, a mailing-list member or the subject of a confidential exchange. A full message can disclose far more: personnel decisions, calendar entries, product plans, credentials, tracking links or malicious attachments. Diagnostic value and disclosure harm inhabit the same bytes.

The easy administrative story is that the domain owner asked for the report, so the receiver owes it. RFC 9991 rejects that shortcut. It gives the owner a way to request failure reports and identify destinations. It gives receivers and consumers a common reporting format. It does not turn a DNS request into title over mail the requester did not necessarily send and may never have known existed.

That distinction is the article's Governance object. The protocol coordinates a request. Authority over disclosure remains local and accountable.

Request, generation and receipt are three decisions

RFC 9991 is a May 2026 Standards Track specification. Together with the core DMARC specification and the aggregate-reporting document, it replaces the relevant parts of RFC 7489; it also updates the earlier authentication-failure reporting rules.

The Domain Owner publishes ruf destinations and fo options in a DMARC Policy Record. Those values say where failure reports are requested and which failure conditions interest the owner. They are not a command channel. The receiving organization determines which report types, if any, it will transmit according to the failure, the requested option and its own policy.

That produces three separate decisions. The owner decides to ask. The receiver decides whether and how to disclose. The consumer decides how to handle and rely on what arrives. A green status at one layer cannot certify the others.

This matters because a failure report may describe one message or group similar incidents, may arrive nearly immediately and can carry substantially more detail than an aggregate report. The same speed that shortens diagnosis also shortens the time available for privacy review, destination validation and containment. Automation must preserve the boundaries rather than erase them.

More detail changes the evidence class

The Abuse Reporting Format places explanatory text, machine-readable feedback fields and original-message material in different MIME parts. RFC 9991 adds DMARC-specific meaning, including Identity-Alignment, relevant DKIM details, SPF DNS material and an authentication-failure type.

Identity-Alignment is deliberately narrow. It lists the authentication mechanisms that failed to authenticate an aligned identity, or says none when attempted mechanisms succeeded. It does not explain why a signature failed. It does not prove that the apparent author sent the message, that the message was malicious, that a receiver's later disposition was correct or that disclosure is authorized.

The original headers or body can answer questions the derived fields cannot. They can also introduce facts outside the original diagnostic purpose. Once copied into a report, those facts acquire a new custodian, a new retention clock and a new set of people and systems able to inspect them.

Calling the report “forensic” does not suspend that accounting. Forensics is a purpose, not an unlimited data category.

External authorization proves willingness, not entitlement

A policy record can direct reports outside its Organizational Domain. RFC 9991 reuses the external-destination authorization procedure from aggregate reporting. The destination publishes DNS material showing that it is willing to receive reports for the requesting domain. This stops a domain owner from unilaterally weaponizing receivers against an unwilling third party.

The check is necessary and bounded. It does not establish that every report is accurate, that every field is necessary, that the consumer has a lawful or contractual basis for the data, or that onward forwarding is controlled. RFC 9991 explicitly notes that a destination which appears internal can itself forward elsewhere. The final destination is not guaranteed merely by reading the advertised address.

Governance therefore needs two receipts: one for destination eligibility and another for disclosure proportionality. Collapsing them produces a subtle error—treating willingness to accept some reports as authority to receive any content a generator happens to possess.

Minimization must remain useful and bounded

RFC 9991 recommends targeted scope and duration, carefully controlled reporting URIs, redaction of bodies and headers, and secure transport. It also notes that many large providers restrict or disable failure reporting because the privacy cost is real.

Redaction is not equivalent to deletion. The earlier redaction specification describes a consistent, collision-resistant transformation that lets a consumer recognize when two obscured strings were originally identical. That preserves diagnostic grouping without revealing the source string. It also preserves linkability. If the same transform and secret persist for too long or across too many purposes, a pseudonymous token can become a durable cross-case identifier.

A sound implementation records the redaction version and scope, rotates or separates keys by purpose where appropriate, and prevents raw and redacted values from drifting into the same broad log estate. It also knows when correlation is unnecessary. The minimum useful disclosure is not always a stable token; sometimes it is a category, a one-time case identifier or no report at all.

Minimization should be tested against the diagnostic question. Remove too little and private correspondence travels unnecessarily. Remove too much and the report becomes decorative while still creating custody risk. The answer is a documented decision, not a universal field list.

Rate limiting makes absence interpretable only with a receipt

Failure reports can become a denial-of-service channel. An attacker can send large volumes of mail purporting to use a victim's domain and induce participating receivers to direct reports toward the victim or its delegate. RFC 9991 therefore requires outgoing rate limits and permits consolidation of similar incidents or discarding excess reports. Its aim is to expose different failure conditions, not count every failed message.

That is another reason a consumer cannot treat the stream as a complete event ledger. Silence can mean no qualifying failure, a receiver that does not participate, local privacy policy, aggregation, a rate-limit drop, transport failure or an expired diagnostic window. A burst can mean a new condition, a reporting-policy change or an induced flood.

The consumer needs the generator's declared sampling and rate-limit context before drawing volume conclusions. The generator needs a local record of what was suppressed and why without recreating a sensitive per-message archive. Counts by bounded reason and time window may be enough.

The report itself is untrusted content

Failure reports may contain spam, phishing, malware, deceptive links and attachments because they reproduce material from a failed message. The standard recommends isolation, sandboxing, segmentation and access restricted to trained authorized people. A consumer that routes these reports into ordinary mailboxes, ticket previews or indexing systems can widen the very incident it intended to study.

Aligned DMARC on the report stream helps bind a sending domain to the transport identity expected by the receiver. It does not make embedded content safe, prove every assertion in the machine-readable part or authorize every analyst to see the original message. Authentication, content safety, data entitlement and operational access remain separate controls.

The most valuable automation may therefore be negative. It can strip active content, refuse unsupported MIME structures, quarantine attachments, cap decompression and parsing work, and withhold a report from general search. A successful parser is not the end of the decision; it is the start of controlled custody.

A purpose-limited failure-disclosure receipt

I propose a compact receipt for each disclosure policy and every exceptional release. This is editorial guidance, not an additional IETF requirement.

The receipt begins with the DMARC policy domain, DNS lookup time and result, requested ruf destinations and fo condition, external-destination authorization result, receiver policy version and the purpose with an expiry date. It identifies the failure class and whether the case is individual or grouped.

It then lists data categories selected—not the data itself—such as derived authentication fields, trace-header subset, redacted address token or bounded message excerpt. It records the redaction method and version, correlation scope, grouping rule, rate-limit outcome, secure-transport result and any generator error. On the receiving side it binds the consumer role, access boundary, isolation result, retention deadline and deletion or supersession event to an accountable decision.

The receipt must not become a shadow mailbox. Message bodies, local parts, recipient addresses, credentials, live malicious URLs and attachments stay outside it. Content fingerprints should be used only where the risk and purpose justify them, with clear scope and expiry.

This gives both parties an answer when somebody later asks, “Why did these bytes cross this boundary?” The answer is not “because DNS asked.” It is a chain of local decisions made visible enough to review.

Sources

  1. Lu Heng — Data Sovereignty: Technical vs Practical Realities
  2. Lu Heng — Why BTW Media Exists
  3. Lu Heng — The Policy Mirror
  4. IANA — Messaging Abuse Reporting Format Parameters
  5. RFC 9991 information page
  6. RFC 5322 — Internet Message Format
  7. RFC 5965 — An Extensible Format for Email Feedback Reports
  8. RFC 6590 — Redaction of Potentially Sensitive Data from Mail Abuse Reports
  9. RFC 6591 — Authentication Failure Reporting Using ARF
  10. RFC 6650 — Creation and Use of Email Feedback Reports
  11. RFC 7489 — DMARC
  12. RFC 9989 — DMARC
  13. RFC 9990 — DMARC Aggregate Reporting
  14. RFC 9991 — DMARC Failure Reporting