ARF: what RFC 5965 (and Auto-Submitted) actually define
A standards-first look at the Abuse Reporting Format: how a "report spam" click becomes a machine-readable complaint, and what Auto-Submitted does.
A recipient clicks "report spam" in their mail client. That single action needs to reach the original sender, or their platform, as something more useful than a rumor: which message, sent to which address, got flagged. Before a standard existed for this, a mailbox provider offering any feedback at all invented its own report format, and a sender processing complaints across more than one provider had to build a separate parser for each.
That's the same problem DSN solved for delivery failures: free-form bounce text that varied by server, useless to any parser, until a machine-readable format replaced it. Complaints needed the same treatment.
What ARF (and Auto-Submitted) define
RFC 5965 defines the Abuse Reporting Format (ARF): a multipart/report structure, the same container RFC 3462 defined for DSN, carrying a machine-readable complaint about one specific message. A sender typically receives ARF reports through a feedback-loop (FBL) subscription registered with a mailbox provider.
RFC 3834 defines a single header, Auto-Submitted, covered here as a subsection since it's too thin on its own for a page of its own. The header marks a message as automatically generated, so a receiving system, including complaint and feedback-loop processing, knows not to auto-reply to it or treat it as if a human sent it. Both RFCs boil down to the same signal: telling the receiving side that a message is automated mail, not something a person typed.
How it works
A recipient marks a message as spam. The mailbox provider generates an ARF report, a multipart/report message with feedback-type: abuse, and sends it to the address the original sender registered for that provider's FBL. The report typically embeds the original message or its headers, so the sender can identify exactly which send triggered the complaint.
A sender registered for FBLs at major mailbox providers processes these reports to suppress future sends to that recipient. That's the entire mechanical loop: a complaint goes in, a report comes out, the sender acts on it.
Auto-Submitted operates independently of that loop but covers related ground. Any automated message, an autoresponder, a bounce, or an FBL report itself, should carry Auto-Submitted: auto-generated (or auto-replied, auto-notified). That tells the receiving system not to treat the message as human-sent and not to trigger an automatic reply, which keeps two automated systems from looping replies at each other.
Anatomy
ARF and Auto-Submitted each define their own small, fixed vocabulary.
ARF's machine-readable fields, inside the feedback-report part:
| Field | What it holds |
|---|---|
Feedback-Type | The complaint category: abuse, fraud, or other |
User-Agent | The software that generated the report |
Version | The ARF version the report conforms to |
Original-Mail-From | The envelope sender of the reported message |
Original-Rcpt-To | The recipient who filed the complaint |
Arrival-Date | When the reported message arrived |
Reported-Domain | The domain the report identifies |
Auto-Submitted values:
| Value | What it signals |
|---|---|
no | Human-sent. The default when the header is absent |
auto-generated | Generated automatically, with no direct human action behind it |
auto-replied | An automatic response to another message |
auto-notified | An automatic notification, such as an MDN |
Worked example
A complete ARF report for a message a recipient marked as spam:
Content-Type: multipart/report; report-type=feedback-report; boundary="arf-boundary"--arf-boundaryContent-Type: text/plain; charset=us-asciiThis is an email abuse report for a message received from IP203.0.113.10 on Tue, 11 Aug 2026 09:12:03 +0000.--arf-boundaryContent-Type: message/feedback-reportFeedback-Type: abuseUser-Agent: ExampleMail/1.0Version: 1Original-Mail-From: <sender@example.com>Original-Rcpt-To: <user@example.com>Arrival-Date: Tue, 11 Aug 2026 09:12:03 +0000Reported-Domain: example.com--arf-boundaryContent-Type: message/rfc822(original message or headers)--arf-boundary--
The first part exists for a human reviewing the report. The message/feedback-report part is what a sender's software reads: Feedback-Type: abuse and Original-Rcpt-To: user@example.com are enough on their own to identify the complaint and the address to suppress. The third part carries the original message, or just its headers, for full identification.
Limits
FBL coverage isn't uniform. Gmail, Yahoo, and Microsoft each run their own feedback-loop program, with separate registration and separate volume or reputation thresholds a sender has to clear before that provider starts sending reports at all.
ARF only exists for a given mailbox once a sender has registered for that provider's FBL. There's no universal, automatic complaint channel that works everywhere by default: a provider a sender never registered with doesn't send reports, and there's no fallback.
Auto-Submitted is advisory only. RFC 3834 defines what the header means, not any requirement that a receiving system honor it. Nothing forces a sender or an intermediary to check for it, or to act on it once found.
Check it yourself
If you run an FBL subscription with a major mailbox provider, open the raw headers of a received ARF report directly, rather than whatever summary your monitoring tool renders. Look for the Feedback-Type and Original-Rcpt-To fields inside the message/feedback-report part: those two alone tell you the complaint category and the exact address that triggered it.
Where it fits
ARF and DSN both use the multipart/report container, but report on different things: DSN reports a delivery outcome, ARF reports a complaint. A sender monitoring outbound mail watches both as separate feedback channels. MDN adds a third signal, disposition, what a recipient's client did with a message after it arrived, independent of whether it bounced or got flagged as abuse.
Auto-Submitted matters on the filtering side too. Server-side rules defined in Sieve can act on the header, routing or handling a message differently once it's marked as automatically generated.
For the wider set of standards this page sits inside, see the reference hub.
Nuntly surfaces this as a complaint event and a complaint-rate metric; see the receiving observability guide and the sending webhooks reference.
FAQ
Do I automatically get ARF reports from every mailbox provider?
No. ARF reports only arrive once you've registered for a given provider's feedback-loop program, and each major provider runs its own separate program with its own requirements.
What's inside an ARF report besides the complaint itself?
A machine-readable feedback-report part with fields like Feedback-Type and Original-Rcpt-To, plus typically the original message or its headers, so the sender can identify exactly which message and recipient triggered it.
Why does Auto-Submitted matter for feedback loops?
An FBL report, a bounce, or an autoresponder is itself an automated message. Marking it Auto-Submitted tells the receiving system not to treat it as human-sent or reply to it automatically, which prevents a loop between two automated systems.
Does an ARF report guarantee the sender did something wrong?
No. It reports that a specific recipient marked a specific message as spam, which can reflect genuine abuse, a stale list, or simply a recipient who forgot subscribing. The report itself doesn't classify the cause.
RFC reference
RFCs covered: RFC 5965, RFC 3834. Superseded / updated by: None for either.