Auto replies, bounces and mail loops: keeping AI agents out of machine mail

Machine mail is any message a program wrote: out of office replies, helpdesk ticket acknowledgements, satisfaction surveys, no reply senders and delivery failures. An AI email agent must not answer it, must not count it as a human reply, and must route the lead to a person with a reason. Sellinger marks such messages as machine mail, since 4 October 2026.

Cold email creates a lot of automated answers. Every company has a helpdesk, an auto responder or a ticket system, and your message hits them all. For a person reading an inbox, machine mail is easy to ignore. For an AI agent that reads every message and replies to what it understands, it is a trap with three costs.

What does machine mail look like?

• Out of office. "I am away until the 14th."
• Ticket acknowledgement. "We received your message. Your reference is 48213." Sent when your email reaches a support address.
• Satisfaction survey. "How did we do? Rate your experience."
• No reply sender. From an address that does not accept mail, with a footer saying so.
• Delivery failure. A bounce notice from the mail server.
• Empty or near empty messages. An automatic acknowledgement with no content.
• Generated replies. Some tools now write an automatic answer with a language model, so they can read like a person. The marker is not the style but the source.

Some of these carry headers that say the message was automatic. RFC 3834 describes an Auto-Submitted header for this purpose and advises against automatically answering a message that is marked as automatic. Many systems do not set it, so you cannot rely on it alone.

What goes wrong if an agent answers it?

Wasted sends. Each answer to a robot uses a send from a limited daily count, in a mailbox whose reputation you care about. Our default is 50 sends a day per mailbox.

Loops. An agent that replies to a helpdesk can trigger another acknowledgement, which the agent reads as a reply and answers. Two machines can talk to each other all day. Rate limits and thread caps should stop it, and better detection prevents it.

False replies. A ticket acknowledgement counted as a reply makes the reply rate look healthier than it is, and a lead marked as engaged when no human has read anything. Decisions on the campaign follow from that number. See does cold email still work on why reply rates are hard to compare even when counted properly.

Embarrassment. "Thanks for getting back to me!" sent to a no reply address does your brand no good.

How does Sellinger handle it?

Four rules, in plain terms.

1. Mark it. A message that matches machine mail classes, such as helpdesk acknowledgements, surveys and generated replies, carries one marker on the conversation entry.
2. Do not count it. It never counts as a human reply anywhere, in the app, reports or the agent's own logic. The same definition is shared between the backend, the web app and the database, so numbers agree.
3. Do not answer it. The agent skips it.
4. Route it. The lead is sent to a person with a named reason, such as an automatic ticket acknowledgement, because a person may still want to follow up, for instance by finding the real contact.

A short human line such as "Thanks" counts as a reply. A no reply sender does not. The shared test cases for this boundary are the same in every part of the system.

This went live on 4 October 2026.

What should you do if you run your own setup?

• Check headers. Auto-Submitted, Precedence, and the delivery status notification type tell you a lot. Treat them as a signal, not a guarantee.
• Check the sender. Addresses such as noreply or donotreply are not people.
• Check the content. Ticket numbers, "do not reply to this message", survey links and "we have received your request" are tells.
• Never let a bounce reach a reply step. Handle delivery failures on their own path, and remove the address.
• Count replies in two layers. Replies of any kind, and replies that a person wrote. Report the second.
• Cap thread depth. No more than a few automatic turns in one thread.
• Review a sample. Read twenty conversations marked as replies and count how many are robots.

Does it change your numbers?

Yes, and that is the point. If you counted machine mail as replies before, your reply rate falls when you correct it, and your sample of real conversations gets cleaner. A lower, true number is more useful than a higher, false one. This is the same discipline as counting meetings held rather than booked (count meetings honestly).

What does a loop look like, step by step?

A made up example of how two machines can talk to each other when nothing stops them.

1. The agent sends a first email to a contact at a company.
2. The company's helpdesk replies: "We received your message. Your reference is 48213."
3. An agent that treats every inbound message as a reply answers: "Thanks, happy to share more details."
4. The helpdesk opens a second ticket and sends another acknowledgement.
5. The agent answers again.

Each turn uses a send from the mailbox. No person has read anything, and the thread now looks busy. Marking step 2 as machine mail breaks the loop at the first turn: no answer, no reply count, and the lead goes to a person with the reason "automatic ticket acknowledgement".

Which cases are hard?

A generated reply that reads like a person. Some tools write automatic answers with a language model, so style is no guide. The test is the source of the message, and a person should look at a case the system is unsure about.

An out of office that names a colleague. The message is machine mail, but it may carry something useful: the name of the person to write to. That is why the lead goes to a person and is not simply dropped.

A real person replying through a helpdesk. A support agent may write a human line from a ticket system. It is a person, so it counts. The boundary is who wrote it, and the shared test cases exist because that line is not always obvious.

A bounce. A delivery failure is not a reply and not a person. It belongs on its own path, where the address is removed or fixed.

How should reply numbers be reported?

Report two lines. The first is all inbound messages. The second is replies that a person wrote. The gap between them is your machine mail. If you run a campaign for a client, define the second line in the report and say so, the same way you define held meetings and booked meetings (count meetings honestly).

A made up example: a campaign sends 400 emails and receives 60 inbound messages. A review shows 22 are out of office, ticket acknowledgements or bounces. The honest reply count is 38, a rate of 9.5%, not 60 and 15%. The campaign was never worse than that. It was measured wrongly.

What should you do about your own sending?

Keep a working reply address on every sending mailbox and read what arrives in it, so that bounces and automatic answers reach the place that handles them. The rules we apply to every AI written email are in cold email rules we enforce, and the way each kind of reply is handled is in the 12 reply types.

What is the principle?

An agent should answer people. Everything else is routing. For the rules we apply to every AI written email, see cold email rules we enforce, and for how a reply of each kind is handled, the 12 reply types.