Summary

  • RFC 9991 lets a Domain Owner request detailed feedback about messages that fail DMARC, but a Mail Receiver still decides whether to generate a report, which report type to send and what its privacy policy permits it to disclose.
  • A verified external destination has authorized receipt of a reporting relationship; that verification does not approve every header, address, message body, attachment, retention period or downstream use.
  • The reliable control chain separates authentication failure, reporting request, disclosure decision, redaction, delivery, report validation and any automated response.

Imagine a legitimate employee sending a calendar invitation through a forwarding service. The forwarder alters enough of the message to break DKIM, and SPF now evaluates the forwarder's path. DMARC fails at the final receiver. The Author Domain publishes a ruf address operated by a deliverability contractor.

Every technical fact can be accurate. The receiver really observed a failure. The DNS record really requests a report. The external consumer may really have published the authorization record expected by the verification procedure. Yet an unredacted failed-message report can reveal the invitation, the recipient, trace headers and an employment discussion to a party outside the original exchange.

The decisive question is not whether the failure exists. It is who may move which evidence across the receiver's boundary.

RFC 9991 standardizes a request, not compelled production

RFC 9991, published on the IETF Standards Track in May 2026, describes DMARC failure reports. They provide message-level detail more quickly than aggregate reports and can help a Domain Owner distinguish intended traffic that broke authentication from unauthorized use of its domain.

The mechanism begins with a request. RFC 9989 defines the ruf destination and fo options in the DMARC Policy Record. A Domain Owner can say where it would like failure feedback sent and under which failure conditions.

That DNS publication does not make the receiver a passive exporter. RFC 9991 says a report is generated when the Domain Owner requests forensic analysis and the Mail Receiver is willing to provide it. The Receiver determines which failure-report types, if any, to transmit according to its own policy, the observed failure and the published options.

This separation is operationally necessary. The Domain Owner has useful knowledge about its legitimate senders and abuse involving its name. The Mail Receiver possesses the message, serves the recipient, operates under its own privacy promises and bears the immediate cost of sending data. A shared protocol can express the request without transferring that responsibility.

A failure report can carry the communication, not merely the verdict

The information difference between aggregate and failure reporting is large. RFC 9990 groups observations over a reporting period: source addresses, counts, alignment results, evaluated policy and local override reasons. It is designed for statistical visibility.

RFC 9991 uses the authentication-failure form of the Abuse Reporting Format. RFC 5965 gives that report three parts: a human-readable explanation, machine-readable fields and either the original message or its complete header block. RFC 6591 supplies authentication-failure fields, and RFC 9991 adds DMARC-specific alignment reporting.

That detail aids diagnosis because it preserves evidence that counts cannot show. It also changes the disclosure class. Message headers can expose correspondents and routing. The body can contain legal advice, product plans, termination notices or calendar data. A forwarding path may reveal a final destination that the Domain Owner did not previously know. A mailing-list failure can expose membership.

An authentication failure does not make those people parties to the reporting contract. It may be caused by forwarding, a mailing list, configuration error, an expired key, a transient DNS problem or unauthorized use. Even when the message is abusive, an innocent recipient's address and private reply context do not become necessary merely because the attacker borrowed a domain.

RFC 9991 therefore recommends limiting failure reports to targeted diagnostic use, constraining their duration, validating destinations, redacting or minimizing data and using secure transport. It notes that many large providers restrict or disable these reports and prefer aggregates. That is not noncompliance with the reporting request. It is the receiver exercising the decision the standard leaves with it.

External-destination verification is reciprocal routing authority

A ruf address may be outside the Organizational Domain that published the DMARC record. It can belong to another division, a contracted analytics service or an unrelated destination inserted by mistake or malice.

RFC 9991 imports the external-destination verification procedure from RFC 9990, substituting ruf for the aggregate-report tag. Before sending, the Mail Receiver checks whether the external domain has published the expected authorization. This prevents one domain from unilaterally enrolling another domain to receive report traffic. It also limits a reflection pattern in which an attacker points a policy at a victim and induces receivers to send there.

The check answers a narrow question: has this external destination agreed to receive reports for that policy domain? It does not answer whether the sender's privacy policy allows the full message, whether the contractor's staff may read it, whether the destination forwards elsewhere, how long the material will be retained, or whether it will train a model or trigger enforcement.

Those questions require a disclosure profile beyond DNS: approved fields, forbidden classes, sampling, purpose, retention, onward transfer, incident handling and deletion. A green destination check is a routing authorization, not a universal data licence.

