What Is ARF in Email? Abuse Reporting Format Explained

In email, ARF stands for Abuse Reporting Format — the IETF standard (RFC 5965) that makes spam complaints and DMARC forensic reports machine-readable. If you have ever seen the phrase “what is ARF in email” sitting beside a ruf= tag in a DMARC record, this is what it means: a MIME envelope ISP feedback loops and authentication-failure reporters use to deliver structured complaints back to senders.

ARF matters because it is the wire format underneath every DMARC forensic report, every “report spam” complaint that leaves Yahoo or Microsoft, and every modern feedback-loop integration — and it is one of the rarest signals you will ever ingest. DMARCguard scanner data (April 2026) shows 16.3% of scanned domains publish a rua= aggregate mailbox, and only a fraction of those also publish a ruf= forensic mailbox. Among the major mailbox providers, Microsoft has explicitly confirmed it does not emit forensic reports; the rest are publicly silent. (That 16.3% is a rua= proxy; we do not measure ARF emission directly.)

By the end of this guide you will know the three-part MIME structure defined by RFC 5965, the field semantics that matter for an admin, why DMARC ruf= reports rarely materialize in 2026, and how to register for the ISP feedback-loop programs that still emit ARF.

What Is the Abuse Reporting Format (ARF)?

ARF, the Abuse Reporting Format, is a MIME-based email format defined in RFC 5965 (2010). It packages an abuse complaint, a DMARC forensic report, or an ISP feedback-loop notification into three machine-readable parts so abuse desks can process them automatically. That single sentence is the short answer; the rest of the section explains where it came from and why it sits at the intersection of two very different workflows.

The format has two parents. AOL built the first large-scale Complaint Feedback Loop in 2005 using a proprietary format, then helped standardize the design through the IETF’s MARF working group. The result was RFC 5965, which formalized the multipart/report; report-type=feedback-report envelope and a registry of fields like Feedback-Type, Source-IP, Authentication-Results, and Reported-Domain (RFC 5965 §3.1 for the MIME structure, §3.3 for the field registry).

A useful framing: ARF is the envelope, and what fills it depends on who is reporting what. When a Yahoo recipient hits “report spam,” the complaint leaves Yahoo’s postmaster as an ARF message with Feedback-Type: abuse. When a receiver sends the publisher of a DMARC record a sample of a message that failed authentication, it uses the AFRF profile (RFC 6591) with Feedback-Type: auth-failure. Same envelope, different cargo.

You will sometimes see MARF (“Messaging Abuse Reporting Format”) in older M3AAWG and IETF documents. MARF is just the working-group name that produced the ARF family of RFCs (5965, 6591, 6650, 6651, 6652, 6692); the format itself is always called ARF.

ARF Format: The Three-Part MIME Structure

The ARF format is a multipart/report; report-type=feedback-report MIME message with three nested parts. RFC 5965 §3.1 fixes the order, and every ARF emitter you will encounter — Yahoo, Mail.ru, Seznam, the OpenDMARC filter, the Comcast feedback loop — produces the same shape:

1. text/plain — the human-readable summary an abuse-desk operator sees first.
2. message/feedback-report — the structured key-value block that parsers actually read.
3. message/rfc822 or text/rfc822-headers — the original message in full, or just its headers if the emitter is preserving recipient privacy.

The outer wrapper carries the report-type=feedback-report parameter; if you encounter a feedback loop whose outer Content-Type is multipart/mixed instead of multipart/report, your parser will reject standards-strict reports unless you special-case it. (The Comcast feedback loop is the well-known offender here.)

Part 2 — the message/feedback-report block — is where every interesting field lives. It always carries Version: 1, a Feedback-Type header, a User-Agent identifying the generator, and at minimum the Original-Mail-From, Source-IP, and Reported-Domain of the message that triggered the complaint. RFC 5965 §3.3 defines the canonical registry; later RFCs extend it for specific use cases.

Part 3 has been the part most affected by privacy regulation. Three variants exist in the public RFC record:

The RFC 9477 pattern is particularly important if you operate inside the EU: the modern Coordinated Feedback Loop strips the original message down to an opaque tag the sender injected at send time, so no recipient PII ever leaves the receiver.

ARF Email Reports Explained: An Annotated Real Example

Captured ISP ARF traffic stays private because it carries complainant PII, so the verbatim citable samples in the public record live in IETF RFC appendices. The sample below is RFC 5965 Appendix B.2 — the canonical ARF email format, reproduced exactly.

