Abuse Reporting Format (ARF)
The Abuse Reporting Format (ARF) is a standardised, machine-readable format for reporting email abuse between providers. It is defined in RFC 5965 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 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:
- A human-readable
text/plainexplanation. - The
message/feedback-reportpart with the machine-readable fields. - The reported message itself, as
message/rfc822(full message) ortext/rfc822-headers(headers only).
From: <abuse@mailbox-provider.example>
To: <fbl@sender.example>
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: <bounce-9f21c@sender.example>
Original-Rcpt-To: <recipient@mailbox-provider.example>
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-reportpart 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 and should never be retried.
- Treat
Feedback-Type: not-spamdifferently — 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 follows.
- Accept that not every provider offers an FBL. For those, the
abuse@mailbox described under abuse desk remains the only channel.