---
title: "Abuse Reporting Format (ARF) for Email (RFC 5965) [2026]"
description: "ARF (Abuse Reporting Format, RFC 5965) is the format behind DMARC failure reports and feedback-loop complaints — and how to read one."
protocol: "ARF"
category: "Brand & Reporting"
rfc: "RFC 5965"
faq:
  - question: "What are DMARC failure (forensic) reports?"
    answer: "DMARC failure reports — historically called forensic or ruf reports — are per-message notifications a receiver sends when an email fails DMARC authentication. They use the Abuse Reporting Format (ARF, RFC 5965), while the DMARC reporting mechanism itself is defined by RFC 9991. Each report carries authentication results, the sender IP, and often message headers."
  - question: "What changed for ARF in RFC 9991?"
    answer: "RFC 9991 (May 2026) replaced the failure-reporting parts of the old DMARC RFC 7489 and updated the ARF/AFRF format from RFC 6591. It added new report fields — most notably Identity-Alignment — and made external ruf-destination verification mandatory. The ARF wire format itself is still RFC 5965."
  - question: "Who sends DMARC failure reports?"
    answer: "Email receivers like Gmail, Yahoo, and Microsoft can send DMARC failure reports if you publish a ruf tag, but most do not. Many large providers disable them or heavily redact them for privacy reasons (RFC 9991 §7). Failure reports are far less common than aggregate (rua) reports."
  - question: "What is the eXtended Abuse Reporting Format (XARF)?"
    answer: "XARF is a proprietary extension to ARF developed by Abusix. It adds a machine-readable JSON payload for easier automation. ARF is the IETF standard used globally; XARF is mostly limited to specific vendors and abuse networks. DMARC reporting always uses standard ARF, not XARF."
  - question: "What is an abuse email address?"
    answer: "An abuse email address (typically abuse@yourdomain.com) is a designated contact for abuse complaints and reports, often listed in WHOIS and DNS records. When ISPs or feedback-loop programs generate ARF reports, they send them to this address or to the address in your DMARC ruf tag."
  - question: "What is the difference between RUA and RUF in DMARC?"
    answer: "RUA (aggregate) reports are XML files sent daily that summarize all DMARC results for your domain. RUF (failure) reports use the ARF format and are sent per message when authentication fails. RUA is anonymized and widely supported; RUF is detailed but rarely sent due to privacy. Rely on RUA as your primary source."
---
<TLDR>
  ARF (Abuse Reporting Format, RFC 5965) is the format behind DMARC failure
  reports — the per-message notifications a receiver sends when a message fails
  DMARC, requested with the `ruf` tag. RFC 9991 (May 2026) updated the format,
  adding fields including Identity-Alignment and tightening verification of
  external report destinations. Most large providers send few failure reports or
  redact them heavily for privacy. Inspect one with the [ARF report
  checker](/tools/arf-checker/).
</TLDR>

ARF (Abuse Reporting Format) is the standardized structure for email abuse
reports. When mailbox providers detect spam, phishing, authentication failures,
or other abuse, they use ARF to send structured reports that machines can
process automatically. Understanding ARF matters if you work with DMARC failure
reports, ISP feedback loops, or any abuse-complaint system.

ARF is the _format_ (defined in RFC 5965). When DMARC uses that format for
per-message failure reports, the reporting _mechanism_ is now defined by RFC
9991 (May 2026), which replaced the reporting sections of the original DMARC
standard, [RFC 7489](/blog/dmarc-rfc-9989-9990-9991/). This guide explains what
ARF is, how it works, why [DMARC](/learn/dmarc/) uses it, what RFC 9991 changed,
and how to read the reports you receive.

<KeyStat
  stat="RFC 5965"
  label="defines the ARF wire format; RFC 9991 (May 2026) governs the DMARC failure reports that use it"
  source="IETF — RFC 5965 & RFC 9991"
  sourceHref="https://www.rfc-editor.org/rfc/rfc5965.html"
/>

## What Is ARF (Abuse Reporting Format)?

ARF is a machine-readable format for reporting email abuse, defined in RFC 5965.
It provides a consistent structure so receiving mail servers, ISPs, and mailbox
providers can communicate abuse events to domain owners and senders in a way
automated systems can parse and act on.