From: <abusedesk@example.com>
Date: Thu, 8 Mar 2005 17:40:36 EDT
Subject: FW: Earn money
To: <abuse@example.net>
MIME-Version: 1.0
Content-Type: multipart/report; report-type=feedback-report;
     boundary="part1_13d.2e68ed54_boundary"

--part1_13d.2e68ed54_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

This is an email abuse report for an email message received from IP
192.0.2.1 on Thu, 8 Mar 2005 14:00:00 EDT.

--part1_13d.2e68ed54_boundary
Content-Type: message/feedback-report

Feedback-Type: abuse
User-Agent: SomeGenerator/1.0
Version: 1
Original-Mail-From: <somespammer@example.net>
Original-Rcpt-To: <user@example.com>
Arrival-Date: Thu, 8 Mar 2005 14:00:00 EDT
Reporting-MTA: dns; mail.example.com
Source-IP: 192.0.2.1
Authentication-Results: mail.example.com;
               spf=fail smtp.mail=somespammer@example.com
Reported-Domain: example.net
Reported-Uri: http://example.net/earn_money.html
Reported-Uri: mailto:user@example.com
Removal-Recipient: user@example.com

--part1_13d.2e68ed54_boundary
Content-Type: message/rfc822
Content-Disposition: inline

From: <somespammer@example.net>
Received: from mailserver.example.net (mailserver.example.net
     [192.0.2.1]) by example.com with ESMTP id M63d4137594e46;
     Thu, 08 Mar 2005 14:00:00 -0400
To: <Undisclosed Recipients>
Subject: Earn money
[...spam body...]
--part1_13d.2e68ed54_boundary--

The decoder table pairs each field with what it means and what an admin should actually do.

The DMARC variant looks slightly different. RFC 6591 (the AFRF profile, covered next) keeps the same outer envelope but swaps the field set: Feedback-Type: auth-failure replaces abuse, DKIM-specific fields appear (Auth-Failure: bodyhash, DKIM-Canonicalized-Body, DKIM-Domain, DKIM-Selector), and part 3 becomes text/rfc822-headers — dropping the body but preserving the DKIM-Signature, Received chain, and Subject (RFC 6591 §B.1).

If you want to inspect a real ARF report without writing a parser, paste the raw .eml into the DMARCguard ARF report analyzer — it breaks out the three MIME parts, decodes each field, and flags non-standard quirks like missing Date: headers or base64-wrapped parts.

ARF and DMARC Forensic Reports (the ruf= Tag)

Here is the link between the two formats: a DMARC forensic report is an ARF message whose Feedback-Type header is auth-failure. RFC 6591 defines the AFRF — Authentication Failure Reporting Format — profile, and AFRF is the DMARC ruf= report on the wire. If you have ever published a ruf=mailto: mailbox and wondered what would land in it, the answer is an AFRF-flavoured ARF message.

The DMARC ruf= tag is the publisher-side mailbox where receivers MAY send per-message forensic reports. It is paired with the fo= tag, which controls when those reports fire. RFC 7489 §6.3 defines four values: fo=0 (default — both SPF and DKIM must fail), fo=1 (either fails), fo=d (any DKIM failure), fo=s (any SPF failure). fo=1 is the value most senders actually want; fo=0 produces almost nothing because both checks rarely fail simultaneously.

Why forensic reports rarely materialize

Even when you publish a ruf= tag with fo=1, you should expect very few reports. Three reasons drive the scarcity, all of them documented in primary sources rather than vendor blog rumour.

1. GDPR and PII friction. The IETF DMARC working group puts it plainly in draft-ietf-dmarc-failure-reporting-25 (Steven M. Jones / Alessandro Vesely, 18 Apr 2026, §7): “many large-scale providers limit or entirely disable the generation of failure reports, preferring to rely on aggregate reports, which provide statistical visibility without exposing sensitive content.” Forensic reports carry message bodies, recipient addresses, and subject lines — all PII under GDPR.

2. Microsoft 365 explicitly does not emit. Microsoft has put it on the record in its own DMARC configuration documentation: “Microsoft 365 doesn’t send DMARC Forensic reports (also known as DMARC Failure reports), even if a valid ruf=mailto: address exists in the DMARC TXT record of the source domain.” (learn.microsoft.com, accessed 2026-04-28). It is the only on-record statement from a major mailbox provider, and it is a “no.”