RFC 9991 makes another boundary explicit for Public Suffix Domain records. A ruf request on a record with psd=y must not be considered without specific agreements among interested parties. A high-level policy location must not become a channel for collecting message detail from every subordinate domain by default.

Identity-Alignment names a failed mechanism, not a guilty person

RFC 9991 updates the report with Identity-Alignment. The current IANA MARF registry defines it as a list of authentication mechanisms that failed to authenticate an aligned identity, or none when all attempted methods succeeded.

This is precise protocol evidence. It helps a consumer see whether DKIM, SPF or both failed the DMARC alignment test. It does not identify the human who composed the message, show that the Author Domain intentionally sent it, prove fraud or determine why alignment broke.

The word “Identity” can invite a much larger conclusion than the field carries. Leadership systems should preserve the full name Identity-Alignment, the evaluated domains, result, receiver and time. A dashboard that shortens it to “identity failed” silently turns a domain-comparison result into an accusation.

Redaction preserves utility but does not promise anonymity

RFC 6590 describes a useful redaction technique. A receiver can transform selected private strings consistently, allowing a consumer to correlate repeated reports involving the same hidden value without seeing the original value. A keyed transform can be stronger than replacing every address with the same mask.

Correlation is itself a capability. The consumer can learn that multiple failures involve one recipient or account. The stability window, key rotation and authorized purpose therefore matter. A stable token kept indefinitely can become a durable cross-report identifier.

Redaction is also incomplete by nature. A Message-ID, timestamp, unusual subject, trace path or log held by another party may re-identify the message. Human prose can contain names and facts that a generic filter will miss. RFC 6590 expressly warns that software is unlikely to recognize every way private information appears in natural language.

The correct record is not a Boolean redacted=true. It is a versioned transformation profile: which fields were removed, which were tokenized, which key epoch was used, which content classes were scanned, which residual risks were accepted and who approved the purpose. If the receiver cannot create a report proportionate to that purpose, the safe result may be an aggregate report or no report.

A well-formed report is still an assertion

ARF makes reports machine-readable, but RFC 5965 warns that its fields are assertions and are not necessarily verifiable. Report content can be mistaken, incomplete or deliberately false. The format does not supply substantial security for every claim.

Origin authentication protects one boundary: it helps the consumer know which reporting system sent the artifact and whether transport altered it. It does not make the receiver's interpretation correct. A valid Auth-Failure field cannot prove that a named sender committed abuse. A validly signed report can still carry a parser exploit, malware sample or misleading derived field.

Automated action therefore needs a second policy. The consumer should validate the reporting relationship, format, size, field consistency and attached content; quarantine hostile material; correlate with its own sending records; and distinguish a configuration repair from account suspension or legal escalation. The RFC 6449 feedback-loop guidance treats such exchanges as operational relationships, not consequence-free public mailboxes.

Reporting can become the attack

RFC 9991 requires outgoing rate limits. Without them, an attacker can send a large volume of messages claiming a victim's domain, deliberately fail SPF and DKIM, and cause participating receivers to generate reports toward the victim or its processor.

Volume is only one cost. A report can replicate spam, phishing links and malicious attachments into a trusted analysis environment. RFC 9991 recommends neutralizing active web links and removing attachments; consumers should isolate report streams, sandbox content, segment processing and restrict human access.

The limit should follow both policy domain and destination, with global and tenant budgets. Otherwise, many domains can target one consumer within their individual allowances. Similar failures can be consolidated using the ARF Incidents field. The aim is to communicate different failure conditions, not to preserve a one-message-one-report ritual.

Report mail can also fail DMARC. RFC 9991 recommends aligned report streams and cautions about loops. Monitoring must treat a failure report that produces another failure report as a control fault, not useful recursive evidence.

The evidence chain has seven decisions

Heng Lu's Reality Layers supplies a disciplined reading. The observed authentication failure, the DNS reporting request, the receiver's privacy decision, the report bytes, the delivery, the consumer's interpretation and the operational response are seven related realities. None can substitute for the next.

Minimum Initial Specification and Localized Future Decision explains why the split is a strength. Internet interoperability needs common tags, fields, verification and failure behavior. It does not need a central rule forcing every receiver to disclose the same content under every jurisdiction and user promise.

Running-Code Primacy locates the final evidence in execution: which evaluator produced the failure, which branch elected to report, which transform changed the content, which DNS authorization was observed, which bytes left, which consumer accepted them and which account or rule changed afterward.

A domain can legitimately request diagnostic evidence. The receiver can legitimately decline, aggregate or minimize it. The external consumer can legitimately accept a bounded stream. Governance begins when those decisions remain visible instead of being compressed into “DMARC reporting enabled”.