What Is ARF? Abuse Reporting Format & DMARC Failure Reports (RFC 5965)

Key Takeaways

ARF (Abuse Reporting Format) is a standardized, machine-readable format for reporting email abuse, defined in RFC 5965. It’s the format behind DMARC failure reports and ISP feedback loops.
“Forensic report,” “failure report,” and “ARF report” all describe the same artifact. The terminology shifted with the new DMARC RFC set published in May 2026.
As of May 2026, DMARC itself is defined across three documents: RFC 9989 (core DMARC), RFC 9990 (aggregate/RUA reporting), and RFC 9991 (failure/RUF reporting). Together they obsolete the original RFC 7489. The ARF wire format underneath is still RFC 5965.
RFC 9991 adds a required Identity-Alignment field to failure reports, which tells you exactly which mechanism (SPF, DKIM, or both) failed to produce an aligned identifier.
Most mailbox providers, including Gmail and Yahoo, still don’t send failure reports at any real volume. Aggregate (RUA) reports remain the reliable data source for most domain owners.

What Is ARF (Abuse Reporting Format)?

ARF stands for Abuse Reporting Format. It is a standardized, machine-readable format for notifying senders that an email caused a problem. It was defined in RFC 5965 back in 2010, at a point when abuse reports were mostly inconsistent plain-text emails that mail admins had to read by hand. That worked fine when volume was low, but it fell apart the moment providers wanted to automate anything. ARF provided receivers, ISPs, and mailbox providers with a shared structure so that abuse events could be reported to domain owners and senders in a format that scripts and parsers could easily handle.

Today ARF shows up in four main places:

DMARC failure reports – when a message fails DMARC authentication, a receiver can send an ARF report describing exactly what went wrong.
ISP feedback loops – when a recipient clicks “this is spam,” some providers relay that complaint back to the sender in ARF format.
Abuse-desk complaints – manual reports of misuse routed through automated abuse-handling systems.
Phishing and fraud reports – reports flagging a message as fraudulent rather than merely unwanted.

Worth clearing up early: this ARF has nothing to do with any other acronym you might be thinking of. In the email world, ARF is always the Abuse Reporting Format.

How an ARF Report Is Structured (The Three Parts)

RFC 5965 defines ARF as a MIME multipart/report message, which just means it’s an email built out of three distinct pieces stacked together. Each piece serves a different reader: one is for a human, one is for a machine, and one is the evidence.

Part 1: Human-Readable Summary (text/plain)

The first part is a plain-text block meant for a person skimming their inbox. It usually gives a one- or two-line summary of what happened, so someone glancing at the report doesn’t need to parse the machine-readable fields just to understand the gist.

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

This is the core of the report and the part automated systems actually parse. It’s a block of key-value fields such as Feedback-Type, Version, User-Agent, Source-IP, and Arrival-Date, along with authentication-specific fields like Auth-Failure. This is where the diagnostic value of the report actually lives.

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

The final part carries either the full original message or just its headers, depending on how the sender configured things and how much detail the receiver is willing to share. Because message content can carry personal information, many receivers strip this down to headers only, or redact parts of it, before sending the report on.

ARF Feedback Types

The Feedback-Type field tells you what kind of report you’re looking at:

Feedback-Type	Meaning	Use case
abuse	Spam or unwanted mail complaint	ISP feedback loops
auth-failure	Authentication failure	DMARC failure reports
fraud	Phishing or fraud	Fraud/brand-abuse reporting
virus	Malware detected	Antivirus/security gateways
other	Anything not covered above	Miscellaneous, vendor-specific uses

For DMARC purposes, you’ll only ever see one value here: auth-failure. Additional feedback types can be registered with IANA if a new use case comes along, but the DMARC use case has stayed put with auth-failure since day one.

ARF, AFRF, RUF, Forensic Reports: Untangling the Terminology

If you’ve been reading about DMARC reporting and started seeing ARF, AFRF, RUF, and “forensic report” used almost interchangeably, you’re not imagining things. These terms genuinely overlap, and here’s how they actually relate:

ARF is the base wire format defined in RFC 5965. It’s generic and was never DMARC-specific.
AFRF (Authentication Failure Reporting Format) is the extension defined in RFC 6591 that adapted ARF specifically for reporting SPF, DKIM, and DMARC authentication failures.
RUF is the DMARC tag (ruf=) you put in your DNS record to request that per-message failure reports get sent somewhere.
Forensic report is the older name for this same artifact, carried over from the original DMARC specification, RFC 7489. The current RFC set calls it a “failure report” instead.

So when someone asks for a “forensic report example” and someone else calls it a “DMARC failure report,” they’re talking about the same thing. The naming shifted with the standard, not the underlying mechanism.

ARF and DMARC: Failure Reports Explained