3. Receiver coverage is collapsing. Of eight major mailbox providers (Gmail, Yahoo/AOL, Microsoft, Apple, Fastmail, Proton, Comcast, iCloud), Microsoft is the only one with an on-record statement and the rest are publicly silent. Practitioner consensus puts Yahoo (via the Red Sift partnership), NetEase, LinkedIn, and Seznam as the only credible AFRF emitters in 2026. If you are debugging the DMARC failure path, aggregate reports remain the primary signal.

A forwarding wrinkle: AFRF reports include the original Authentication-Results and any ARC chain on forwarded mail, so you can tell whether a failure originated at the sender or at an intermediate hop. ARC preserves the verdict across hops; AFRF tells you when the chain broke.

DMARC Failure Reports vs Aggregate Reports

The two DMARC report types serve different jobs. Aggregate (rua=) gives you statistical visibility across millions of messages; forensic (ruf=) gives per-message detail when authentication fails. The trade-offs are stark:

In practice, rely on aggregate reports as your primary signal and treat forensic reports as a supplementary feed when they show up at all. DMARCguard’s ingestion mirrors that: every rua= report is parsed and indexed, and any ARF/AFRF mail that does arrive is layered on top with full field-by-field decoding. If your deliverability runbook needs forensic reports for daily decisions, the data will not be there.

ISP Feedback Loops That Still Send ARF in 2026

Most ARF traffic in 2026 is not DMARC forensic at all — it is recipient “report spam” complaints flowing through ISP feedback-loop programs. These have their own registration workflow, their own quirks, and their own trajectory through 2024–2026 consolidation. The table below is the operational map:

Registration URLs are linked from the Yahoo Sender Hub FAQs (the authoritative reference for Yahoo, AOL, AT&T, and Comcast) and Microsoft’s SNDS portal. Mail.ru, La Poste, and Seznam each operate their own postmaster sites.

A few 2024–2026 changes competitor write-ups miss:

• AT&T migrated to Yahoo MX on August 6, 2025. All 13 AT&T consumer domains (sbcglobal.net, bellsouth.net, etc.) now route via Yahoo and use the Yahoo CFL — no standalone AT&T FBL.
• Microsoft JMRP body-stripping (Nov 2025+). Per spamresource.com, January 2026, JMRP ARF reports now strip the original message body and redact the sender address; only original headers, Authentication-Results, Received-SPF, DKIM-Signature, and ARC survive.
• Yahoo CFL is DKIM-only. Yahoo Sender Hub no longer offers IP/CIDR-keyed enrollment.
• Validity Universal FBL paywall. Since September 21, 2023, raw ARF feeds for the Universal FBL portfolio (Libero, Telenor, Terra, Fastmail, etc.) are a paid product (~$1,500/yr per 100k complaints).

Gmail is the deliberate non-FBL exception. Postmaster Tools v2 (V1 retired September 30, 2025) gives senders an aggregated Feedback-ID-keyed dashboard and API — but no ARF messages are ever sent. Google’s own help page explains the workflow: senders embed a Feedback-ID header on outbound mail, and identifiers with unusual spam rates surface inside the Postmaster Tools FBL dashboard. The absence of an outbound ARF feed is the policy.

ARF vs XARF: When the JSON Variant Matters

XARF (Extended Abuse Reporting Format) is a vendor extension by Abusix. It adds a JSON payload alongside the standard message/feedback-report block, allowing richer abuse-type taxonomies — phishing, malware, fraud sub-categories — that vanilla ARF does not encode.

The neutral framing: XARF is more expressive but adoption is concentrated in Abusix’s customer base. For DMARC forensic reports, Feedback-Type: auth-failure ARF is what every emitting receiver emits. If your abuse desk ingests both, treat ARF as the baseline parser and XARF as an optional enrichment path.

How to Read an ARF Report in Practice

The five-step workflow below is what an admin actually does when an ARF report lands in their abuse mailbox. Each step maps to a specific field in the message/feedback-report block:

