# RFC 3834 — Automatic Email Responses

> The auto-responder rulebook: when not to respond, the Auto-Submitted header, null return-path and loop prevention, and how senders should emit and handle OOO/vacation replies.

Source: emailmarketing.net — https://emailmarketing.net/learn/rfc/rfc3834-auto-replies

Every campaign you send triggers automatic replies such as out-of-office (OOO) notices, and every feature that answers mail automatically can start a mail loop. RFC 3834 is the rulebook for anything that answers mail automatically: vacation and OOO notices, bots that acknowledge tickets, and responders on file servers and mail servers.

Two of its contributions matter every day to an email service provider (ESP). The first is the **`Auto-Submitted:` header**, the standard machine-readable marker that says "this was not written by a human". The second is the **discipline of loop prevention**, which stops auto-responders, [bounces](https://emailmarketing.net/learn/bounce-handling/delivery-status-notifications) and bulk mail from feeding back into each other.

An ESP sits on both sides. Its campaigns trigger thousands of OOO replies, and its own transactional and notification traffic must not take part in loops.

## Responder taxonomy

| Type | Acts for | Example |
|---|---|---|
| Service Responder | An address whose whole purpose is to respond; senders expect the response | File retrieval, calendar booking |
| Personal Responder | One recipient, following that user's configuration | UNIX `vacation`, OOO |
| Group Responder | Many recipients, under uniform criteria | A server-wide notifier for viruses or quarantined mail |

## When a responder must NOT respond

Responders "MUST NOT blindly send a response for every message received":

- A responder **MUST NOT** respond when the response would go to a null address, that is, when the `MAIL FROM` or `Return-Path` of the subject message is `<>` (bounces and other notifications). This mirrors [RFC 5321's rule](https://emailmarketing.net/learn/rfc/rfc5321-smtp#null-reverse-path-mail-from) that notifications are sent with the null sender.
- It **SHOULD NOT** respond to any message that carries `Auto-Submitted:` with a value other than `no`. Auto-replies never answer auto-replies.
- It **MAY** refuse to respond to return paths with patterns typical of responders and mailing lists: local parts that match `owner-*`, `*-request`, `MAILER-DAEMON` and similar.
- Personal and Group responders **SHOULD NOT** respond unless the recipient's address appears explicitly in a `To:`, `Cc:`, `Bcc:` or `Resent-*` field. This prevents responses to bulk mail sent as Bcc, and to much spam.
- A responder **SHOULD NOT** respond to messages with the `Precedence:` values `list`, `junk` or `bulk`. This is a de facto rule that the RFC endorses; `Precedence` is not formally standardized.
- **Rate limit:** send the same response to the same sender at most once within a period of several days, with **7 days RECOMMENDED as the default**. Send at most one response per incoming message.
- Service responders SHOULD NOT answer badly malformed requests, and SHOULD NOT return large responses (more than a few kilobytes) without verifying that the requester authorized them. This defends against backscatter and amplification.

## Where the response goes

- **To the `Return-Path`** after delivery, or to the SMTP `MAIL FROM` reverse path before delivery. It is "really the only [address] that can be expected, as a matter of protocol, to be suitable for automatic responses that were not anticipated by the sender."
- Personal and Group responders **SHOULD NOT** use `Reply-To:`. `From:` has the same problems, and `Sender:` SHOULD NOT be used either. A Service Responder MAY use `From:`, or an address in the payload, if the specification of its service says so.
- If `Return-Path` is missing, the delivery agent has a bug. Do not guess with heuristics.

**What this means for an ESP:** OOO replies to your campaigns arrive at your **bounce address or Variable Envelope Return Path (VERP) address**, not at your `From:` or `Reply-To:` address. Your return-path processor must classify them (see below). The VERP encoding tells you which recipient is away, even when the body of the reply is useless.

## How a compliant response is built

- **Envelope:** choose a `MAIL FROM` that makes loops unlikely. **`<>` MAY be used**, or a dedicated response address that never responds. `NOTIFY=NEVER` on RCPT is RECOMMENDED where the server supports the [Delivery Status Notification (DSN) extension](https://emailmarketing.net/learn/rfc/esmtp-extensions), because an auto-responder does not want bounces of its own responses.
- **Header:**
  - `Auto-Submitted: auto-replied`.
  - `From:` reaches the human owner or maintainer. For personal responders, that is the recipient's name and a recognizable address.
  - `To:` is the single recipient of the response.
  - `Subject:` is a brief indication that this is an automatic response, followed by the original subject. The prefix `Auto: ` MAY be used (followed by an ASCII space, 0x20).
  - `In-Reply-To:` and `References:` SHOULD be set from the `Message-ID` of the subject message, as described in RFC 2822 §3.6.4.
  - `Date:` is the time the response was generated.
  - `Reply-To:` appears only if a reply is actually wanted, and points to where the reply is expected.
- **Body:** brief, in `text/plain`. It SHOULD NOT include significant content, non-text parts or attachments from the subject message. This stops responders from rebroadcasting confidential or malicious content.

## The `Auto-Submitted:` header field

The syntax is `Auto-Submitted: value [; parameters]`. The registered values are:

| Value | Meaning | Rules |
|---|---|---|
| `no` | The message originated with a human | Optional; its absence roughly indicates human origin |
| `auto-generated` | Sent by an automatic process **not** in direct response to another message (cron alerts, notifications, welcome mail) | MUST NOT be used on direct responses. MUST NOT label DSNs or message disposition notifications (MDNs), which are identified by their own MIME types |
| `auto-replied` | Sent by an automatic process in direct response to another message | SHOULD be used on all auto-replies; MAY also appear on DSNs and MDNs |

Extension keywords require IETF consensus. The field is the standard key for suppression: mail that carries `auto-generated` or `auto-replied` must never receive an automatic answer.

## Loop prevention, summarized

Loops are prevented by defense in depth, and each layer is sufficient on its own:

1. Responses go to the Return-Path, and messages with a null return path never get responses. A responder that sends with `MAIL FROM:<>`, or from a response address that stays silent, can therefore never be answered by a compliant peer.
2. `Auto-Submitted: auto-replied` marks the response, so other responders stay silent.
3. Remembering each sender, and responding at most once per sender per 7 days, caps volume even against a peer that does not comply.
4. One response per incoming message, never more (the defense against "sorcerer's apprentice mode").

## Guidance for senders (ESP operations)

- **Sending automated mail:** every message your platform generates that is not a direct reply (welcome mail, alerts, digests and, arguably, bulk campaigns) can carry `Auto-Submitted: auto-generated`. Anything that answers a user's message carries `auto-replied`. This costs nothing, stops storms of OOO replies coming back at you, and labels your streams honestly for filters. Never put an `Auto-Submitted` value other than `no` on genuine human one-to-one (1:1) mail.
- **Never auto-respond to `<>` or to `Auto-Submitted` mail** in any product feature (autoresponders, "thanks for your reply" flows, ticket bots). Doing so generates backscatter, and backscatter gets IP addresses [blocklisted](https://emailmarketing.net/learn/reference/blocklists-and-spamhaus).
- **Classifying inbound replies at the bounce address:** an OOO reply is not a bounce. Detect it by `Auto-Submitted: auto-replied`, by subject prefixes such as `Auto: ` or a localized "out of office", and by the absence of a `multipart/report` structure. Then **do not suppress the recipient**. An OOO reply proves that the mailbox exists and received the message, so treating it as a failure removes live subscribers. Microsoft Exchange marks OOO replies with `X-Auto-Response-Suppress` and `auto-replied`. Plenty of responders in the real world do not comply, so keep heuristics alongside the header check.
- **Reply tracking features:** exclude messages with `Auto-Submitted != no` from "reply" engagement metrics, and do not let them trigger follow-up sequences. Counting OOO replies as engagement corrupts both analytics and sending logic.
- **Expect spikes in OOO volume** after large business-to-business (B2B) sends, especially around holidays. They are normal and harmless. An auto-response loop between your system and a responder is not harmless, and the limits on your side (once per 7 days, once per message) are the guard against it.
- **Precedence: bulk** on marketing mail is still a courtesy signal that some responders honor by staying silent. It is non-standard but harmless, and it reduces OOO noise.

## Related articles

- [RFC 5321 (SMTP)](https://emailmarketing.net/learn/rfc/rfc5321-smtp), the null reverse-path contract this builds on
- [Delivery Status Notifications](https://emailmarketing.net/learn/bounce-handling/delivery-status-notifications), the other kind of automatic mail, identified by format rather than by Auto-Submitted
- [ESMTP Extensions](https://emailmarketing.net/learn/rfc/esmtp-extensions), including `NOTIFY=NEVER`
- [Complaint Feedback Loops](https://emailmarketing.net/learn/list-management/complaint-feedback-loops)