When you add a ruf= tag to your DMARC DNS record, you’re asking receiving mail servers to send you a report any time a message claiming to be from your domain fails DMARC. Unlike aggregate reports, which batch up a day’s worth of traffic into one XML summary, failure reports are meant to be generated close to the time of the failure and cover a single message.

A DMARC failure report tells you things an aggregate report can’t: the authentication results for that specific message, details about exactly which mechanism failed, information about the sending source, and either the full message or its headers so you can trace where it actually came from. That level of detail is what makes failure reports useful for catching a spoofing attempt in near real time, assuming you actually receive one, which brings us to the next section.

What RFC 9991 Changed (2026 Update)

In May 2026, the IETF published a new set of DMARC documents that replace the original RFC 7489: RFC 9989 (core DMARC), RFC 9990 (aggregate/RUA reporting), and RFC 9991 (failure/RUF reporting). Together, they obsolete RFC 7489. Here’s what actually changed for failure reports:

The RFC lineage shifted: RFC 9991 now covers failure reporting and obsoletes the failure-reporting sections of RFC 7489. It also updates RFC 6591 (AFRF) with a more precise set of required fields.
The ARF wire format itself didn’t change: RFC 5965 is still the underlying base format.
A new required field: Identity-Alignment: A comma-separated list naming which mechanism, DKIM or SPF, failed to produce an aligned identifier, or “none” if an aligned identifier did authenticate. This is the most useful field for anyone reading a report, as it tells you directly whether you’re looking at a misconfiguration or outright spoofing,
A new Auth-Failure type: dmarc: Used specifically when no aligned identifier authenticated the message, as opposed to a generic SPF or DKIM failure.
New required fields for diagnosing alignment failures: DKIM-Domain, DKIM-Identity, and DKIM-Selector are required when an aligned DKIM signature failed. SPF-DNS is required when an aligned SPF check failed.
New optional fields for extra detail: Delivery-Result and the DKIM-Canonicalized-Header/Body pair, available when a receiver wants to include more diagnostic context.

Why Identity-Alignment matters so much

DMARC was never really checking whether SPF or DKIM passed in isolation, it’s checking whether an authenticated identifier lines up with the domain in the visible From: address. A message can have SPF and DKIM both technically pass and still fail DMARC if neither is aligned with the From: domain. This field spells that out directly.

RUA vs RUF: Aggregate vs Failure Reports

	RUA (Aggregate)	RUF (Failure)
Format	XML	ARF
Frequency	Typically daily	Near real-time, per message
Content	Summary counts by source IP and result	Full detail on one specific failing message
Privacy exposure	Low	High
Adoption among receivers	Broad	Limited
Defined in	RFC 9990	RFC 9991

Recommendation (same as before)

Always configure rua= in your DMARC record. Major mailbox providers widely support DMARC Aggregate reports and provide the day-to-day visibility you need to monitor authentication. Configuring ruf= is optional and can offer additional diagnostics, but many receivers don’t send forensic reports, so treat them as a supplementary data source.

How to Read an ARF Report (Field-by-Field Example)

Given below is an example of what a DMARC failure report might look like for a direct-domain spoof, where an attacker sends an email claiming to be from your domain with no valid SPF or DKIM behind it:

Feedback-Type: auth-failure
Version: 1
User-Agent: MailReceiver/2.1
Auth-Failure: dmarc
Identity-Alignment: dkim, spf
Original-Mail-From: <[email protected]>
Reported-Domain: yourdomain.com
Source-IP: 198.51.100.44
SPF-DNS: v=spf1 include:_spf.yourdomain.com ~all
Authentication-Results: mx.receiver.example;
    dmarc=fail (p=reject) header.from=yourdomain.com;
    spf=fail smtp.mailfrom=spoofed-source.net;
    dkim=none
Arrival-Date: Wed, 22 Jul 2026 09:14:02 +0000

Walking through the fields that matter most:

Feedback-Type: auth-failure confirms this is an authentication complaint, not a spam or abuse report.
Auth-Failure: dmarc tells you the failure is specifically a DMARC alignment failure, the type introduced by RFC 9991.
Identity-Alignment: dkim, spf is the key diagnostic line. Both mechanisms failed to produce an aligned identifier, which combined with no valid DKIM signature and a failing SPF check, points strongly toward outright spoofing rather than a misconfiguration on your side.
Source-IP and Original-Mail-From tell you where the message actually came from, useful for blocklisting or further investigation.
Reported-Domain confirms which of your domains was targeted, handy if you manage several.
SPF-DNS shows the SPF record the receiver evaluated against, which helps you confirm whether your own record was read correctly.

If this had instead been a legitimate third-party sender you forgot to authorize, you’d typically see Identity-Alignment naming only one mechanism, with the other showing a pass, which points you toward a configuration fix rather than an attack.

Why You Might Not Receive Failure Reports

If you’ve set up ruf= and the reports never show up, or barely trickle in, there are several legitimate reasons:

1. Major providers mostly don’t send them

