The Auto-Submitted header is the small piece of metadata that stops machines from answering machines. Without it, an out-of-office reply meets an automatic confirmation, each one triggers the other, and within minutes a mailbox holds thousands of messages that nobody wrote. This guide explains how auto-replies, vacation responders and bounces should be marked, how to recognise them in inbound processing, and how to keep your own transactional acknowledgements from ever starting a loop.
Why mail loops happen and why they are expensive
A loop needs two automatic parties and one rule that says: reply to whatever arrives. Picture a support address that answers every incoming message with a confirmation, and a customer who is on holiday with a vacation responder. The customer writes in, the support system confirms, the vacation responder answers the confirmation, the support system confirms that, and so on. Neither side is broken. Each one is following its own instructions.
The cost is real even when a loop lasts only a few minutes. Queues fill, mailboxes hit their quota, and the volume of near-identical messages can make receiving servers treat your domain as abusive. If the loop involves a third party, such as a mailing list or an unmonitored shared mailbox, many more people see it. Preventing this is cheap: a few headers, one envelope rule and a counter.
| Loop pattern | How it starts | What breaks it |
|---|---|---|
| Auto-confirmation meets vacation responder | Your system acknowledges every inbound message, including automatic ones | Do not answer messages marked as automatic, and rate-limit per sender |
| Bounce meets auto-reply | A failed auto-reply generates a bounce that is itself answered | Send auto-replies with a null sender so failures cannot come back |
| Two forwarding rules | Mailbox A forwards to B and B forwards to A | Loop detection by hop count, usually in Received headers; fix the rules |
| Reply-To pointing at your own intake | A form sets Reply-To to an address that auto-acknowledges | Guard the intake route and use a different address for human replies |
| Mailing list echo | An auto-reply goes to the list address instead of the sender | Answer the envelope sender only, never the list |
The Auto-Submitted header in RFC 3834
RFC 3834 describes how automatic responses to email should behave. Its main contribution is the Auto-Submitted header field, which any system that generates mail without a person typing it can use. It has three values you need to know.
| Value | Meaning | Typical use |
|---|---|---|
| no | A person wrote and sent the message (the default if the header is absent) | Normal mail from a mail client |
| auto-generated | A machine created the message, not as a direct answer to another message | Receipts, alerts, scheduled reports, password reset notices |
| auto-replied | A machine created the message as a direct answer to a specific incoming message | Vacation responders, acknowledgements of a received request |
The rule for receivers is simple. If the header is present with any value other than no, an automatic responder should not send another automatic response to it. That single rule breaks the loop between two compliant systems, because the second message carries the marker that the first system respects.
What a compliant auto-reply looks like
A well-formed automatic reply identifies itself in several places at once. The envelope sender is empty, the Auto-Submitted header says auto-replied, and the message points back at the one it answers using In-Reply-To and References, so mail clients thread it correctly. A Precedence header is optional but helps older software. Here is a sample set of headers with invented addresses.
Return-Path: <>
Received: from mail.example.net (mail.example.net [192.0.2.25])
by mx.example.org with ESMTPS; Tue, 06 Oct 2026 09:14:02 +0000
From: Support <support@example.net>
To: customer@example.org
Subject: We received your request
Auto-Submitted: auto-replied
Precedence: auto_reply
In-Reply-To: <req-8841@example.org>
References: <req-8841@example.org>
Message-ID: <ack-8841@example.net>
Date: Tue, 06 Oct 2026 09:14:01 +0000
X-Auto-Response-Suppress: All
Hello, we have received your request and a person will answer
within one business day. This is an automatic message.Note that the Return-Path line shows empty angle brackets. That header is added by the receiving server from the SMTP envelope, and it is how a downstream system sees the null sender. The next section explains it.
The null sender: why bounces and auto-replies use an empty Return-Path
During an SMTP conversation the sending server announces an envelope sender with the MAIL FROM command. For ordinary mail this is a real address that will receive bounces. For delivery status notifications and for automatic replies, the envelope sender is empty, written MAIL FROM:<>. RFC 5321 defines this null reverse-path and says it is used so that notifications about notifications are never generated.
This matters for two reasons. First, if your auto-reply cannot be delivered, the receiving server has nobody to tell, so no bounce is created and the loop cannot extend itself. Second, your inbound processing gains a very cheap and reliable filter: a message with an empty Return-Path is a bounce or an automatic message, so it should never get an automatic answer.
A rule worth enforcing in code: Never send an automatic response to a message whose envelope sender is empty, and always send your own automatic responses with an empty envelope sender.
Bounces use the same mechanism, in the format described in RFC 3464 for delivery status notifications. If you want to tell a real bounce from an out-of-office message, our guide to SMTP bounce codes covers the failure side in detail. For where the Return-Path ends up when you use your own bounce domain, see custom Return-Path and tracking domains.
Precedence and other auto-response signals
The Auto-Submitted header is the documented, current signal, but real inboxes also carry older and vendor-specific ones. A robust responder checks several and answers only when none of them says the message is automatic.
| Signal | Where it comes from | How to treat it |
|---|---|---|
| Auto-Submitted other than no | RFC 3834 | Do not auto-respond |
| Return-Path empty (MAIL FROM:<>) | RFC 5321 null reverse-path | Do not auto-respond |
| Precedence: bulk, junk or list | Long-standing convention, not a current standard | Do not auto-respond |
| List-Id, List-Unsubscribe or List-Post | Mailing list headers (for example RFC 2919 for List-Id) | Do not auto-respond; the message came from a list or a bulk sender |
| X-Auto-Response-Suppress | Defined by Microsoft Exchange to ask for no automatic replies | Respect it when you see it |
| Subject like Automatic reply or Out of office | Text written by a responder | Weak signal; use only after headers |
On your own outgoing automatic mail, add Auto-Submitted and, if you like, Precedence and X-Auto-Response-Suppress. They cost nothing and protect you from other people responders. Your bulk campaigns should carry the list headers described in our List-Unsubscribe guide, which also tell responders to stay quiet.
Rules for sending your own auto-confirmation emails
Transactional acknowledgements are the most common source of loops that we hear about. A form, helpdesk or ticket system sends a message such as We got your request every time something arrives. It is a good habit for customers, and it needs guardrails. Apply these in order.
- Check the incoming message first. If it has Auto-Submitted other than no, an empty Return-Path, a bulk, junk or list Precedence, or list headers, do not acknowledge it.
- Answer the envelope sender. Use the Return-Path of the incoming message. Do not use Reply-To, and do not use the From header when the two differ. If there is no usable envelope address, do not reply.
- Send with an empty envelope sender. Your acknowledgement should use MAIL FROM:<> and carry Auto-Submitted: auto-replied.
- Limit by sender. Store the time of the last acknowledgement for each sender address, and send at most one in your chosen window.
- Apply a global cap. Add a ceiling for the total number of automatic replies per hour. If it is reached, stop and alert a person instead of sending.
- Never include the original message. Quoting the incoming text in the reply can spread unwanted content and makes loops grow larger with every round.
If your confirmations come from a web form rather than from received email, the same ideas apply in a different shape: the visitor submitted a form, so you send one confirmation per submission, protect the form with a CAPTCHA and rate limits, and never let the form decide the recipient. Our contact form email guide covers that side, and separating transactional and marketing streams explains why acknowledgements should not share a stream with promotions.
A simple per-sender throttle
The throttle needs only a table with the sender address and the time of the last reply. Before sending, look the address up. If the last reply is inside your window, skip. If not, send and update the row. Normalise the address first by lower-casing it and stripping plus tags if your policy allows, so that one person cannot get around the limit with variations. Keep the records only as long as the window needs, and treat them as personal data under your retention rules.
Detecting out-of-office and vacation replies in inbound processing
When you receive mail by webhook or by a parsed inbox, as described in our inbound email processing guide, every message deserves a quick classification before anything else happens. Out-of-office replies are legitimate messages from real mailboxes. They just are not what you were waiting for, and they must not trigger customer-facing actions or list changes.
A practical classification order
- Check Auto-Submitted. Any value other than no means automatic.
- Check the Return-Path. Empty means a bounce or an automatic message. Then decide between the two in the next step.
- Look for a delivery status report. A multipart/report message with a delivery-status part (RFC 3464) is a bounce and goes to your bounce handling.
- Check Precedence, X-Auto-Response-Suppress and list headers.
- Only then, look at the subject and the first lines of text for typical phrases such as Automatic reply, Out of office or I am away until. Treat this as a hint, because wording varies by language and client.
- If nothing matches, treat the message as a human reply and route it normally.
Header checks should always run before text checks. Text patterns are language specific and easy to fool, and a customer who writes the words out of office in a real question should not be silenced.
| Classification | Typical signs | Action |
|---|---|---|
| Human reply | No automatic markers; a normal Return-Path | Route to a person or your reply parser |
| Out-of-office or vacation reply | Auto-Submitted: auto-replied, vacation wording, normal address that exists | Log it, no customer action, no list change, do not answer |
| Bounce (delivery failure) | Empty Return-Path and a delivery-status report | Send to bounce and suppression handling |
| Mailing list or bulk traffic | List headers or bulk Precedence | Do not answer; handle according to your rules |
| Unclear automatic message | Some markers but no report or reply wording | Store for review; take no automatic action |
Treating out-of-office replies as non-bounces for list hygiene
An out-of-office reply proves that a mailbox exists and accepted your message. Counting it as a bounce is a mistake that quietly damages your list. The address would be suppressed even though it works, your bounce rate would rise for no reason, and an engaged contact on holiday would stop hearing from you.
- Do not suppress. An out-of-office reply is not a delivery failure, a complaint or an unsubscribe. Leave the address active.
- Do not count it as a bounce. Keep bounce metrics for real delivery failures, so they can be compared over time. See what to measure in deliverability.
- Do not count it as engagement either. It is an automatic response, not a sign of interest. Do not use it to reset a sunset clock.
- Optionally pause. If the reply gives a return date and your tooling can read it, you may delay the next send until then. Do not guess the date from free text.
- Watch for repeated auto-replies of another kind. A reply that says the person has left the company is a signal for a human to review, even though it is not a technical bounce.
For the wider process of suppressing real failures, complaints and opt-outs, see suppression list management.
Reply-To mailboxes and who answers them
When you send campaigns or notifications from an address that nobody reads, you usually set Reply-To to a mailbox that someone does read. That mailbox is the place where out-of-office replies, human answers and sometimes bounces from forwarding rules all arrive together, so it needs the same care as any inbound route.
- Make sure the Reply-To mailbox exists, accepts mail from outside and has enough storage. A full or missing mailbox produces bounces in the sender view of the people who replied.
- Do not point Reply-To at a mailbox that sends automatic acknowledgements unless that acknowledgement follows the guards above.
- Treat Reply-To as a human channel. Automatic systems should answer the envelope sender, not this field.
- If you parse replies automatically, classify first and parse second, so that out-of-office text does not become a ticket body.
- Keep the visible From address on a domain you have authenticated, as explained in sending domain authentication.
A worked example: finding a loop in the numbers
A small business runs a support address that acknowledges every incoming message and allows up to 40 automatic acknowledgements an hour as its only safety net. One morning an employee at a client company leaves on holiday and switches on a vacation responder. A client email arrives at 09:00, and the support system acknowledges it. The vacation responder answers the acknowledgement. The support system, which does not check Auto-Submitted, acknowledges that as well.
Each round takes about 30 seconds, so the pair exchanges 2 messages a minute. The hourly ceiling of 40 acknowledgements is reached after about 20 minutes, and from then on the support system queues the rest and a team member is alerted. By then the client mailbox holds around 40 vacation replies and the support inbox about the same number of useless tickets. Nothing is lost permanently, but the cleanup takes the better part of an hour.
After the incident the team makes four changes. Acknowledgements now carry Auto-Submitted: auto-replied and go out with an empty envelope sender. Inbound mail with any Auto-Submitted value other than no, an empty Return-Path or list headers is never acknowledged. Each sender address gets one acknowledgement per 24 hours. The hourly ceiling stays as a last line of defence. Replaying the same holiday scenario in staging now produces one acknowledgement and one vacation reply, then silence: 2 messages instead of about 80.
A short checklist
- Every automated message carries Auto-Submitted: auto-generated or auto-replied.
- Automatic replies use an empty envelope sender (MAIL FROM:<>).
- Inbound guard checks Auto-Submitted, Return-Path, Precedence and list headers before any reply.
- Replies go to the envelope sender, not to Reply-To or a list address.
- One acknowledgement per sender per window, with a global hourly cap and an alert.
- Original message text is never quoted back automatically.
- Out-of-office replies are logged, not counted as bounces, not suppressed and not treated as engagement.
- Reply-To mailboxes exist, are monitored and apply the same guards.
- Loop scenarios are tested in staging before release, using the methods in our staging and mail catcher guide.
Need help with inbound mail and auto-replies? Tell us how your replies are routed and what your system answers automatically, and we will help you plan a loop-safe setup.
Further reading and sources
Frequently asked questions
What is the Auto-Submitted header?
It is a header defined in RFC 3834 that tells a receiver whether a message was written by a person or produced by a machine. The value no means a person sent it. The value auto-generated means a system produced it without being asked by a specific message. The value auto-replied means a system produced it as a direct answer to another message.
Should I send an out-of-office reply to every message I receive?
No. RFC 3834 asks responders not to answer mail that is itself automatic, not to answer messages with a null return path, and not to answer the same sender repeatedly in a short time. Mailing list traffic and bulk mail should be left alone as well, because replying to them only adds noise and can reach a very large audience.
Why do automatic replies use an empty Return-Path?
An empty envelope sender, written MAIL FROM:<> in the SMTP dialogue, tells every later server that no one should be notified if this message cannot be delivered. RFC 5321 describes it for bounces, and RFC 3834 asks for it on auto-replies. It breaks the chain that would otherwise let two failing systems bounce messages back and forth.
Is an out-of-office reply a bounce?
No. It means the mailbox exists and accepted the message, so the address is valid. A real bounce is a delivery status notification or an SMTP rejection that says delivery failed. Counting out-of-office replies as bounces would remove good contacts from your list and distort your delivery numbers.
How can I tell a vacation responder from a real reply?
Check headers first. Look for Auto-Submitted other than no, an Exchange style X-Auto-Response-Suppress header, a bulk or auto_reply Precedence, or a null Return-Path. Then use subject patterns such as Automatic reply or Out of office as a weaker second signal. Treat unclear cases as human replies so that real people are not ignored.
Does the Precedence header still matter?
Yes, although it is not part of a current standard. Many older autoresponders and mail tools still read values such as bulk, junk and list as a request not to answer. Adding Precedence: bulk to bulk or automatic mail is harmless, but it does not replace Auto-Submitted, which is the documented signal.
Where should an automatic reply be sent: From, Reply-To or Return-Path?
RFC 3834 says to answer the address in the Return-Path of the incoming message, which is the envelope sender. Reply-To is chosen by the author for human answers and can point anywhere, including at a third party, so answering it automatically can send mail to people who never wrote to you.
How often can I send an auto-reply to the same person?
Choose a limit and enforce it. RFC 3834 recommends that a responder sends at most one reply to a sender within a reasonable period instead of answering every message. A common approach is a stored timestamp per sender address and a single reply per window, plus an overall hourly cap so that one bad day cannot flood your system.
Will a loop hurt my sending reputation?
It can. A loop produces a burst of repetitive messages, often to addresses that did not ask for them, and recipients and mailbox providers may treat that as abuse. Even a short loop can also fill queues and mailboxes. Prevention with headers, a null sender and rate limits is far easier than recovery.