--- title: "Abuse Reporting Format (ARF)" description: "ARF is a standardized, MIME-based format for reporting email abuse incidents like phishing or spam between providers and abuse teams." url: "https://mailmum.io/glossary/abuse-reporting-format-arf/" --- # Abuse Reporting Format (ARF) The Abuse Reporting Format (ARF) is a standardised, machine-readable format for reporting email [abuse](https://mailmum.io/glossary/abuse/) between providers. It is defined in [RFC 5965](https://www.rfc-editor.org/rfc/rfc5965) and is the format in which almost every feedback loop delivers its complaints. An ARF report is itself an email message. What makes it machine-readable is a MIME part of type `message/feedback-report` that carries the facts of the incident — source IP, envelope sender, arrival time, type of complaint — as structured fields instead of prose. ## Why does ARF exist? An [abuse desk](https://mailmum.io/glossary/abuse-desk/) at a large mailbox provider may forward hundreds of thousands of complaints a day. Free-text reports have to be read by a human; ARF reports can be parsed, correlated with sending logs, and used to suppress a recipient automatically within seconds of the complaint. That automation is the entire point. A sender enrolled in a feedback loop can remove a complaining recipient from its lists before the next campaign goes out, which is what keeps complaint rates below the threshold where mailbox providers start rejecting mail outright. ## How is an ARF report structured? An ARF report is a `multipart/report` message with `report-type=feedback-report` and three parts: 1. A human-readable `text/plain` explanation. 2. The `message/feedback-report` part with the machine-readable fields. 3. The reported message itself, as `message/rfc822` (full message) or `text/rfc822-headers` (headers only). ```txt From: To: Subject: FW: Special offer for you Date: Tue, 04 Aug 2026 08:12:19 +0000 MIME-Version: 1.0 Content-Type: multipart/report; report-type=feedback-report; boundary="part-0815" --part-0815 Content-Type: text/plain; charset="us-ascii" This is an email abuse report for an email message received from 192.0.2.25 on Tue, 04 Aug 2026 08:11:02 +0000. For more information about this format please see https://www.rfc-editor.org/rfc/rfc5965 --part-0815 Content-Type: message/feedback-report Feedback-Type: abuse User-Agent: ExampleFBL/1.0 Version: 1 Original-Mail-From: Original-Rcpt-To: Arrival-Date: Tue, 04 Aug 2026 08:11:02 +0000 Source-IP: 192.0.2.25 Reporting-MTA: dns; mx1.mailbox-provider.example Reported-Domain: sender.example Authentication-Results: mx1.mailbox-provider.example; spf=pass smtp.mailfrom=sender.example; dkim=pass header.d=sender.example --part-0815 Content-Type: message/rfc822 [the original message, headers and body] --part-0815-- ``` ## Which fields does a feedback report contain? Only three fields are required: `Feedback-Type`, `User-Agent` and `Version`. Everything else is optional, which is why parsers have to tolerate reports that are missing the field they care most about. | Field | Meaning | | --- | --- | | `Feedback-Type` | `abuse`, `fraud`, `virus`, `not-spam` or `other` | | `User-Agent` | the software that generated the report | | `Version` | format version, currently `1` | | `Source-IP` | the IP address the reported message was received from | | `Original-Mail-From` | the envelope sender of the reported message | | `Original-Rcpt-To` | the complaining recipient, often redacted | | `Arrival-Date` | when the reported message was received | | `Reported-Domain` | the domain held responsible | In practice most large providers redact the recipient address before sending the report, so `Original-Rcpt-To` is either absent or replaced by a placeholder. The sender is expected to identify the recipient from a unique identifier in the returned message — typically a VERP envelope sender or a `List-Unsubscribe` token. ## What is a feedback loop? A feedback loop (FBL) is an arrangement in which a mailbox provider sends you an ARF report every time one of its users clicks "report spam" on a message from your IP addresses or domains. Enrolment is per-provider and usually requires proving control of the sending IP range or of the DKIM signing domain. Reports are delivered to an address you nominate. That address should be processed automatically rather than read by a person: the expected action is to suppress the recipient immediately and to record the complaint against the campaign it came from. ## How should you handle incoming ARF reports? * Parse the `message/feedback-report` part rather than the prose part. The wording of the prose differs between providers; the fields do not. * Suppress the complaining recipient permanently. A complaint is a stronger signal than a soft [bounce](https://mailmum.io/glossary/bounce-message/) and should never be retried. * Treat `Feedback-Type: not-spam` differently — it reports the opposite, a message a user rescued from the spam folder, and must not trigger suppression. * Watch the rate, not just the individual reports. A sudden rise in complaints from one IP address usually means a compromised account rather than a bad campaign, and it is the earliest warning you will get before [blacklisting](https://mailmum.io/glossary/ip-blacklisting/) follows. * Accept that not every provider offers an FBL. For those, the `abuse@` mailbox described under [abuse desk](https://mailmum.io/glossary/abuse-desk/) remains the only channel.