RFC 9991: The New DMARC Failure Reporting Standard Explained

In May 2026, the IETF published RFC 9991 — the official DMARC Failure Reporting standard. Together with RFC 9989 (core DMARC) and RFC 9990 (aggregate reporting), it obsoletes RFC 7489, the original DMARC specification that has governed email authentication since 2015. Here is what changed, why it matters, and what you need to do about it.

Background: Why RFC 7489 Was Replaced

RFC 7489, published in March 2015, was the first formal DMARC specification. It covered everything — the core protocol, policy syntax, aggregate reporting, and failure reporting — in a single document. Over the following decade, implementors discovered ambiguities, edge cases, and operational gaps. Privacy regulations grew stricter. Deployment at scale revealed denial-of-service risks. The DMARC working group spent years refining the specification before publishing the 2026 update as three separate RFCs:

• RFC 9989 — Core DMARC protocol: policy syntax, identifier alignment, policy evaluation, and the overall framework.
• RFC 9990 — Aggregate Reporting: the XML report format, delivery rules, and external destination verification for rua= reports.
• RFC 9991 — Failure Reporting: the format and rules for per-message failure reports (ruf=), including the new Identity-Alignment field and mandatory rate limiting.

What RFC 9991 Covers

RFC 9991 focuses exclusively on DMARC failure reports — also called forensic reports — which are generated when an individual message fails DMARC authentication. These reports are requested via the ruf= tag in your DMARC record and are distinct from the daily aggregate XML reports sent to your rua= address.

Failure reports are generated almost immediately after a Mail Receiver detects a DMARC failure. Their purpose is twofold: to help Domain Owners diagnose authentication failures seen in aggregate reports, and to rapidly identify unauthorized use of their domain in phishing or spoofing campaigns.

What Changed From RFC 7489

1. The New Identity-Alignment ARF Field

The most technically significant change in RFC 9991 is the formal definition of the Identity-Alignment header field for ARF (Abuse Reporting Format) failure reports. This field was not standardized in RFC 7489.

The ABNF grammar defined in the RFC is:

id-align     = "Identity-Alignment:" [CFWS]
               ( "none" /
                 dmarc-method
                 *( [CFWS] "," [CFWS] dmarc-method )
               )
               [CFWS]

dmarc-method = ( "dkim" / "spf" )
               ; each may appear at most once in an id-align

This field is REQUIRED in DMARC failure reports under RFC 9991. Combined with the existing ARF field Auth-Failure, it gives report consumers a precise, machine-readable indicator of what failed and why.

2. Formal Auth-Failure Type for DMARC

RFC 9991 formally defines dmarc as an authentication failure type for the ARF Auth-Failure field. This value is used when a failure report is generated because some or all of the authentication mechanisms failed to produce aligned identifiers. In a properly formed RFC 9991 failure report, you will see:

Auth-Failure: dmarc
Identity-Alignment: dkim
DKIM-Domain: example.com
DKIM-Identity: @example.com
DKIM-Selector: mail

This is more precise than the reporting approach in RFC 7489, which relied on implementors independently deciding how to express DMARC-specific failures in ARF format.

3. Mandatory Rate Limiting

One of the most operationally important additions in RFC 9991 is the explicit requirement that report generators MUST implement rate limiting. This was implicit best practice under RFC 7489 but is now normative:

Recommended rate-limiting strategies from the RFC include:

• Storing reports for a period before sending them, allowing similar failures to be detected, collected, and consolidated using the ARF Incidents field.
• Setting a maximum number of reports per minute that will be generated, with the remainder discarded.
• Aggregating failures that share the same root cause rather than reporting each message individually.

This matters because an attacker can deliberately send large volumes of messages that fail both SPF and DKIM, causing Mail Receivers to flood a domain's ruf= address with reports. Without rate limiting, this becomes a practical denial-of-service vector.

4. External Destination Verification Is Now Explicit

RFC 9991 requires that when failure reports are sent to an external destination (a domain different from the Organizational Domain of the DMARC record), the Mail Receiver MUST follow the external destination verification procedure defined in RFC 9990 Section 4, substituting the ruf tag wherever rua appears.

This prevents two classes of abuse:

1. A bad actor publishing a DMARC record pointing ruf= at an external domain and then deliberately sending failing messages to flood that domain with reports.
2. A Domain Owner unilaterally directing failure reports to a third party without that party's consent.

Under RFC 7489, external destination verification existed for aggregate reports but the language around failure reports was less explicit. RFC 9991 closes that gap.

5. Transport Alignment for Report Streams