Before ARF, abuse reports were plain-text emails with inconsistent formats,
which made automated processing nearly impossible. ARF solves this with a
three-part MIME structure that carries human-readable context, machine-readable
fields, and the original offending message.

ARF is used in several scenarios:

- **DMARC failure reports**: When an email fails DMARC authentication, a receiver
  can send an ARF report to the domain owner.
- **Feedback loops**: ISPs like Yahoo and Microsoft send ARF reports when users
  mark messages as spam.
- **Abuse complaints**: Abuse desks often send manual reports in ARF format.
- **Phishing and fraud reports**: Security teams use ARF to report phishing
  attempts.

The format is extensible: new feedback types and fields can be added while
keeping backward compatibility. (Note that "ARF" here means the email Abuse
Reporting Format — not the unrelated medical or aviation acronyms.)

## How ARF Works: The Three-Part Report Structure

Every ARF report is a MIME multipart message containing exactly three parts. RFC
5965 §3.1 fixes their order, and understanding the structure is essential for
parsing reports correctly.

### Part 1: Human-Readable Summary

The first part is `text/plain` and explains the abuse event for a human reviewer.
It typically includes a description of the issue, remediation guidance, and
contact details for the reporting organization. This part is optional but nearly
always present.

### Part 2: Machine-Readable Report (`message/feedback-report`)

The second part is the core of ARF. It carries structured key-value fields using
the `message/feedback-report` content type, including:

- `Feedback-Type`: The category of abuse (`auth-failure`, `abuse`, `fraud`, and
  others)
- `User-Agent`: The software that generated the report
- `Version`: The ARF format version (`1` for RFC 5965)
- `Original-Mail-From`: The envelope sender of the original message
- `Arrival-Date`: When the message was received
- `Source-IP`: The IP address that sent the message
- `Auth-Failure`: (for DMARC reports) which authentication outcome triggered the
  report

These fields let automated systems extract the sender IP, identify the type of
abuse, and determine which authentication checks failed.

### Part 3: The Original Message (`message/rfc822` or `text/rfc822-headers`)

The third part carries either the full original message or only its headers. For
privacy, many receivers include headers only and redact personally identifiable
information (PII) before sending.

This three-part structure makes ARF both human-friendly and machine-parsable,
which is why it became the standard for abuse reporting.

## ARF Feedback Types

The `Feedback-Type` field identifies the category of abuse being reported. RFC
5965 defines five core types:

| Feedback Type  | Meaning                                   | Typical Use Case                             |
| -------------- | ----------------------------------------- | -------------------------------------------- |
| `abuse`        | Spam or unwanted email                    | ISP feedback loops, user spam complaints     |
| `auth-failure` | Authentication failure (SPF, DKIM, DMARC) | [DMARC](/learn/dmarc/) failure reports       |
| `fraud`        | Phishing, spoofing, or fraud attempt      | Security teams reporting phishing campaigns  |
| `virus`        | Message contained malware                 | Anti-virus systems reporting infected emails |
| `other`        | Doesn't fit the above categories          | Miscellaneous abuse reports                  |

For DMARC failure reports, the feedback type is always `auth-failure`. This
signals an authentication failure rather than a spam complaint or phishing
report. Additional types can be registered with IANA, and some vendors define
their own (such as `not-spam` for false positives).

## ARF and DMARC: Failure Reports Explained

When you publish a DMARC record with a `ruf=` tag, you ask email receivers to
send reports about messages that fail DMARC authentication. RFC 9991 calls these
**failure reports** (or "failed message reports"); you will also see the older
term **forensic reports**, which came from RFC 7489. The two names describe the
same thing — per-message reports in ARF format with `Feedback-Type: auth-failure`.

Per RFC 9991 §2, a receiver normally generates a failure report almost
immediately after detecting a DMARC failure, rather than waiting for the daily
aggregate report. A DMARC failure report includes:

- **Authentication results**: The `Authentication-Results` header showing SPF,
  DKIM, and DMARC verdicts
- **Failure details**: Which mechanism failed to authenticate an aligned
  identifier
- **Sender information**: Source IP, envelope sender, and sometimes reverse DNS
- **Message headers**: Headers from the original message (the body is often
  redacted)

