Domain-Based Message Authentication, Reporting, and Conformance (DMARC) Failure Reporting
obsoletes
- rfc-7489 — Domain-based Message Authentication, Reporting, and Conformance (DMARC)
updates
- rfc-6591 — Authentication Failure Reporting Using the Abuse Reporting Format
Extracted elements (22)
External destinations for failure reports must be verified to prevent a bad actor from publishing a DMARC Policy Record that abuses a third-party destination by deliberately sending messages that trigger failure reports, and to prevent Domain Owners from unilaterally directing unwanted reports to external parties.
Failure reports are generated and sent almost immediately after detecting a DMARC failure, unlike aggregate reports, to quickly notify Domain Owners of authentication failures and to provide richer per-message detail useful for diagnosing whether a failure involves authorized or abusive use of the domain.
Many large-scale providers limit or entirely disable failure report generation, preferring aggregate reports that provide statistical visibility without exposing sensitive message content. This document acknowledges that privacy concerns have led operators to restrict failure reporting and recommends limiting its use to targeted diagnostic activities with minimization techniques.
A Mail Receiver generating DMARC failure reports MAY also issue DKIM-specific or SPF-specific failure reports (per RFC 6591) instead of or in addition to the DMARC failure report type. Reporters are also free to follow RFC 6651 (DKIM failure reporting) or RFC 6652 (SPF failure reporting) specifications.
This document updates RFC 6591 (Authentication Failure Reporting Using ARF) by adding the Identity-Alignment field and the 'dmarc' Auth-Failure type, and obsoletes RFC 7489 as part of the DMARC suite split into RFC 9989, RFC 9990, and RFC 9991.
A DMARC failure report MUST include the Identity-Alignment ARF header field (REQUIRED), and DKIM-Domain, DKIM-Identity, DKIM-Selector are REQUIRED for DKIM failures of an aligned identifier.
A Mail Receiver generating failure reports to external destinations MUST use the Verifying External Destinations procedure from Section 4 of RFC 9990, substituting the 'ruf' tag where 'rua' appears.
Email streams carrying DMARC failure reports SHOULD be DMARC-aligned to prevent unaligned reports from producing subsequent failure reports that could cause mail loops.
Report generators MUST implement a rate-limit on outgoing reports so as not to flood Report Consumers with excessive reports, which would allow denial of service.
Report generators MUST NOT consider 'ruf' tags in DMARC Policy Records that have a 'psd=y' tag, unless there are specific agreements between the interested parties.
SPF-DNS is REQUIRED in DMARC failure reports for SPF failure of an aligned identifier. Delivery-Result, DKIM-Canonicalized-Header, and DKIM-Canonicalized-Body are OPTIONAL.
The Receiver SHALL determine which failure report types, if any, to transmit based on its own policy, the failure in question, and the content of the 'fo' tag in the retrieved DMARC Policy Record.
When multiple URIs are provided to receive failure reports, the report generator MUST make an attempt to deliver to each of them. External destinations MUST be verified per the procedure in Section 5.
A DMARC Policy Record can direct reports to a third-party Report Consumer, enabling traffic analysis and metadata collection about the Mail Receiver's traffic. Mail Receivers must consider their privacy policies before sending reports to third parties; a Domain Owner may also publish an apparently internal address that actually forwards reports elsewhere.
Failure reports may include PII and NPI from failed messages, including full message content and trace header fields, exposing sender/recipient identifiers and potentially sensitive business data such as product launches, termination notices, or calendar data to unintended recipients.
Mailing list and forwarding scenarios can expose hidden recipients: failure reports generated when a forwarded message fails authentication are sent to the original Domain Owner, revealing final destinations previously unknown to them.
Partially or unredacted failure reports may propagate large amounts of spam, phishing, or malware content to Report Consumers. Mitigations include substituting 'hxxp' for 'http' in URIs, removing attachments, isolating report mail streams, using sandboxes, and limiting access to authorized individuals.
A DMARC failure report is an augmented ARF (RFC 6591) message including: Identity-Alignment (REQUIRED), Delivery-Result (OPTIONAL), DKIM-Domain/Identity/Selector (REQUIRED for DKIM failures), SPF-DNS (REQUIRED for SPF failures), and optionally canonicalized DKIM header/body fields.
The Authentication Failure Type 'dmarc' is defined for the Auth-Failure ARF field, used when a failure report is generated because some or all authentication mechanisms failed to produce aligned identifiers.
IANA updated the 'Identity-Alignment' entry in the 'Feedback Report Header Fields' registry (MARF Parameters group): Field Name 'Identity-Alignment', Related Feedback-Type 'auth-failure', Status 'current', Reference RFC 9991.
Failure reports represent a possible denial-of-service attack: an attacker sending numerous messages purporting to be from a victim Domain Owner but failing SPF and DKIM causes participating Mail Receivers to flood the Domain Owner with reports. Mitigation includes aggregating reports via the ARF Incidents field, storing reports before sending, and applying rate-limiting.
The Identity-Alignment field carries a comma-separated list of authentication mechanism names ('dkim' and/or 'spf') that failed to authenticate an aligned identity, or the keyword 'none' if all attempted methods succeeded. ABNF: id-align = 'Identity-Alignment:' [CFWS] ( 'none' / dmarc-method *( [CFWS] ',' [CFWS] dmarc-method ) ) [CFWS]; each method may appear at most once.