Gmail and Yahoo, among the largest sources of inbound mail for most domains, generally don’t generate failure reports..

2. Privacy and redaction

Failure reports can expose personal information from message headers or bodies, which creates GDPR and CCPA exposure for the sender. RFC 6590 covers redacting sensitive data from abuse reports, and applying that redaction can strip out much of what made the report useful in the first place.

3. External destinations need to be verified

If your ruf= address points somewhere outside your own organizational domain, RFC 9991 requires the receiver to run an external destination verification check (the same mechanism RFC 9990 defines for aggregate reports) before it will send anything there. Without that authorization record in place, reports won’t arrive.

4. Rate-limiting is expected

RFC 9991 calls for reporters to limit how many failure reports they send to any one recipient, partly to avoid flooding a mailbox and partly to prevent reporting loops.

5. No failures, no reports

If your legitimate mail is authenticating cleanly, there’s nothing to trigger a failure report in the first place.

6. Your fo tag settings

The fo= tag controls exactly when a report fires: fo=0 (the default) only reports when both SPF and DKIM fail or misalign, fo=1 reports if either one fails, fo=d reports on DKIM failure specifically, and fo=s reports on SPF failure specifically. Most domains that actually want useful diagnostics set fo=1.

Email Feedback Loops and ARF

Failure reports aren’t the only place ARF shows up. ISP feedback loops (Yahoo’s Complaint Feedback Loop and Microsoft’s JMRP/SNDS programs among them) use the exact same ARF format, just with Feedback-Type set to abuse instead of auth-failure.

These reports fire when a recipient marks a message as spam, and they’re a useful early signal for deliverability problems even though they’re not tied to DMARC at all.

How to Set Up ARF / Failure Reporting for Your Domain

If you want to start collecting failure reports for your domain:

1. Add a ruf= tag to your DMARC DNS record pointing at a dedicated mailbox or reporting address.

2. Set fo=1 if you want reports on either an SPF or a DKIM failure, rather than only when both fail.

3. If the ruf= address lives outside your organizational domain, make sure the external destination authorization record is in place, or receivers won’t send anything there.

4. Register for feedback loop programs with major ISPs separately, since these run outside of DMARC entirely.

5. Don’t plan to read these by hand at any real volume. Even a small amount of mail can generate more raw ARF reports than is practical to parse manually. This is where an automated DMARC report analyzer simplifies things.

Summing Up

Failure reports are one specific application of ARF inside DMARC. RUF gives you rich, per-message detail when it arrives, but a meaningful share of receivers don’t send it, which makes aggregate (RUA) reporting your dependable, everyday source of visibility. With the DMARC standard now formalized across RFC 9989, RFC 9990, and RFC 9991, getting the terminology and details right matters more than ever, especially if you’re troubleshooting an actual spoofing incident rather than a simple misconfiguration.

If you’re setting up reporting for the first time or want to see this data without parsing raw ARF messages yourself, our DMARC Report Analyzer is built to handle exactly this. Sign up for a free trial today, and read your reports without the complexity!

Frequently Asked Questions

What is a DMARC failure (forensic) report?

It’s a per-message ARF report generated when an email fails DMARC authentication. It contains details about the specific message, including which authentication mechanisms failed and whether they produced an identifier aligned with the From: domain. “Forensic report” is the older name for the same thing, carried over from RFC 7489.

What is the difference between RUA and RUF in DMARC?

RUA (aggregate) reports are daily XML summaries covering all mail seen from a domain, now defined in RFC 9990. RUF (failure) reports are near-real-time ARF reports about individual failing messages, defined in RFC 9991. RUA is broadly supported; RUF is optional and inconsistently sent.

Who sends DMARC failure reports?

Only some receivers generate them at all, and major mailbox providers like Gmail and Yahoo generally don’t. Support varies by receiver, and privacy concerns, rate-limiting requirements, and destination verification rules under RFC 9991 all reduce how often they actually arrive.

What is the difference between ARF and XARF?

ARF (RFC 5965) is the IETF-standardized format used across DMARC failure reports and ISP feedback loops. XARF is a proprietary, vendor-originated extension that adds a JSON payload for easier parsing. It isn’t an IETF standard and isn’t used by major providers for DMARC reporting.

Why am I not receiving any DMARC failure reports?

Likely reasons include sending to major providers that don’t generate them, privacy redaction stripping the report down, a missing external destination verification record if your ruf= address is off-domain, mandatory rate-limiting on the receiver’s side, or simply having no authentication failures to report in the first place. Your fo= tag setting also determines exactly when a report gets triggered.

About
Latest Posts

Ahona Rudra

Domain & Email Security Expert at PowerDMARC

Ahona is the Marketing Manager at PowerDMARC, with 5+ years of experience in writing about cybersecurity topics, specializing in domain and email security. Ahona holds a post-graduation degree in Journalism and Communications, solidifying her career in the security sector since 2019.