The destinations and conditions for these reports come from the `ruf` and `fo`
tags, now defined in RFC 9989 §4.7. Two RFC 9991 rules matter for report
generators: they MUST rate-limit outgoing reports to avoid flooding a recipient,
and they MUST NOT honor a `ruf` tag on a Public Suffix Domain record (`psd=y`)
without a prior agreement.

## What RFC 9991 Added: New ARF Fields for DMARC

RFC 9991 §4 augments the ARF/AFRF format (RFC 6591) with extra fields so a DMARC
failure report describes _alignment_, not just a raw SPF or DKIM result. This is
the practical difference between the old reports and the current standard:

| Field                                           | Requirement                        | What it tells you                                                                                                        |
| ----------------------------------------------- | ---------------------------------- | ------------------------------------------------------------------------------------------------------------------------ |
| `Identity-Alignment`                            | REQUIRED                           | Which mechanisms failed to authenticate an _aligned_ identity (`dkim`, `spf`), or `none` if an aligned identifier passed |
| `Auth-Failure: dmarc`                           | Defined by §4                      | The report exists because no mechanism produced an aligned identifier                                                    |
| `DKIM-Domain`, `DKIM-Identity`, `DKIM-Selector` | REQUIRED for aligned DKIM failures | The exact DKIM identity that failed                                                                                      |
| `SPF-DNS`                                       | REQUIRED for aligned SPF failures  | The SPF record the receiver evaluated                                                                                    |
| `Delivery-Result`                               | OPTIONAL                           | What ultimately happened to the message                                                                                  |
| `DKIM-Canonicalized-Header` / `-Body`           | OPTIONAL                           | Canonicalized content for deep DKIM debugging                                                                            |

The headline addition is `Identity-Alignment`. DMARC only passes when an
authenticated identifier _aligns_ with the `From:` domain, so "SPF passed" is not
the same as "SPF passed for the right domain." `Identity-Alignment` states which
aligned identifiers failed, which is exactly the signal you need to separate a
real configuration gap from outright spoofing. The new `Auth-Failure: dmarc`
type marks a report generated because no aligned identifier authenticated, and a
receiver MAY still send separate per-mechanism reports alongside it.

## RUA vs RUF: Aggregate vs Failure Reports

DMARC defines two report types: aggregate (`rua`) and failure (`ruf`).
Understanding the difference is critical.

### Aggregate Reports (RUA)

