RFC 5965: ARF — Abuse Reporting Format
ELI5: When someone clicks “Report Spam” in their email client, the mailbox provider needs a way to tell the sender about it. ARF is the standardized format for that complaint — a structured message that says “this recipient marked your email as spam” along with a copy of the offending message.
Why This Exists
Mailbox providers (Gmail, Yahoo, Outlook, etc.) let users report unwanted email as spam. Responsible senders need this feedback to remove complainers from their lists and identify problems with their sending. Without a standard format, each provider would use a different complaint format, making automated processing impossible.
ARF provides the standard. Mailbox providers use it to send feedback loop (FBL) reports, and senders parse these reports to:
- Immediately suppress the complaining recipient
- Track complaint rates per campaign, IP, or sending domain
- Detect compromised accounts or unexpected sending
- Report authentication failures and other abuse types
How It Works
An ARF report is a multipart/report MIME message with report-type=feedback-report. It contains three parts:
-
Human-readable description (
text/plain) — summary for human reviewers. -
Machine-readable report (
message/feedback-report) — structured fields defined by this RFC. -
Original message (
message/rfc822ortext/rfc822-headers) — the email that was reported.
ARF Report Example
From: feedback@isp.example.com To: abuse@sender.example.com Subject: FBL report - complaint from user MIME-Version: 1.0 Content-Type: multipart/report; report-type=feedback-report; boundary="ARF-BOUNDARY-001" --ARF-BOUNDARY-001 Content-Type: text/plain This is an abuse report for a message received from IP 203.0.113.10 on Wed, 11 Mar 2026 09:15:00 -0500. --ARF-BOUNDARY-001 Content-Type: message/feedback-report Feedback-Type: abuse User-Agent: ISP-FBL/1.0 Version: 1 Original-Mail-From: campaign@sender.example.com Arrival-Date: Wed, 11 Mar 2026 09:15:00 -0500 Source-IP: 203.0.113.10 Reported-Domain: sender.example.com Authentication-Results: isp.example.com; dkim=pass header.d=sender.example.com; spf=pass smtp.mailfrom=sender.example.com --ARF-BOUNDARY-001 Content-Type: message/rfc822 From: campaign@sender.example.com To: user@isp.example.com Subject: Weekly Newsletter #42 Message-ID: <news-42@sender.example.com> List-Unsubscribe: <https://sender.example.com/unsub?id=xyz> [original message body] --ARF-BOUNDARY-001--
Key Technical Details
Feedback-Type Values
| Type | Meaning |
|---|---|
abuse |
User reported the message as spam (the most common type) |
fraud |
Message appears to be phishing or a scam |
virus |
Message contained malware |
other |
Catch-all for reports that do not fit other categories |
not-spam |
User indicated this is NOT spam (false positive correction) |
auth-failure |
Authentication check failed (RFC 6591 extends this) |
Required and Optional Fields
| Field | Required | Description |
|---|---|---|
Feedback-Type |
Yes | The type of report (see above) |
User-Agent |
Yes | Name and version of the generating software |
Version |
Yes | Always 1 for this RFC |
Original-Mail-From |
No | The envelope sender (MAIL FROM) of the reported message |
Arrival-Date |
No | When the reported message arrived |
Source-IP |
No | The IP that sent the reported message |
Reported-Domain |
No | The domain associated with the reported message |
Authentication-Results |
No | Authentication results per RFC 8601 |
Reported-URI |
No | URIs found in the reported message (repeatable) |
Original-Rcpt-To |
No | The envelope recipient of the reported message |
Privacy Considerations
Many mailbox providers redact the recipient address from the included original message to protect user privacy. The complaint may only include headers, not the full body. Some providers (notably Yahoo) include the full original message; others (like Microsoft) send only headers. Your ARF parser must handle both cases.
Common Mistakes
- Not registering for feedback loops. Most major mailbox providers require you to register your sending IPs or domains for their FBL program. Without registration, you will never receive ARF reports.
- Ignoring complaint rate. Mailbox providers track complaint rates (complaints / messages delivered to inbox). Exceeding 0.1% is a warning; exceeding 0.3% will typically trigger filtering or blocking. Parse ARF reports and act fast.
-
Not suppressing complainers immediately. When you receive an ARF report with
Feedback-Type: abuse, immediately suppress that recipient. Continuing to send to someone who complained is a fast path to blocklisting. - Parsing only specific FBL formats. Different providers may include different optional fields or vary the original message content. Build a robust parser that handles missing fields gracefully.
-
Confusing ARF with DSN. DSNs (RFC 3464) report delivery status (bounce/delay/success). ARF reports user complaints. They use similar
multipart/reportstructure but differentreport-typevalues and serve different purposes.
Deliverability Impact
- Complaint rate is a top reputation signal. Gmail, Yahoo, and Microsoft all use complaint rates to decide whether to deliver your mail to the inbox, spam folder, or reject it outright. ARF processing is not optional for any serious sender.
- FBL data drives list hygiene. ARF reports tell you exactly which recipients do not want your mail. This is more actionable than bounces because the address is valid — the human just does not want your messages.
-
Campaign diagnostics. By correlating ARF reports with the
Message-IDor custom headers in the original message, you can identify which campaigns, subject lines, or content triggered complaints. - Account compromise detection. A sudden spike in ARF reports can indicate that a customer's account or API key has been compromised and is being used to send spam.