Current standard
What this RFC defines
RFC 5965 defines ARF (Abuse Reporting Format), the standardised format used by mailbox providers to send spam complaint reports to senders via Feedback Loops (FBLs). An ARF report is a MIME message containing a human-readable description, the original message headers, and a machine-readable block with the feedback type and category.
Where you see it in practice
When a recipient clicks the spam button in Gmail, Outlook, or Yahoo, the mailbox provider generates an ARF complaint report and sends it to the FBL address registered by the sending ESP. Your ESP uses these ARF reports to automatically unsubscribe complainers and track complaint rates per campaign. A high complaint rate (above 0.08% for Gmail) triggers inbox placement penalties.
The ARF feedback format
RFC 5965 defined the Abuse Reporting Format (ARF) in August 2010, standardizing the structure of feedback reports sent from mailbox providers to mail senders when recipients report spam. An ARF report is a multipart/report with content-type feedback-report, containing fields like Feedback-Type (abuse, opt-out, virus, fraud), User-Agent (identifying the reporting system), Original-Mail-From, Original-Rcpt-To, Reported-Domain, and the original message headers.
Feedback Loops (FBLs)
ARF is the payload format for Feedback Loops (FBLs), the system by which major mailbox providers notify senders about spam complaints. Yahoo, Comcast, AOL, Outlook.com, and other providers offer FBL enrollment programs where a sender registers their sending IPs or DKIM domains. When a user marks mail from that sender as spam, the provider generates an ARF report and sends it to a designated address. Senders use these reports to suppress future mail to complaining recipients and to identify subscriber quality issues.
Gmail is the exception
Gmail does not offer a traditional per-sender FBL. Instead, it provides Postmaster Tools (a dashboard showing aggregated complaint rates, spam classification, and authentication statistics) and expects senders to monitor those metrics rather than receive individual complaint messages. This reflects Google privacy design: individual complaints could theoretically identify the complainer, so Google aggregates before disclosure. Bulk senders should sign up for both Postmaster Tools (Gmail) and traditional FBLs (Outlook.com, Yahoo, etc.) to get full complaint visibility.
RFC 5965 (August 2010) defines ARF (Abuse Report Format): the structured format that ISPs use to report spam complaints back to senders via feedback loops (FBLs). When a recipient clicks “Report as spam” at Gmail, Yahoo, Outlook.com, or similar, the ISP generates an ARF report and sends it to a registered address for the sending domain. Uses multipart/report; report-type=feedback-report per RFC 6522. Sibling of DSN and MDN. Bulk senders parse ARF to auto-suppress complaining recipients and preserve sender reputation.
RFC 5965 at a glance
| Aspect | Detail |
|---|---|
| Purpose | Report abuse (spam complaints) from ISP back to sender |
| Container | multipart/report; report-type=feedback-report |
| Machine-readable part | message/feedback-report Content-Type |
| Delivery | Via SMTP to sender’s registered FBL address |
| Enrollment | Sender must register with each ISP’s FBL program |
| Common ISPs | Yahoo, Microsoft (Outlook.com/Hotmail), AOL/Verizon, Comcast; Gmail uses Postmaster Tools instead of ARF |
| Published | August 2010 |
| Extended by | RFC 6591 (authentication failure reports), RFC 6650 (creation and use guidance) |
The message/feedback-report fields
| Field | Purpose | Required? |
|---|---|---|
Feedback-Type | Report category: abuse, fraud, virus, other, auth-failure | Required |
User-Agent | Name and version of ARF-generating software | Required |
Version | ARF format version (currently 1) | Required |
Original-Mail-From | MAIL FROM of the complained-about message | Recommended |
Original-Rcpt-To | Recipient who complained | Recommended |
Arrival-Date | When the original message arrived | Recommended |
Reported-Domain | Domain identified as the source of abuse | Recommended |
Source-IP | IP address of the reported sender | Recommended |
Original-Envelope-Id | ENVID from RCPT TO if used | Optional |
Authentication-Results | SPF/DKIM/DMARC verdicts at ISP | Optional |
Full ARF example
From: complaints@fbl.example-isp.com
To: fbl@sender-domain.com
Subject: FW: Newsletter (abuse report)
Content-Type: multipart/report; report-type=feedback-report;
boundary=”arf-boundary-xyz”
–arf-boundary-xyz
Content-Type: text/plain; charset=utf-8
This is an email abuse report for an email message received
from IP 192.0.2.10 on 2026-07-15 at 09:32 UTC. For more
information about this format please see
https://www.rfc-editor.org/rfc/rfc5965.
–arf-boundary-xyz
Content-Type: message/feedback-report
Feedback-Type: abuse
User-Agent: SomeGeneratedBySoftware/1.0
Version: 1
Original-Mail-From: <bounces@sender-domain.com>
Original-Rcpt-To: <user@example-isp.com>
Arrival-Date: Wed, 15 Jul 2026 09:32:15 +0000
Reported-Domain: sender-domain.com
Source-IP: 192.0.2.10
Authentication-Results: mx.example-isp.com;
dkim=pass header.d=sender-domain.com;
spf=pass smtp.mailfrom=sender-domain.com;
dmarc=pass header.from=sender-domain.com
–arf-boundary-xyz
Content-Type: message/rfc822
From: Sender <newsletter@sender-domain.com>
To: user@example-isp.com
Subject: This week’s newsletter
Message-ID: <abc123@sender-domain.com>
Date: Wed, 15 Jul 2026 09:15:22 +0000
…
–arf-boundary-xyz–
Some ISPs redact the recipient address (Original-Rcpt-To
becomes user-xxxxxxxx@example-isp.com or is omitted) to
protect user privacy. Complaint aggregation without
individual identification is common practice.
Feedback-Type values
| Value | Meaning | Typical response |
|---|---|---|
abuse | Recipient complained about unsolicited or unwanted mail | Add to suppression list immediately |
fraud | Reported as fraudulent (phishing, scam) | Investigate and suppress; may indicate compromised account |
virus | Reported as containing malicious content | Investigate content pipeline; check for compromised accounts |
auth-failure | Authentication (SPF/DKIM/DMARC) failed at recipient (per RFC 6591) | Investigate configuration; report may be forensic DMARC (ruf) |
other | Complaint category not covered above | Depends on specific ISP practices |
Major ISP FBL programs
| ISP | Program | Sign-up |
|---|---|---|
| Yahoo Mail | Yahoo Complaint Feedback Loop | Requires DKIM signing; sign up via Yahoo Sender Hub |
| Microsoft (Outlook.com, Hotmail, Live) | Junk Mail Reporting Program (JMRP) | Requires SNDS access; sign up via Microsoft Sender Support |
| AOL / Verizon | AOL FBL | Historical; check current status |
| Comcast | Comcast FBL | Sign up via Comcast Postmaster |
| Gmail | Postmaster Tools dashboard (NOT ARF) | Aggregate reputation and complaint rate visible in dashboard; no per-complaint report |
| Various regional | Local ISP FBLs | Varies; check with regional postmaster contacts |
Common ARF handling mistakes
Related standards and further reading
- Feedback Loops and ARF Guide: practical FBL setup
- DSN Parsing Guide: parsing sibling format
- Suppression Lists Best Practices: acting on ARF signals
- DKIM Record Guide: signing prerequisite for many FBLs
Frequently asked questions
How do I sign up for feedback loops?
Each ISP has its own FBL program with sign-up requirements. Yahoo requires DKIM signing plus sign-up via Yahoo Sender Hub. Microsoft requires SNDS (Smart Network Data Services) access and sign-up via Microsoft Sender Support. Comcast provides a public form on their postmaster site. Signup typically requires: proof of domain ownership, DKIM signing on outbound mail, and a dedicated FBL mailbox to receive reports. Gmail does not offer ARF FBL; use Postmaster Tools instead for aggregate complaint data.
What should I do when I receive an ARF report?
Auto-suppress the Original-Rcpt-To address permanently. Continuing to send to a complainer destroys reputation. Log the report for analysis (patterns in complaint categories, timing, source). Track complaint rate per campaign, per subscriber source, per content type; this data drives program improvements. Do not respond to the report or investigate individual complaints; ISPs consider FBL reports one-way notifications.
Why does Gmail not send ARF?
Gmail’s design choice: aggregate complaint rate via Postmaster Tools dashboard rather than per-complaint reports. Google’s reasoning includes user privacy (per-complaint reports could allow senders to identify complainers) and scale (Gmail’s volume would generate enormous ARF traffic). Senders monitor Gmail complaint rate via Postmaster Tools instead. The signal is aggregate but frequent enough for operational decisions.
How does ARF relate to DMARC forensic reports?
RFC 6591 extended ARF to carry DMARC forensic (ruf) reports with Feedback-Type: auth-failure. The container is the same multipart/report; the payload distinguishes purpose. Sender-side parsers should route based on Feedback-Type: abuse/fraud/virus to complaint suppression pipelines, auth-failure to authentication investigation. Many DMARC processors handle both automatically.
Is ARF still relevant in 2026 given the rise of DMARC?
Yes. DMARC handles authentication reporting; ARF handles content and behavior complaints (spam, phishing). These are complementary. Even with p=reject DMARC deployed, recipients still click “Report as spam” and ARF FBLs still deliver those signals to senders. Bulk sender best practice in 2026: deploy DMARC, register for major FBLs, monitor Gmail Postmaster Tools, act on all signals.
Did this guide save you time?
SMTPedia is free and independent. A coffee helps keep every guide accurate.
Buy SMTPedia a coffeeAbout the Author
Alaa · LinkedIn
Email infrastructure specialist with 8+ years of hands-on experience in SMTP, deliverability, and email verification. I’ve configured and troubleshot mail systems across Postfix, Exchange, and cloud relays, managed IP reputation and warmup campaigns, and built verification pipelines processing millions of addresses. My work spans DNS authentication (SPF, DKIM, DMARC, BIMI), bounce handling, blocklist monitoring, and compliance frameworks including CAN-SPAM and GDPR. I write every article on SMTPedia to give email professionals, developers, and marketers the accurate, RFC-grounded reference they need.
About SMTPedia
SMTPedia is an independent email industry reference covering SMTP, IMAP, POP3, email deliverability, marketing platforms, DNS authentication, and email verification. Every article is researched from official provider documentation, IETF RFCs, and industry best practices. Settings and configurations are verified quarterly.
We are cited as a source by ChatGPT, Microsoft Copilot, and thousands of email professionals worldwide. Learn more about our editorial process.