- **Format**: XML
- **Frequency**: Sent daily (or at the receiver's interval)
- **Content**: Summary statistics of all DMARC evaluations (pass/fail counts,
  source IPs, authentication results)
- **Privacy**: Anonymized — no message content, no recipient addresses
- **Adoption**: Widely supported by all major providers
- **Use case**: Trend analysis, finding unauthorized senders, monitoring
  alignment

### Failure Reports (RUF)

- **Format**: ARF (RFC 5965 + RFC 6591 AFRF, as updated by RFC 9991 §4)
- **Frequency**: Per-message (sent soon after a failure occurs)
- **Content**: Details about a single failed message (headers, authentication
  results, sometimes body)
- **Privacy**: Contains PII — heavily restricted or redacted
- **Adoption**: Rarely sent by major providers

**Recommendation**: Always configure `rua=` in your DMARC record. Add `ruf=` if
you want failure reports, but don't expect many. Aggregate reports are your
single source of truth — use a
[DMARC report analyzer](/tools/dmarc-report-analyzer/) to parse and visualize them
at scale.

## Reading an ARF Report: Field-by-Field Example

Here's an annotated DMARC failure report for an unauthorized sender spoofing your
domain — SPF fails and the message carries no DKIM signature, so no aligned
identifier authenticates and DMARC fails. For a second worked sample, see this
[annotated real-world ARF report example](/blog/what-is-arf/).

```
From: noreply@example-receiver.com
To: forensic@yourdomain.com
Subject: FW: Failure report for yourdomain.com
Content-Type: multipart/report; report-type=feedback-report;
    boundary="----=_Part_12345"

------=_Part_12345
Content-Type: text/plain

This is a DMARC failure report for a message that used your domain in the
From: address. The message failed DMARC because no aligned identifier
authenticated: SPF failed and the message carried no DKIM signature.

------=_Part_12345
Content-Type: message/feedback-report

Feedback-Type: auth-failure
Version: 1
User-Agent: Example-Receiver/1.0
Auth-Failure: dmarc
Identity-Alignment: spf
Authentication-Results: example-receiver.com;
    dmarc=fail (p=quarantine dis=none) header.from=yourdomain.com;
    spf=fail smtp.mailfrom=yourdomain.com;
    dkim=none
Original-Mail-From: sender@yourdomain.com
Arrival-Date: Fri, 28 Feb 2026 14:35:22 +0000
Source-IP: 203.0.113.45
Reported-Domain: yourdomain.com
SPF-DNS: txt; yourdomain.com; "v=spf1 include:_spf.google.com -all"

------=_Part_12345
Content-Type: message/rfc822

From: sender@yourdomain.com
To: recipient@example-receiver.com
Subject: Important update
Date: Fri, 28 Feb 2026 14:35:10 +0000
Authentication-Results: example-receiver.com;
    dmarc=fail (p=quarantine dis=none) header.from=yourdomain.com;
    spf=fail smtp.mailfrom=yourdomain.com;
    dkim=none

[Message headers continue...]

------=_Part_12345--
```

### Key Fields Explained

- **`Feedback-Type: auth-failure`**: This is a DMARC failure report.
- **`Auth-Failure: dmarc`**: The RFC 9991 §4 type — DMARC failed because no
  aligned identifier authenticated.
- **`Identity-Alignment: spf`**: RFC 9991 §4 (REQUIRED). The aligned mechanisms
  that failed; here SPF failed and DKIM was absent. A value of `none` would mean
  an aligned identifier _did_ authenticate.
- **`SPF-DNS`**: The SPF record the receiver evaluated (RFC 9991 §4, REQUIRED for
  aligned SPF failures) — useful for confirming the policy in effect.
- **`Source-IP: 203.0.113.45`**: The sending IP. Investigate whether it's an
  authorized sender or an impersonator.
- **`Original-Mail-From` / `Reported-Domain`**: The envelope sender and your
  domain.

In this example, an unauthorized host sent mail using your domain in the `From:`
address. SPF failed for `yourdomain.com` and there was no DKIM signature, so
DMARC failed — a classic direct-domain spoofing attempt. If `Identity-Alignment`
had reported `none`, the message would have authenticated and no report would
exist.

## Verifying External ruf Destinations

You can point `ruf=` at a mailbox outside your Organizational Domain — a sister
domain, or a third-party report processor. RFC 9991 §5 calls these "external
destinations" and requires that a receiver verify them before sending any
failure reports.

The verification reuses the External Destination Verification procedure from RFC
9990 §4, substituting the `ruf` tag where that procedure references `rua`. In
practice, the destination domain must publish a DNS TXT authorization record (of
the form `<your-domain>._report._dmarc.<destination-domain>`) that consents to
receive your reports. Without it, a conforming receiver won't deliver to the
external address. You can
[verify your ruf= destination with the ARF checker](/tools/arf-checker/) before
relying on it.

This requirement prevents two abuses. It stops a bad actor from pointing `ruf` at
a victim's mailbox and then deliberately generating failure reports to flood it,
and it stops a domain owner from forcing unwanted, potentially sensitive mail
onto a third party that never agreed to receive it. RFC 9991 §5.1 adds that
report streams should themselves be DMARC-aligned and rate-limited, so failure
reports don't trigger more failure reports and cause mail loops.

## Email Feedback Loops and ARF

Feedback loops (FBLs) are programs run by ISPs that send ARF reports when users
mark email as spam. These reports use `Feedback-Type: abuse` rather than
`auth-failure`.

### How Feedback Loops Work

1. A user receives your email and clicks "Report Spam."
2. The ISP generates an ARF report describing the complaint.
3. The ISP sends the report to your registered abuse or feedback address.
4. You process the report and remove the complaining user from your list.

### Major Feedback Loop Programs

- **Yahoo**: Requires registration; sends ARF reports for complaint types.
- **Microsoft (Outlook.com)**: JMRP (Junk Mail Reporting Program) and SNDS.
- **AOL**: Sends ARF reports via its feedback-loop registration.
- **Cloudflare**: Sends ARF reports for domains using Cloudflare Email Routing.

Gmail does not operate a traditional sender-facing feedback loop. It uses
complaint data internally to adjust filtering and sender reputation.

### Why Feedback Loops Matter

High complaint rates damage your sender reputation. ISPs use complaint rates to
decide whether your future messages reach the inbox or the junk folder.
Processing FBL reports and removing complainers is essential for maintaining good
[email deliverability](/blog/email-deliverability-monitoring/).

## AFRF: Authentication Failure Reporting (RFC 6591)

AFRF extends ARF specifically for authentication-failure reporting. It's defined
in RFC 6591 and adds fields relevant to SPF, DKIM, and DMARC failures — and RFC
9991 §4 is the update that brings AFRF in line with current DMARC.

AFRF introduces the `Auth-Failure` field, which records the authentication
outcome:

- `dkim` — DKIM signature verification failed
- `spf` — SPF check failed
- `dmarc` — no aligned identifier authenticated (the RFC 9991 type)
- `adsp` — DKIM Author Domain Signing Practices failed (now obsolete)

The [`Authentication-Results` header](/tools/email-header-analyzer/) (RFC 8601)
is often included and provides additional detail:

```
Authentication-Results: receiver.com;
    spf=fail smtp.mailfrom=example.com smtp.helo=mail.example.com;
    dkim=pass (1024-bit key) header.d=example.com header.i=@example.com;
    dmarc=fail (p=quarantine sp=quarantine) header.from=example.com
```

This header shows exactly what passed and what failed, making it easier to
diagnose issues.

## ARF vs XARF: What Changed

XARF (eXtended Abuse Reporting Format) is a proprietary extension to ARF
developed by Abusix. ARF is an IETF standard; XARF is vendor-specific and not
part of the official RFC series.

| Feature        | ARF (RFC 5965)                      | XARF                       |
| -------------- | ----------------------------------- | -------------------------- |
| **Format**     | `message/feedback-report` (plain)   | Adds JSON payload          |
| **Adoption**   | Universal (IETF standard)           | Limited (Abusix ecosystem) |
| **Use case**   | DMARC, FBLs, abuse reporting        | Abuse networks, spam traps |
| **Processing** | Requires ARF parser                 | Easier JSON parsing        |
| **DMARC**      | Standard format for failure reports | Not used for DMARC         |

XARF's advantage is a JSON-encoded report alongside the standard ARF structure,
which is easier to parse with modern tools. But because XARF is not an IETF
standard, major providers don't use it for DMARC reporting. For DMARC failure
reports, you'll only encounter standard ARF as defined in RFC 5965 and extended
by RFC 6591 (AFRF).

## Why You Might Not Receive Failure Reports

Even with a properly configured `ruf=` tag, you may not receive failure reports.
RFC 9991 §7 is explicit that the privacy trade-offs lead many operators to limit
or disable them. Here's why reports go missing:

### 1. Receivers Don't Send Them

Major providers like Gmail and Yahoo generally don't send DMARC failure reports.
Privacy regulations (GDPR, CCPA) and the risk of exposing user data make failure
reporting legally and operationally risky.

### 2. Privacy and Redaction

Providers that do send reports often redact message bodies and recipient
addresses (RFC 6590). Some redact so heavily that the reports lose most of their
diagnostic value.

### 3. Verification Requirements

External `ruf` destinations must be authorized via the RFC 9991 §5 procedure
above. If that DNS authorization record is missing, conforming receivers won't
deliver reports.

### 4. Rate-Limiting and Volume

RFC 9991 requires report generators to rate-limit. High-volume domains can have
reports throttled or dropped to avoid overwhelming a mailbox.

### 5. No Failures Are Occurring

If all your email passes DMARC, there's nothing to report. Check your aggregate
reports to confirm whether failures are actually happening.

### 6. Failure Reporting Options (`fo` Tag)

The DMARC `fo` tag controls when reports are generated:

- `fo=0` (default): Report only if both SPF and DKIM fail
- `fo=1`: Report if either SPF or DKIM fails
- `fo=d`: Report if DKIM fails
- `fo=s`: Report if SPF fails

With `fo=0`, a message where one mechanism still passes won't generate a report
even if alignment is imperfect. Most domains that want diagnostics set `fo=1`.

## Setting Up ARF Reporting for Your Domain

To receive ARF reports (both DMARC failure reports and ISP feedback loops),
follow these steps:

### 1. Add the `ruf` Tag to Your DMARC Record

Include a `ruf=` tag with the address where you want failure reports, and set
`fo=1` for broader visibility:

```
_dmarc.yourdomain.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:forensic@yourdomain.com; fo=1"
```

### 2. Set Up a Dedicated Address

Don't use a personal inbox. Create a dedicated address like
`forensic@yourdomain.com` and automate processing where possible.

### 3. Authorize External Destinations

If your `ruf` address is on a different domain, publish the RFC 9991 §5
authorization record on the destination domain — otherwise conforming receivers
won't send reports there.

### 4. Register for ISP Feedback Loops

To receive spam-complaint reports, register with major ISPs:

- **Yahoo**: [senders.yahooinc.com](https://senders.yahooinc.com/)
- **Microsoft**: JMRP and SNDS via
  [postmaster.live.com](https://postmaster.live.com/)
- **AOL**: Registration via AOL's postmaster portal

### 5. Process Reports Automatically

ARF reports are machine-readable, so parse them automatically rather than reading
them by hand. DMARCguard processes ARF reports for you — extracting
authentication results, source IPs, and failure reasons — and you can use our
[ARF report analyzer](/tools/arf-report-analyzer/) to inspect individual reports
and spot patterns without manual work.

## Frequently Asked Questions

### What are DMARC failure (forensic) reports?

DMARC failure reports — historically called forensic or ruf reports — are
per-message notifications a receiver sends when an email fails DMARC
authentication. They use the Abuse Reporting Format (ARF, RFC 5965), while the
DMARC reporting mechanism itself is defined by RFC 9991. Each report carries
authentication results, the sender IP, and often message headers.

### What changed for ARF in RFC 9991?

RFC 9991 (May 2026) replaced the failure-reporting parts of the old DMARC RFC
7489 and updated the ARF/AFRF format from RFC 6591. It added new report fields —
most notably `Identity-Alignment` — and made external `ruf`-destination
verification mandatory. The ARF wire format itself is still RFC 5965.

### Who sends DMARC failure reports?

Email receivers like Gmail, Yahoo, and Microsoft can send DMARC failure reports
if you publish a `ruf` tag, but most do not. Many large providers disable them or
heavily redact them for privacy reasons (RFC 9991 §7). Failure reports are far
less common than aggregate (`rua`) reports.

### What is the eXtended Abuse Reporting Format (XARF)?

XARF is a proprietary extension to ARF developed by Abusix. It adds a
machine-readable JSON payload for easier automation. ARF is the IETF standard
used globally; XARF is mostly limited to specific vendors and abuse networks.
DMARC reporting always uses standard ARF, not XARF.

### What is an abuse email address?

An abuse email address (typically `abuse@yourdomain.com`) is a designated contact
for abuse complaints and reports, often listed in WHOIS and DNS records. When
ISPs or feedback-loop programs generate ARF reports, they send them to this
address or to the address in your DMARC `ruf` tag. You can see what a domain
currently publishes with the [WHOIS lookup](/tools/whois-lookup/).

### What is the difference between RUA and RUF in DMARC?

RUA (aggregate) reports are XML files sent daily that summarize all DMARC results
for your domain. RUF (failure) reports use the ARF format and are sent per
message when authentication fails. RUA is anonymized and widely supported; RUF is
detailed but rarely sent due to privacy. Rely on RUA as your primary source.

## Related Protocols

- [DMARC](/learn/dmarc/) — Defines the `ruf` tag and the failure-reporting
  mechanism (RFC 9991)
- [TLS-RPT](/learn/tls-rpt/) — A different reporting format (JSON) for
  transport-encryption issues, not authentication failures
- [SPF](/learn/spf/) — SPF failures trigger ARF reports when DMARC failure
  reporting is enabled
- [DKIM](/learn/dkim/) — DKIM failures trigger ARF reports in DMARC failure
  reporting

Not sure which DMARC tool handles failure reports best?
[Compare DMARC monitoring platforms](/compare/) to see how DMARCguard stacks up.