ARF Abuse Report Format Guide [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 can be processed automatically. Understanding ARF is critical if you work with DMARC forensic reports, ISP feedback loops, or any abuse complaint system.

This guide explains what ARF is, how it works, why DMARC uses it for forensic reports, and how to interpret the reports you receive.

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 that receiving mail servers, ISPs, and mailbox providers can communicate abuse events to domain owners and senders in a way that automated systems can parse and act upon.

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

ARF is used in several scenarios:

• DMARC forensic reports: When an email fails DMARC authentication, receivers can send an ARF report to the domain owner
• Feedback loops: ISPs like Yahoo, Microsoft, and others send ARF reports when users mark emails as spam
• Abuse complaints: Manual reports from abuse desks often use ARF format
• Phishing and fraud reports: Security teams use ARF to report phishing attempts

The format is extensible, meaning new feedback types and fields can be added while maintaining backward compatibility.

How ARF Works: The Three-Part Report Structure

Every ARF report is a MIME multipart message containing exactly three parts. Understanding this structure is essential for parsing reports correctly.

Part 1: Human-Readable Summary

The first part is text/plain and provides a human-readable explanation of the abuse event. This section is designed for manual review and typically includes:

• A description of the issue (e.g., “The attached message was identified as spam”)
• Instructions for remediation
• Contact information for the reporting organization

This part is optional but nearly always included. It helps human reviewers quickly understand what happened without parsing structured data.

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

The second part is the core of ARF. It contains structured key-value pairs that describe the abuse event. This section uses the message/feedback-report content type and includes fields like:

• Feedback-Type: The category of abuse (e.g., auth-failure, abuse, fraud)
• User-Agent: The software that generated the report
• Version: The ARF format version (always 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) What authentication mechanism failed

These fields allow automated systems to 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 contains either the full original message or just its headers. This allows the domain owner to see exactly what was sent and investigate the issue.

For privacy reasons, many receivers include only headers and omit the message body. Some providers redact personally identifiable information (PII) like recipient addresses before including the message.

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 forensic reports, the feedback type is always auth-failure. This signals that the report is about an authentication failure rather than a spam complaint or phishing attempt.

Additional feedback types can be registered with IANA, and some vendors define their own types (e.g., not-spam for false positives).

ARF and DMARC: Forensic Reports Explained

When you publish a DMARC record with a ruf= tag, you’re asking email receivers to send forensic reports about messages that fail DMARC authentication. These forensic reports use ARF format with Feedback-Type: auth-failure.

Here’s what a DMARC forensic report includes:

• Authentication results: The Authentication-Results header showing SPF, DKIM, and DMARC verdicts
• Failure details: The Auth-Failure field specifying whether SPF, DKIM, or both failed
• Sender information: Source IP address, envelope sender, and sometimes reverse DNS
• Message headers: Headers from the original message (body is often redacted)
• Timestamp: When the receiver processed the message

The Auth-Failure field is specific to authentication failures and includes values like:

• dkim — DKIM signature verification failed
• spf — SPF check failed
• dmarc — DMARC policy evaluation failed

Some receivers also include dkim+spf if both mechanisms failed.

Why Forensic Reports Are Rare

While forensic reports sound valuable, they have significant limitations:

1. Privacy concerns: Forensic reports include message content, which may contain PII. Regulations like GDPR discourage sharing user data.
2. Low adoption: Major providers like Gmail and Yahoo do not send forensic reports.
3. High volume: For domains with millions of messages, forensic reports would generate unsustainable email volume.
4. Limited value: Aggregate reports provide better insights for most use cases.

Because of these issues, you should treat forensic reports as supplementary data. Never rely on them as your primary DMARC monitoring mechanism.

RUA vs RUF: Aggregate vs Forensic Reports

DMARC defines two types of reports: aggregate (rua) and forensic (ruf). Understanding the difference is critical.

Aggregate Reports (RUA)

• Format: XML
• Frequency: Sent daily (or at intervals defined by the receiver)
• 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 email providers
• Use case: Long-term trend analysis, identifying unauthorized senders, monitoring DMARC alignment

Forensic Reports (RUF)

• Format: ARF (RFC 5965)
• Frequency: Per-message (sent immediately when 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
• Use case: Investigating specific authentication failures, debugging SPF/DKIM issues

Recommendation: Always configure rua= in your DMARC record. Configure ruf= if you want forensic reports, but don’t expect to receive 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 example of an ARF forensic report for a DMARC authentication failure.

From: [email protected]
To: [email protected]
Subject: FW: Abuse report for yourdomain.com
Content-Type: multipart/report; report-type=feedback-report;
    boundary="----=_Part_12345"

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

This is an authentication failure report for an email claiming to be from
your domain. The message failed DMARC authentication due to SPF failure.

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

Feedback-Type: auth-failure
Version: 1
User-Agent: Example-Receiver/1.0
Auth-Failure: spf
Authentication-Results: example-receiver.com;
    dmarc=fail (p=quarantine dis=none) header.from=yourdomain.com;
    spf=fail smtp.mailfrom=yourdomain.com;
    dkim=pass header.d=yourdomain.com
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

------=_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=pass header.d=yourdomain.com

[Message headers continue...]

------=_Part_12345--

Key Fields Explained

• Feedback-Type: auth-failure: This is a DMARC forensic report
• Auth-Failure: spf: SPF check failed (SPF alignment issue)
• Authentication-Results: Shows DKIM passed but SPF failed, causing DMARC to fail
• Source-IP: 203.0.113.45: The IP that sent the message — investigate whether this is an authorized sender
• Original-Mail-From: The envelope sender (MAIL FROM command)
• Reported-Domain: Your domain

In this example, the failure is due to SPF. You’d investigate whether 203.0.113.45 is a legitimate sending IP and whether it’s included in your SPF record. The fact that DKIM passed suggests the message might be legitimate but sent from an IP not listed in SPF.

Email Feedback Loops and ARF

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

How Feedback Loops Work

1. A user receives your email and clicks “Report Spam” or “This is Junk”
2. The ISP generates an ARF report with the complaint details
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 mailing list

Major Feedback Loop Programs

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

Gmail does not operate a traditional feedback loop accessible to senders. Instead, they use 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 determine whether you’re a spammer. If too many users mark your emails as spam, your future messages are more likely to land in the junk folder or be blocked entirely.

Processing FBL reports and removing complainers from your lists is essential for maintaining good 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.

AFRF introduces the Auth-Failure field, which specifies what authentication mechanism failed:

• dkim — DKIM signature verification failed
• spf — SPF check failed
• adsp — DKIM Author Domain Signing Practices failed (now obsolete)

AFRF is used by DMARC forensic reports (ruf) to indicate whether SPF or DKIM (or both) caused the DMARC failure. Without AFRF, you’d have to parse the Authentication-Results header manually to determine what failed.

The Authentication-Results header (RFC 7001) is often included in AFRF reports 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 pct=100) 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. While ARF is an IETF standard, XARF is vendor-specific and not part of the official RFC series.

Key Differences

XARF’s main advantage is that it includes a JSON-encoded report in addition to the standard ARF structure. This makes it easier to parse with modern tools. However, because XARF is not an IETF standard, it’s not used by major email providers for DMARC reporting.

For DMARC forensic reports, you’ll only encounter standard ARF format as defined in RFC 5965 and extended by RFC 6591 (AFRF).

Why You Might Not Receive Forensic Reports

Even with a properly configured ruf= tag in your DMARC record, you may not receive forensic reports. Here’s why:

1. Receivers Don’t Send Them

Major providers like Gmail, Yahoo, and many others do not send DMARC forensic reports. Privacy regulations (GDPR, CCPA) and the risk of exposing user data make forensic reporting legally and operationally risky.

2. Privacy and Redaction

Even providers that send forensic reports often redact message bodies and recipient addresses. Some redact so heavily that the reports lose most of their diagnostic value.

3. Verification Requirements

Some receivers require that your ruf address be verified before they’ll send reports. This usually involves responding to a confirmation email or publishing a DNS TXT record authorizing the address.

4. High Volume Concerns

If your domain receives millions of emails daily, forensic reports could generate millions of abuse reports. Receivers may throttle or disable forensic reporting to avoid overwhelming your mailbox.

5. No Failures Are Occurring

If all your email passes DMARC authentication, there are no failures to report. Check your aggregate reports to confirm whether failures are occurring.

6. Forensic Reporting Options (fo Tag)

The DMARC fo tag controls when forensic reports are generated:

• fo=0 (default): Generate reports if both SPF and DKIM fail
• fo=1: Generate reports if either SPF or DKIM fails
• fo=d: Generate reports if DKIM fails (regardless of SPF)
• fo=s: Generate reports if SPF fails (regardless of DKIM)

If you’re using fo=0 and only one mechanism fails (while the other passes), you won’t receive forensic reports even though DMARC may still pass.

Setting Up ARF Reporting for Your Domain

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

1. Add the ruf Tag to Your DMARC Record

Include a ruf= tag in your DMARC TXT record with the email address where you want to receive forensic reports.

_dmarc.yourdomain.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1"

The fo=1 option requests reports if either SPF or DKIM fails, giving you more visibility into authentication issues.

2. Set Up a Dedicated Email Address

Don’t use your personal inbox for ARF reports. Create a dedicated address like [email protected] or [email protected] and configure automated processing if possible.

3. Verify Your RUF Address (If Required)

Some receivers send a verification email before they’ll send forensic reports. Monitor your ruf address for these verification requests and respond promptly.

4. Register for ISP Feedback Loops

To receive spam complaint reports, register for feedback loops with major ISPs:

• Yahoo: https://senders.yahooinc.com/
• Microsoft: JMRP and SNDS via postmaster.live.com
• AOL: Registration via AOL’s postmaster portal

Each program has its own registration process and requirements. You’ll typically need to verify domain ownership and provide contact details.

5. Process Reports Automatically

ARF reports are machine-readable, so you should parse them automatically rather than reading them manually. Tools and libraries are available in most languages for parsing ARF format.

DMARCguard processes ARF reports automatically, extracting authentication results, source IPs, and failure reasons. You can also use our ARF report analyzer to inspect individual reports and identify patterns (e.g., a specific IP range always failing SPF) without manual analysis.

Frequently Asked Questions

What are DMARC forensic reports?

DMARC forensic reports (also called failure reports or ruf reports) are per-message notifications sent when an email fails DMARC authentication. They use ARF (Abuse Reporting Format) as defined in RFC 5965 and contain details about the failing message including authentication results, sender IP, and sometimes message headers.

Who sends DMARC forensic reports?

Email receivers like Gmail, Yahoo, and Microsoft can send DMARC forensic reports if you configure the ruf tag in your DMARC record. However, not all receivers send these reports. Many major providers either don’t send them at all or heavily redact them for privacy reasons. Forensic reports are far less common than aggregate reports.

What is an abuse email address?

An abuse email address (typically [email protected]) is a designated contact for receiving abuse complaints and reports. This address is often listed in WHOIS records and DNS records. When ARF reports are generated by ISPs or feedback loop programs, they’re typically sent to the domain’s abuse contact or the address specified in the ruf tag of a DMARC record.

What is the eXtended Abuse Reporting Format (XARF)?

XARF is a proprietary extension to the ARF format developed by Abusix. It adds machine-readable JSON payloads to ARF reports for easier automated processing. While ARF is an IETF standard used globally, XARF is primarily used by specific vendors and abuse networks. For DMARC forensic reports, the standard ARF format is always used.

Why am I not receiving DMARC forensic reports?

There are several reasons: (1) Many large receivers like Gmail don’t send forensic reports at all, (2) Your DMARC record might not include a ruf tag, (3) Privacy regulations prevent sharing message content, (4) Your ruf address might not be verified or reachable, or (5) There may be no authentication failures occurring. Aggregate reports (rua) are far more reliable and widely supported.

How do I read an ARF report?

An ARF report has three parts: (1) A human-readable text summary explaining the issue, (2) A machine-readable section with fields like Feedback-Type, Original-Mail-From, and Auth-Failure, and (3) The original message or its headers. Look for the Auth-Failure field to see what failed (DKIM, SPF, or both), check the Source-IP to identify the sender, and examine authentication results in the headers.

What is the difference between RUA and RUF in DMARC?

RUA (aggregate reports) are XML files sent daily summarizing all DMARC evaluation results for your domain. RUF (forensic reports) use ARF format and are sent per-message when authentication fails. RUA reports are anonymized, widely supported, and contain volume statistics. RUF reports include message-level details but are rarely sent due to privacy concerns. Always rely on RUA reports as your primary data source.

Related Protocols

• DMARC — Uses ARF for forensic (ruf) reports and defines the ruf tag for requesting them
• TLS-RPT — Different reporting format (JSON) for transport-level encryption issues, not authentication failures
• SPF — SPF failures trigger ARF reports when DMARC forensic reporting is enabled
• DKIM — DKIM signature failures trigger ARF reports in DMARC forensic reporting

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