RFC 9991 states that email streams carrying DMARC failure reports SHOULD be DMARC-aligned. This means the sending infrastructure that delivers failure reports to Domain Owners should itself pass DMARC. The rationale: unaligned reports can trigger additional failure reports, creating mail loops.

6. PSD DMARC Restriction

RFC 9991 introduces an important restriction for Public Suffix Domains (PSDs): 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. This prevents PSDs — which apply policy to many organizational domains below them — from inadvertently collecting failure reports about unrelated organizations.

Privacy: The Underlying Tension

RFC 9991 dedicates an entire section to privacy considerations, reflecting a significant shift in tone from RFC 7489. The RFC is candid: failure reports can expose substantial amounts of personally identifiable information (PII) and non-public information (NPI).

What Failure Reports Can Expose

• Message headers: From, To, Subject, Date, and all trace headers. These contain sender and recipient email addresses.
• Message body: RFC 9991 reports may include the full message body, not just headers. This can expose product launch details, termination notices, calendar data, or other confidential content.
• Mailing list membership: When a list member sends a message to a mailing list, failure reports can inadvertently reveal the identities of all list subscribers who received the forwarded message.
• Forwarding chains: Failure reports can expose intermediate destinations in message forwarding arrangements that are not known to the original sender.
• Third-party report consumers: If ruf= points to a third-party reporting service, that service receives detailed data about your email traffic, which may conflict with your privacy policy or applicable regulations.

What RFC 9991 Recommends

The RFC provides explicit recommendations for both report generators (Mail Receivers) and report consumers (Domain Owners and their delegates):

The Full DMARC 2.0 Picture

To understand RFC 9991 in context, it helps to see how the three new RFCs divide the responsibilities previously held by RFC 7489:

RFC 7489 (March 2015) is officially obsolete. Any implementation, documentation, or tooling that references RFC 7489 as the current standard should now reference RFC 9989, RFC 9990, and RFC 9991 instead.

What This Means for Email Admins

For Domain Owners

• Your DMARC DNS record syntax has not changed. The tags, values, and overall format remain compatible. If your record was valid under RFC 7489, it remains valid under the new RFCs.
• Review your ruf= configuration with fresh eyes. RFC 9991 reinforces that failure reports carry significant privacy risk. If you have a ruf= address configured, ask whether you are actually receiving and acting on those reports. Many organizations set it and forget it.
• Apply redaction if you do use ruf. If you run your own reporting infrastructure or forward reports to a SIEM, consider stripping message bodies and redacting local-parts of email addresses as RFC 9991 suggests.
• Check your third-party reporting provider. If you use a SaaS DMARC service to receive ruf= reports, confirm how they handle PII under the new RFC guidance and whether their data processing agreements are still adequate.

For Mail Server Operators (Sending Reports)

• Rate limiting is now mandatory, not optional. Implement a maximum on outgoing failure reports per destination per time window. Aggregate similar failures before dispatching.
• Verify external destinations. Use the procedure from RFC 9990 Section 4 (substituting ruf for rua) before sending failure reports to domains outside the DMARC Policy Record's Organizational Domain.
• Ensure your report stream is DMARC-aligned. Failure report emails themselves should pass DMARC to avoid generating secondary failures and mail loops.
• Apply redaction at the source. Substitute hxxp for http in reported URIs, consider removing attachments, and redact local-parts of email addresses before sending reports.
• Ignore ruf tags on PSD records. If a DMARC Policy Record contains psd=y, do not send failure reports to its ruf= address unless you have a specific agreement with that PSD operator.

Should You Keep ruf= in Your DMARC Record?

RFC 9991 does not deprecate or discourage ruf= failure reporting — it standardizes it. But the RFC's own privacy guidance and the widespread industry practice of disabling ruf generation (Google and Microsoft both do not send failure reports) means the practical value of configuring ruf= has diminished for most domains.

Here is a decision framework based on RFC 9991 guidance:

Key Takeaways

• RFC 9991 (May 2026) is the new DMARC Failure Reporting standard. Together with RFC 9989 and RFC 9990, it officially obsoletes RFC 7489.
• The new Identity-Alignment ARF field is now a required part of all DMARC failure reports, providing a standardized machine-readable indicator of which authentication mechanisms failed alignment.
• Rate limiting on failure report generation is now mandatory, not a recommendation. This closes a real denial-of-service attack vector.
• External destination verification for ruf= is now explicitly required, using the same procedure as aggregate report verification.
• The RFC confirms what the industry already practices: large providers like Google and Microsoft do not generate failure reports, and aggregate reports remain the recommended mechanism for ongoing DMARC monitoring.
• Your existing DMARC DNS record syntax is unchanged — no DNS updates are required as a result of this RFC update.