1. Confirm the outer Content-Type. It should be multipart/report; report-type=feedback-report. If you see multipart/mixed instead (the Comcast quirk), your standards-strict parser will reject the message — special-case Comcast or skip it.
2. Read Feedback-Type first. abuse means a user complaint: suppress the recipient immediately and route the report to the deliverability queue. auth-failure means an AFRF/DMARC forensic report: route it to the security queue and do not suppress the recipient.
3. Decode Source-IP. Cross-reference it against your SPF include: chain. If the IP is absent from your authorized senders, you are looking at a forwarder, an unauthorized ESP, or a spoofer.
4. Cross-reference Original-Mail-From with Reported-Domain. The first is the return-path (RFC 5321 envelope sender); the second is the From-header domain. Divergence is your alignment-drift indicator.
5. For AFRF, read Auth-Failure. Values are spf, dkim, bodyhash, or dmarc. Each tells you exactly which mechanism failed at the receiver and points you at the right DKIM alignment or SPF fix.

That is the manual workflow. Skip the parsing step entirely by pasting your raw .eml into the DMARCguard ARF checker, which runs every step above in the browser and surfaces the admin actions inline with each field.

FAQ

What is ARF in DMARC?

In DMARC, ARF is the wire format used for forensic reports — the per-message notifications a receiver MAY send when a message fails authentication. RFC 6591 (AFRF) extends RFC 5965 with Feedback-Type: auth-failure and DKIM/SPF failure fields. ARF is the envelope; AFRF is the payload that fills it for DMARC.

Is ARF the same as a DMARC failure report?

A DMARC failure report (also called a forensic report or ruf report) is an ARF message with Feedback-Type: auth-failure. So every DMARC failure report is an ARF report, but not every ARF report is a DMARC failure report — most ARF traffic carries Feedback-Type: abuse and is generated when a recipient clicks “report spam” in their webmail.

What does RFC 5965 define?

RFC 5965 (2010) defines the Abuse Reporting Format itself: the multipart/report; report-type=feedback-report outer envelope, the message/feedback-report MIME type, and the initial registry of fields like Feedback-Type, User-Agent, Source-IP, and Reported-Domain. RFC 6591 and RFC 9477 extend the field set later.

Why am I not receiving ARF reports for my domain?

Three reasons. First, most major mailbox providers — Gmail, Microsoft 365, Apple, Fastmail, Proton — do not emit DMARC forensic reports at all (Microsoft confirmed this in writing). Second, you may not have published a ruf=mailto: tag. Third, ISP feedback loops require separate registration at each provider (Yahoo Sender Hub, Microsoft JMRP, Mail.ru, La Poste, Seznam).

What is the difference between ARF and XARF?

ARF (RFC 5965) is the IETF-standard MIME format every major receiver emits. XARF is Abusix’s vendor extension that adds a JSON payload for richer abuse-type taxonomies — phishing, malware, fraud. For DMARC forensic reports you will only ever see ARF; XARF adoption is concentrated in Abusix’s customer base.

How do I parse an ARF report programmatically?

Read it as a multipart/report MIME message, extract the message/feedback-report part, and parse the key-value fields per RFC 5965 §3.3. For DMARC forensic reports, apply the RFC 6591 §3.2 extensions for the AFRF field set. The DMARCguard ARF report analyzer does this in the browser — no installation, no language SDK.

What is MARF, the Messaging Abuse Reporting Format?

MARF was the IETF working-group name (2007–2012) that produced the ARF family of RFCs (5965, 6591, 6650, 6651, 6652, 6692). The format is called ARF; MARF was just the WG. You will see the term in older M3AAWG and IETF documents — both refer to the same thing.

What ARF Means for Your DMARC Programme in 2026

So: what is ARF in email? It is the MIME format (RFC 5965) that makes abuse complaints and DMARC forensic reports machine-readable. Three parts — a human summary, a structured message/feedback-report block, and the original message or its headers — wrapped in a multipart/report; report-type=feedback-report envelope.

• DMARC ruf= reports use the AFRF variant (RFC 6591) but rarely materialize in 2026, because Gmail, Microsoft 365, Apple, and most EU receivers do not emit them.
• Real ARF traffic lives in ISP feedback-loop programs — Yahoo Sender Hub, Microsoft JMRP, Mail.ru, La Poste, Seznam — each with its own registration workflow and its own quirks.
• Aggregate rua= reports remain the primary DMARC signal you should rely on; treat any forensic data that does arrive as supplementary.

DMARCguard ingests both your DMARC aggregate reports and any forensic or feedback-loop messages your domain receives, then surfaces the field-level admin actions inline. Start free — no credit card. For the deeper protocol reference, the ARF learn-page deep dive walks through every field in the RFC 5965 registry alongside the AFRF and CFBL extensions.