What Is ARF? Abuse Reporting Format (RFC 5965) [2026]

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. This guide explains what ARF is, how it works, why DMARC uses it, what RFC 9991 changed, and how to read the reports you receive.

Key finding

RFC 5965 defines the ARF wire format; RFC 9991 (May 2026) governs the DMARC failure reports that use it

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:

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:

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 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.

From: [email protected]
To: [email protected]
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: [email protected]
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: [email protected]
To: [email protected]
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.

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.

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 (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 [email protected];
    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.

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:[email protected]; ruf=mailto:[email protected]; fo=1"

2. Set Up a Dedicated Address

Don’t use a personal inbox. Create a dedicated address like [email protected] 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
• Microsoft: JMRP and SNDS via 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 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 [email protected]) 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.

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 — Defines the ruf tag and the failure-reporting mechanism (RFC 9991)
• TLS-RPT — A different reporting format (JSON) for transport-encryption issues, not authentication failures
• SPF — SPF failures trigger ARF reports when DMARC failure reporting is enabled
• DKIM — DKIM failures trigger ARF reports in DMARC failure reporting

Not sure which DMARC tool handles failure reports best? Compare DMARC monitoring platforms to see how DMARCguard stacks up.